| name | generate-dev-plan |
| description | Use when the user wants to turn a PRD requirement (FR-N or similar ID) into an executable development plan. Locates the requirement in docs/prd/, investigates the surrounding code, asks clarifying questions, and produces docs/plans/<FR-N>.md as a markdown checkbox list of independent, vertical-slice tasks. Triggers on "make a plan for FR-001", "generate a plan for this requirement", "break this PRD into tasks", "plan the implementation of FR-N", "create a dev plan", "/plan FR-N". |
Generate Dev Plan
Turn a PRD requirement into a checkbox-tracked development plan. Implements Phase 3 of the AI Development Framework V2.
Core principle
A plan is a contract between you and the agent for one requirement. The agent's job is to investigate before writing. Never produce a plan without first reading the PRD, mapping the affected code, and resolving ambiguity with the user. A plan with phantom tasks or missed dependencies is worse than no plan.
Each task MUST be:
- Independently completable — runnable + tested at the end of the task (no plumbing-only tasks).
- Identified — sub-IDs under the requirement (
FR-001.1, FR-001.2, …) so they cross-reference to ACs and tests.
- Sized for one focused session — if a task feels >2 hours of work, split it.
When to use
- PRD exists, contains the requirement, no plan yet → start at Phase 1.
- Plan exists but is stale or incomplete → start at Phase 2 with the existing plan as input.
- You want to plan a change across multiple requirements → run this skill once per requirement, do not bundle.
Skip for: bug fixes < 50 LoC, single-file refactors, exploratory spikes.
The 3 phases
Each phase has an INPUT, an OUTPUT, and a HUMAN GATE before advancing.
Operating protocol
- Identify the requirement ID. If the user didn't give one, ask. Do not pick one yourself.
- Read the matching prompt file in
prompts/ and run it. Treat the prompt body as a system instruction — follow its rules literally.
- Stop at every phase boundary. Show the artifact and ask: approved / refine
<section> / restart phase. No chaining without approval.
- Phase 3 drafting: copy templates/plan.md.tmpl and fill it. Path is
docs/plans/<REQUIREMENT_ID>.md (e.g. docs/plans/FR-001.md).
- Final gate: score against references/checklist.md. Pass criterion: 7/7 items ✅.
Hard rules (non-negotiable)
- One plan per requirement. Do not bundle FR-001 and FR-002 in one file. If they truly share work, split the shared work into a third pseudo-requirement (e.g.
FR-001-002-shared) and reference it from both.
- Every task ends runnable + tested. No "wire up types now, add logic later." Each
[ ] task MUST leave the code green.
- No fuzzy adjectives in tasks. "Improve performance", "clean up the API", "make it robust" trigger an immediate rewrite to a quantified, testable task.
- Cross-reference everything. Every task line points to FR-N.M (sub-ID), AC-N (the acceptance criterion it satisfies), and the test name(s) it adds or modifies.
- Mark files explicitly. Each task names the files it touches. Vague tasks like "update the auth module" are forbidden.
- Ambiguity → ASK. Phase 2 must resolve every open question before Phase 3 starts. Never invent a decision.
- Use markdown checkboxes (
- [ ] / - [x]) — this is the format the rest of the framework expects.
What NOT to do
See references/anti-patterns.md. Top three:
- Plumbing-only sequences —
[ ] add types, [ ] add empty handler, [ ] add tests as separate tasks. Each task must end runnable + tested.
- Phantom tasks — listing work that already exists in the codebase. Phase 2's job is to catch this.
- Monolithic tasks —
[ ] implement the feature with no breakdown. If you can't split, you didn't investigate enough.
References
