generate-dev-plan

Original：🇺🇸 English

Translated

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".

2installs

Sourceel-frontend/software-engineering-skills

Added on2026-05-10

NPX Install

npx skill4agent add el-frontend/software-engineering-skills generate-dev-plan

SKILL.md Content

View Translation Comparison →

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.

#	Phase	Input	Output	Prompt file
1	Locate requirement	Requirement ID + `docs/prd/`	Requirement excerpt + scope confirmation	prompts/01-locate-requirement.md
2	Investigate	Requirement excerpt + repo	Investigation notes + open questions resolved	prompts/02-investigate.md
3	Write plan	Investigation notes	`docs/plans/<FR-N>.md`	prompts/03-write-plan.md

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

Plan template: templates/plan.md.tmpl
Phase prompts: prompts/01-locate-requirement.md, prompts/02-investigate.md, prompts/03-write-plan.md
7-point quality checklist: references/checklist.md
Anti-patterns: references/anti-patterns.md
Source framework: ../../docs/framework.md
Upstream PRD format: ../ai-driven-prd/SKILL.md