用途
writing-plans 是一个用于在接触代码之前编写实现计划的技能，适用于你已经拥有某个多步骤任务的规格说明或需求时。它的目标是产出一份全面、可直接执行的实现计划，假设执行计划的工程师是一名熟练开发者，但对你的代码库、工具链和问题领域几乎一无所知，而且不太懂良好的测试设计。
技能开始时需要声明："I'm using the writing-plans skill to create the implementation plan." 该技能应在专用 worktree（由 brainstorming 技能创建）中运行。
主要能力
范围检查
如果规格覆盖多个相互独立的子系统，本应在 brainstorming 阶段就拆分为子项目规格；如果没有拆分，技能会建议拆成独立计划，每个子系统一份，每份计划都应能独立产出可运行、可测试的软件。
文件结构规划
在定义任务之前，先梳理将会创建或修改哪些文件、每个文件负责什么。设计具有清晰边界和明确接口的单元，每个文件承担单一职责，偏好更小、更聚焦的文件。一起变更的文件应放在一起，按职责而非技术层拆分。在既有代码库中遵循已有模式；如果正在修改的文件已经过于庞大，可以在计划中纳入拆分。
小颗粒任务
每个步骤是一个动作（2-5 分钟），例如：写失败测试、运行确认失败、写最小实现使测试通过、运行测试确认通过、提交。
计划文档头部
每份计划必须以固定头部开头，包含：功能名与 Implementation Plan、面向 agentic workers 的说明（使用 /build 或项目的计划执行技能逐任务实现，步骤用 - [ ] 复选框语法跟踪）、Goal（一句话目标）、Architecture（2-3 句方法说明）、Tech Stack（关键技术/库）。
任务结构
任务按 Task N 组织，先列出 Files（Create / Modify / Test 的精确路径），再用复选框步骤展开，每步给出具体代码、命令与预期结果。示例结构包括写失败测试、运行确认失败、写最小实现、运行确认通过、提交代码。
禁止占位符
每个步骤都必须包含工程师真正需要的内容。以下都是计划失败："TBD"、"TODO"、"implement later"、"fill in details"；"Add appropriate error handling" 之类；没有实际测试代码的"写上述测试"；"Similar to Task N"（应重复代码，因为工程师可能乱序阅读）；只描述做什么而不展示怎么做的步骤；引用任何任务中都未定义的类型、函数或方法。
使用方式
技能要求注明精确文件路径、每一步的完整代码（若改变代码就展示代码）、精确命令与预期输出，并遵循 DRY、YAGNI、TDD、频繁提交。
计划保存位置默认是 ai-workspace/plans/YYYY-MM-DD-<feature-name>.md，但应尊重用户对计划位置的偏好，该默认可被覆盖。
自检
写完计划后，要重新对照规格检查：
- 规格覆盖：浏览规格中的每个章节/需求，能否指出实现它的任务？列出遗漏。
- 占位符扫描：搜索前面列出的警示模式，并修复。
- 类型一致性：后续任务中的类型、方法签名、属性名是否与前面定义一致（例如 Task 3 叫
clearLayers()、Task 7 叫clearFullLayers()就是 bug）。
发现问题就直接原地修复，不必重新审查。如果发现某条规格需求没有对应任务，就补上任务。
执行交接
保存计划后，向用户提供执行选择：一是 Subagent-Driven（推荐），每个任务派发新的子智能体，任务间进行审查，迭代快；二是 Inline Execution，在当前会话中使用 /build 执行，批处理并在检查点暂停审查。如果选择 Subagent-Driven，则每个任务携带计划上下文派发新的子智能体，并在继续前审查输出；如果选择 Inline Execution，则使用 /build（或项目的计划执行技能），以批处理加检查点方式执行。
适用场景与限制
适用于已有规格或需求、即将开始多步骤实现任务的场景，尤其适合需要严格 TDD、频繁提交、任务可独立验证的项目。它要求执行者几乎零上下文，因此计划会非常详细。限制包括：应在专用 worktree 中运行；如果规格包含多个独立子系统而未拆分，需要先拆分；默认保存路径可被用户覆盖；本技能仅负责编写计划，实际执行通过 /build 或项目计划执行技能完成。