Practical, evidence-led guides for taking real work from an early idea to something people can use, inspect, maintain, and improve.
lifecycle-skills is a collection of small operating methods maintained by virtualmase. Each skill is designed for a recurring moment in a project: testing an idea, building from a reviewed plan, cleaning up old work, helping useful work reach people, maintaining what shipped, or studying an experience before changing it.
The collection is not a maturity model and it is not one prescribed workflow. Use the skill that matches the decision in front of you.
| Skill | Use it when | Leave with |
|---|---|---|
| Prototype | You need to test an important assumption before committing to a full build. | A bounded prototype, observation record, decision recommendation, and archive or removal plan. |
| Builder | A reviewed specification is ready to become working software or another maintained implementation. | Source-controlled work, validation evidence, dependency notes, deployment instructions, and a rollback path. |
| Sweeper | A project has stale files, broken references, unused assets, unsafe configuration, or accumulated debt. | An inventory, dry-run plan, approval record, cleanup log, and verification report. |
| Grower | Useful public work needs better discovery, participation, or distribution. | A channel plan, clear publication copy, observed response, correction path, and next experiment. |
| Maintainer | A released project needs triage, release review, dependency checks, incident records, or ongoing care. | A reviewed release or triage record, validation evidence, changelog, residual risks, and the next review point. |
| Experience Research | You need to understand a product, interface, customer journey, or market pattern before proposing a change. | A research brief, evidence table, prioritized improvement hypotheses, validation plan, and decision record. |
A project may move through these skills in any order.
prototype → build → maintain
↑ ↓ ↓
research ← learn ← grow
↑ ↓
└────── sweep ←────┘
That diagram is a reminder, not a process requirement. Real projects loop, stall, revisit earlier decisions, and sometimes stop.
Every skill in this repository follows the same basic shape.
Define the question, scope, owner, relevant constraints, data boundary, success condition, and way back before doing the work.
If the important inputs are unknown, reduce the scope or resolve them first.
Work through a short sequence of concrete steps. The steps should make the decision easier to inspect, not create ceremony for its own sake.
Leave behind something another person can review and continue from. A result without a record is harder to maintain than it needs to be.
State what the skill must not do. A useful method should make its limits as visible as its intended use.
Start with the question you are trying to answer.
If you are asking:
- Should we build this? Start with Prototype.
- How should we build the reviewed plan? Use Builder.
- What can safely be removed? Use Sweeper.
- How do we help the right people find this? Use Grower.
- What does this released project need now? Use Maintainer.
- What is actually happening in this experience? Use Experience Research.
Then:
- Read the skill's
SKILL.md. - Record the intake information that matters for your project.
- Adapt the workflow to the size and risk of the work.
- Keep observations separate from interpretations and recommendations.
- Store the useful outputs with the project, preferably in version control.
- Get review before a consequential, public, destructive, or hard-to-reverse action.
- Hand the result to the next responsible person or skill.
The skill should make the work clearer. If following it creates more overhead than understanding, reduce it to the parts that protect the decision.
A small test is usually cheaper to understand and easier to reverse than a large commitment. Prototype uncertain ideas. Stage risky changes. Prefer changes that can be reviewed in pieces.
Record what was observed, where it came from, when it was observed, and what remains uncertain. Do not turn an interpretation into a fact by writing it confidently.
Important work needs an owner. Approval, review, rollback, and unresolved risk should not belong to an unnamed team or an automated process.
A happy path is not enough. Check invalid input, broken links, inaccessible states, permission failures, recovery behavior, rollback, and the unusual cases that become expensive later.
When two approaches meet the requirement, prefer the one that is easier to inspect, change, remove, or replace.
Clear language, keyboard access, error recovery, documentation, dependency discipline, and upkeep are not final polish. They affect whether the work remains useful after launch.
Distribution should help useful work reach people who may benefit from it. Do not fabricate reviews, buy deceptive engagement, create link schemes, hide automation, or inflate results that were not observed.
The Experience Research skill is intentionally more detailed than the other entry points because research can easily blur observation, preference, market evidence, and proposed action.
It includes reusable templates and a small validation utility for evidence ledgers.
Validate an example ledger with:
python3 scripts/validate_evidence_ledger.py examples/valid-ux-research-ledger.jsonThe validator uses the Python standard library and does not require third-party packages.
skills/ Standalone skill packages. Each begins with SKILL.md.
examples/ Safe example records used to demonstrate and test the methods.
scripts/ Small validation utilities with no required third-party runtime packages.
catalog.json Machine-readable index of the current skill collection.
CHANGELOG.md Material changes to the collection.
COMMUNITY.md Community expectations and participation guidance.
Repository-wide contribution and security guidance lives in CONTRIBUTING.md and SECURITY.md.
A new skill should earn its place by solving a recurring class of decisions that is meaningfully different from the existing collection.
Good additions are:
- narrow enough to understand in one sitting
- useful across more than one project
- explicit about inputs, outputs, and limits
- practical without requiring a particular vendor or platform
- reviewable by another person
- safe to demonstrate with synthetic or public examples
A checklist for a one-off task usually does not need to become a skill.
Corrections, tighter wording, better examples, portability improvements, accessibility fixes, and evidence-backed changes are welcome.
Before opening a pull request, read CONTRIBUTING.md. Do not include credentials, personal data, raw customer material, private analytics, sensitive security details, or other information that does not belong in a public repository.
Security concerns should follow SECURITY.md.
These skills are working guides. They do not replace the legal, security, safety, accessibility, privacy, financial, medical, or compliance responsibilities that apply to a specific project.
Use judgment. Keep the decision visible. Leave the work easier for the next person to understand.
Released under the MIT License.
virtualmase
build quietly.