| name | writing-plans |
| description | 将设计规格转化为细粒度实现计划(plan.md)。每个任务 2 到 5 分钟,遵循 DRY/YAGNI 原则。支持注释循环。触发短语:"编写计划"、"写计划"、"制定方案"。 |
| allowed-tools | Read, Write, Edit, Glob, Grep, Bash, Agent |
/writing-plans — 编写实现计划
将设计规格文档(spec.md)转化为可逐步执行的实现计划。plan.md 是后续所有实现工作的唯一真相来源。
核心原则
- plan.md 比聊天记录更可靠(上下文压缩后仍完整保存)
- 每个任务 2 到 5 分钟可完成,粒度足够细才能被子代理独立执行
- 遵循 DRY 和 YAGNI:只规划当前需要的改动,不为假想需求设计
- 先读代码再写计划:每个改动必须基于对现有实现的理解
流程
第一步:加载设计规格
读取最近的 spec.md(在 docs/sdlc/ 下查找),确认设计意图和范围。
如果没有 spec.md,建议用户先执行 /brainstorming。
第二步:调研现有代码
使用 Glob、Grep、Read 工具深入分析需要修改的文件:
- 理解现有实现的结构和逻辑
- 识别依赖关系和影响范围
- 记录需要注意的约束条件
第三步:编写计划
在 docs/sdlc/YYYY-MM-DD/{slug}/plan.md 中写入实现计划:
# [任务标题]
## 方案说明
[基于 spec.md 的设计决策,描述实现策略]
## 改动文件
- `path/to/FileA`:修改 xxx,添加 yyy
- `path/to/FileB`:新增 zzz
## 代码片段
[关键改动的代码示例,展示核心逻辑]
## 考量与权衡
[为什么选这个方案,有哪些 trade-off]
## 影响的测试
[需要修改或新增的测试]
## Todo List
### Phase 1: [阶段名]
- [ ] 任务 1(2 到 5 分钟描述)
- [ ] 任务 2
### Phase 2: [阶段名]
- [ ] 任务 3
- [ ] 任务 4
任务粒度指南:
- 每个任务应该是一个独立的、可验证的改动
- 描述要足够具体,让不了解上下文的代理也能执行
- 包含文件路径、函数名、预期行为
第四步:计划审查
使用 Agent 工具派遣子代理审查 plan.md。子代理的 prompt 使用 references/plan-reviewer-prompt.md 的内容。
将审查结果呈现给用户,根据反馈修改 plan.md。
第五步:用户审阅
告知用户:"实现计划已写入 docs/sdlc/YYYY-MM-DD/{slug}/plan.md,请审阅并添加注释。"
注释循环
当用户发送"我加了注释"或类似指令时:
- 读取 plan.md 中用户添加的注释
- 根据注释修改 plan.md
- 回复末尾注明:(尚未实现,等待确认)
- 绝不提前写代码
循环直到用户满意。用户确认后,建议执行 /executing-plans 或 /subagent-driven-development。
不做的事
- 不写实现代码
- 不使用内置 Plan Mode(聊天内计划不持久、不可编辑)
- 不跳过代码调研直接写计划