SKILL.md
$27
Workflow
1. Read the approved specs first
Treat:
PRODUCT.mdas the source of truth for user-facing behavior
TECH.mdas the source of truth for architecture, sequencing, and implementation shape
Make sure you understand the expected behavior, constraints, risks, and validation plan before writing code.
2. Offer optional implementation aids for large features
For large or long-running features, optionally offer one of these aids to the user before implementation begins:
PROJECT_LOG.mdto track checkpoints, explored paths, partial findings, and current implementation state
DECISIONS.mdto capture concrete product and technical decisions made during the PRD and tech design process
These are optional aids, not required deliverables. Offer them when they would reduce confusion or help future agents avoid re-exploring the same paths.
3. Plan and implement against the specs
Break the work into concrete implementation steps, then implement the feature against the approved specs.
During implementation:
- keep behavior aligned with
PRODUCT.md
- keep architecture and sequencing aligned with
TECH.md
- add or update tests and verification artifacts as the work lands
Use the same PR for the specs and implementation when practical so the full feature evolution is reviewable in one place.
4. Update specs as the implementation evolves
If implementation reveals that the intended behavior or design should change, update the checked-in specs rather than letting them go stale.
In particular:
- update
PRODUCT.mdwhen user-facing behavior, UX, edge cases, or success criteria change
- update
TECH.mdwhen architecture, sequencing, module boundaries, or validation strategy change
- keep those updates in the same PR as the corresponding code changes
The PR should describe the feature that actually ships, not just the initial draft of the specs.
5. Verify against the specs
Before considering the work complete, verify that the code matches the current specs.
Prefer:
- unit tests and regression coverage that follow the repository's local testing conventions
- integration or end-to-end tests for important user flows
Best Practices
- Keep specs and code synchronized throughout implementation.
- Prefer updating the spec immediately when decisions change rather than batching spec cleanup until the end.
- Use optional tracking documents only when they add real value for a complex feature.
- Keep the same PR coherent: spec updates, code changes, tests, and optional tracking docs should all support the same feature narrative.
Related Skills
spec-driven-implementation
write-product-spec
write-tech-spec