用途
writing-plans 用于在已有规格说明（spec）或需求文档、且尚未触碰代码的阶段，为多步骤任务编写一份详尽的实现计划。它假设执行计划的工程师虽是熟练开发者，但对我们代码库几乎没有上下文，对问题领域和工具链了解甚少，且对良好测试设计的掌握有限。因此计划必须把所有必要信息都写清楚，让执行者无需额外猜测即可按步骤推进。
主要能力
- 范围检查（Scope Check）：若规格涉及多个相互独立的子系统，说明本应在 brainstorming 阶段拆分为子项目规格；若未拆分，则建议按子系统拆成多份计划，每份计划都应能独立产出可运行、可测试的软件。
- 文件结构规划（File Structure）：在定义任务之前，先梳理将创建或修改哪些文件、每个文件负责什么，以此锁定分解决策。要求设计边界清晰、接口明确的单元，每个文件职责单一；偏好小而专注的文件；同时改动的文件应放在一起，按职责而非技术层拆分；在既有代码库中沿用现有模式，若正在修改的文件已变得臃肿，可将拆分纳入计划。
- 小块任务粒度（Bite-Sized Task Granularity）：每个步骤只做一个动作（2-5 分钟），例如「写失败的测试」「运行确认它失败」「实现最小代码让测试通过」「运行测试确认通过」「提交」。
- 计划文档头部：每份计划必须以固定头部开头，包含供代理执行者使用的必备子技能提示、复选框语法的步骤跟踪、目标（一句话）、架构（2-3 句）、技术栈及分隔线。
- 任务结构：每项任务列出 Files（创建、修改、测试的精确路径）与带复选框的步骤，步骤中包含实际代码块、运行命令、预期输出和提交命令。
- 禁止占位符（No Placeholders）：不得出现「TBD」「TODO」「稍后实现」「补充细节」等；不得只描述而不给出代码；不得写「为上述内容编写测试」而不附实际测试代码；不得写「同任务 N」而不重复代码；不得引用任何任务中都未定义的类型、函数或方法。
- 自审（Self-Review）：写完计划后，需自己对照规格复查三项——规格覆盖（逐个需求能否对应到任务，列出缺口）、占位符扫描（找出上述红旗模式并修正）、类型一致性（后续任务使用的类型、方法签名、属性名是否与前面定义一致，例如一处叫 clearLayers() 另一处叫 clearFullLayers() 即为 bug）。发现问题就地修正。
- 执行交接（Execution Handoff）：保存计划后提供两种执行方式——子代理驱动（推荐，每个任务派发全新子代理，任务间进行审查，迭代快）或内联执行（在本次会话中借助 executing-plans 批量执行并在检查点审查）。
使用方式
开始时应声明：「I'm using the writing-plans skill to create the implementation plan.」并建议在专门的工作树（由 brainstorming 技能创建）中运行。计划默认保存到 docs/superpowers/plans/YYYY-MM-DD-<feature-name>.md，用户对计划位置的偏好可覆盖该默认值。若选择子代理驱动，需使用 superpowers-ruby:subagent-driven-development（每个任务全新子代理加两阶段审查）；若选择内联执行，需使用 superpowers-ruby:executing-plans（批量执行并在检查点审查）。
适用场景
当你已有针对多步骤任务的规格或需求，并希望在动代码之前先产出结构化、可逐步执行的实现计划时使用。计划需遵循 DRY、YAGNI、TDD 和频繁提交原则；始终给出精确文件路径，每步若改动代码都展示代码，并给出确切命令及预期输出。
限制
本次资料未提供该技能的收费、价格、平台支持范围、效果数据或性能指标。除文档中明确的默认计划保存路径与可被用户偏好覆盖外，其余自定义配置项暂未提供。