writing-plans
当你有规格说明或需求用于多步骤任务时使用，在动手写代码之前
By jnmetacode · 1,013 installs
npx skills add jnmetacode/superpowers-zh --skill writing-plans
Source repository · Upstream listing
编写计划
概述
编写全面的实现计划，假设工程师对我们的代码库零上下文，且品味存疑。记录他们需要知道的一切：每个任务要修改哪些文件、代码、测试、可能需要查阅的文档、如何测试。将整个计划拆成小步骤任务。DRY。YAGNI。TDD。频繁 commit。
假设他们是有经验的开发者，但对我们的工具链和问题领域几乎一无所知。假设他们不太擅长测试设计。
开始时宣布： "我正在使用 writing plans 技能创建实现计划。"
上下文： 此技能应在专用 worktree 中运行（由 brainstorming 技能创建）。
计划保存位置： docs/superpowers/plans/YYYY MM DD <feature name .md
（用户对计划位置的偏好优先于此默认值）
范围检查
如果规格涵盖了多个独立子系统，它应该在头脑风暴阶段就被拆分为子项目规格。如果没有，建议将其拆分为独立的计划——每个子系统一个。每个计划应该能独立产出可工作、可测试的软件。
文件结构
在定义任务之前，先列出将要创建或修改的文件以及每个文件的职责。这是锁定分解决策的地方。
设计边界清晰、接口定义良好的单元。每个文件应有一个明确的职责。
你对能一次放入上下文的代码推理得最好，文件越专注你的编辑越可靠。优先选择小而专注的文件，而非承担过多功能的大文件。
一起变更的文件应放在一起。按职责拆分，而非按技术层级拆分。
在现有代码库中，遵循已有模式。如果代码库使用大文件，不要单方面重构——但如果你正在修改的文件已经变得难以管理，在计划中包含拆分是合理的。
此结构决定了任务分解。每个任务应产出独立的、有意义的变更。
任务粒度定界
一个任务是 能独立承载自己那一轮测试循环、且值得一个全新审查者把关 的最小单元。划任务边界时：把搭建、配置、脚手架和文档这些步骤，折进那个真正需要它们的交付物所在的任务里；只在「审查者有可能否掉这个任务、同时批准它旁边那个」的地方才拆开。每个任务都以一个 可独立测试的交付物 结束。
小步骤任务粒度
每步是一个操作（2 5 分钟）：
"编写失败的测试" 一步
"运行它确认失败" 一步
"实现最少代码让测试通过" 一步
"运行测试确认通过" 一步
"Commit" 一步
计划文档头部
每个计划必须以此头部开始：
任务结构
python
def test specific behavior():
result = function(input)
assert result == expected
python
def function(input):
return expected
bash
git add tests/path/test.py src/path/file.py
git commit m "feat: add specific feature"
禁止占位符
每个步骤都必须包含工程师需要的实际内容。以下是 计划缺陷 ——绝不要写出来：
"待定"、"TODO"、"后续实现"、"补充细节"
"添加适当的错误处理" / "添加验证" / "处理边界情况"
"为上述代码编写测试"（没有实际测试代码）
"类似任务 N"（重复代码——工程师可能不按顺序阅读任务）
只描述做什么而不展示怎么做的步骤（代码步骤必须有代码块）
引用了未在任何任务中定义的类型、函数或方法
自检
编写完整计划后，以全新视角审视规格并对照检查计划。这是你自己执行的检查清单——不是子代理调度。
1. 规格覆盖度： 浏览规格中的每个章节/需求。你能指出实现它的任务吗？列出所有遗漏。
2. 占位符扫描： 搜索计划中的红旗——上方"禁止占位符"章节中的任何模式。修复它们。
3. 类型一致性： 后续任务中使用的类型、方法签名和属性名是否与前面任务中定义的一致？任务 3 中叫 clearLayers() 但任务 7 中叫 clearFullLayers() 就是 bug。
如果发现问题，直接内联修复。无需重新审查——修好继续推进。如果发现规格中的需求没有对应任务，就添加任务。
执行交接
保存计划后，提供执行选项：
"计划已完成并保存到 docs/superpowers/plans/<filename .md 。两种执行方式：
1. 子代理驱动（推荐） 每个任务调度一个新的子代理，任务间进行审查，快速迭代
2. 内联执行 在当前会话中使用 executing plans 执行任务，批量执行并设有检查点
选哪种方式？"
如果选择子代理驱动：
必需子技能： 使用 subagent driven development
每个任务一个新子代理 + 两阶段审查
如果选择内联执行：
必需子技能： 使用 executing plans
批量执行并设有检查点供审查