generate-dev-plan

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Generate Dev Plan

生成开发计划

Turn a PRD requirement into a checkbox-tracked development plan. Implements Phase 3 of the AI Development Framework V2.

将PRD需求转换为带复选框追踪的开发计划。实现了AI Development Framework V2的第3阶段。

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.

一份计划是你与Agent针对单个需求达成的约定。Agent的职责是先调研再撰写。未阅读PRD、未映射受影响代码、未与用户解决歧义前，绝不要生成计划。包含虚假任务或遗漏依赖的计划比没有计划更糟。

每个任务必须满足：

可独立完成——任务结束时代码可运行且已测试（禁止仅做基础搭建的任务）。
可标识——需求下的子ID（如
```
FR-001.1
```
、
```
FR-001.2
```
……），以便与验收标准（AC）和测试交叉引用。
适配单次专注工作时长——如果任务预计耗时超过2小时，需拆分。

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.

PRD已存在，包含目标需求，但尚未制定计划 → 从第1阶段开始。
计划已存在但过时或不完整 → 以现有计划为输入，从第2阶段开始。
你需要为跨多个需求的变更制定计划 → 针对每个需求单独运行此Skill，不要合并处理。

以下场景无需使用：代码量少于50行的Bug修复、单文件重构、探索性研究。

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

每个阶段都有输入、输出，以及进入下一阶段前的人工审核关卡。

序号	阶段	输入	输出	提示文件
1	定位需求	需求ID + `docs/prd/`	需求节选 + 范围确认	prompts/01-locate-requirement.md
2	调研分析	需求节选 + 代码仓库	调研笔记 + 已解决的待澄清问题	prompts/02-investigate.md
3	撰写计划	调研笔记	`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 ✅.

确定需求ID。如果用户未提供，需询问，不要自行指定。
阅读
prompts/
中的对应提示文件并执行。将提示内容视为系统指令——严格遵循其规则。
在每个阶段边界处停止。展示当前产出并询问：批准/优化<章节>/重启阶段。未获批准前，不要进入下一阶段。
第3阶段起草：复制templates/plan.md.tmpl并填写内容。文件路径为
```
docs/plans/<需求ID>.md
```
（例如
```
docs/plans/FR-001.md
```
）。
最终审核：对照references/checklist.md进行评分。通过标准：7项全部✅。

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.

单个需求对应一份计划。不要将FR-001和FR-002合并到一个文件中。如果确实存在共享工作，将共享工作拆分为第三个伪需求（例如
```
FR-001-002-shared
```
），并在两个需求的计划中引用它。
每个任务结束时代码必须可运行且已测试。禁止类似“先添加类型，之后再添加逻辑”的任务拆分。每个
```
[ ]
```
任务完成后必须保证代码正常运行。
任务中禁止使用模糊形容词。类似*“提升性能”、“清理API”、“增强健壮性”*的表述需立即重写为可量化、可测试的任务。
所有内容需交叉引用。每个任务行需指向FR-N.M（子ID）、AC-N（对应的验收标准）以及新增或修改的测试名称。
明确标记涉及文件。每个任务需指明所修改的文件。禁止类似“更新认证模块”的模糊任务。
遇到歧义→询问。第2阶段必须在第3阶段开始前解决所有待澄清问题。绝不要自行做决定。
使用Markdown复选框（
```
- [ ]
```
/
```
- [x]
```
）——这是框架其他部分要求的格式。

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/anti-patterns.md。三大典型反模式：

仅基础搭建的任务序列——将
```
[ ] 添加类型
```
、
```
[ ] 添加空处理器
```
、
```
[ ] 添加测试
```
拆分为独立任务。每个任务必须以可运行且已测试的状态结束。
虚假任务——列出代码库中已存在的工作。第2阶段的职责就是发现这类问题。
单体任务——仅写
```
[ ] 实现功能
```
而不拆分。如果无法拆分，说明调研不够充分。

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

计划模板：templates/plan.md.tmpl
阶段提示文件：prompts/01-locate-requirement.md、prompts/02-investigate.md、prompts/03-write-plan.md
7项质量检查清单：references/checklist.md
反模式：references/anti-patterns.md
源框架：../../docs/framework.md
上游PRD格式：../ai-driven-prd/SKILL.md