用途
writing-plans 用于在动手改代码之前，为多步骤任务编写一份完整的实施计划。适用前提是你已经有规格（spec）或需求，且任务需要分多步完成。它的核心假设是：执行者是一位熟练的开发者，但对我们这套工具链和问题领域几乎一无所知，也不太懂好的测试设计。因此计划必须把这个工程师需要知道的一切都写清楚。
开始时应声明：“I'm using the writing-plans skill to create the implementation plan.” 该技能建议在专门的工作树（worktree，由 brainstorming 技能创建）中运行。
主要能力
范围检查：如果规格覆盖多个相互独立的子系统，本应在 brainstorming 阶段拆分为子项目规格；若未拆分，应建议拆成多个计划，每个子系统一个计划。每个计划都应能独立产出可运行、可测试的软件。
文件结构规划：在定义任务之前，先规划哪些文件会被创建或修改、每个文件负责什么。设计具有清晰边界和明确接口的单元，每个文件承担单一明确职责。倾向使用更小、更聚焦的文件；一起变更的文件应放在一起，按职责而非技术分层拆分。在已有代码库中遵循既有模式，不单方面重构；但如果要修改的文件已经变得难以管理，把拆分纳入计划也是合理的。
细颗粒度任务：每个步骤是一次动作（2-5 分钟），例如“写失败测试”“运行确认它失败”“实现最小代码让测试通过”“运行测试确认通过”“提交”。
计划文档头部：每份计划都必须以固定头部开始，包含：功能名 Implementation Plan 标题、针对 agentic workers 的 REQUIRED 说明（优先使用 superpowers:subagent-driven-development，否则 superpowers:executing-plans；步骤用复选框 - [ ] 跟踪）、Goal（一句话说明要构建什么）、Architecture（2-3 句说明方法）、Tech Stack（关键技术/库）。
任务结构：每个任务包含 Files 段（Create/Modify/Test 的精确路径，Modify 需带行号范围），随后是以复选框列出的步骤，每步包含说明、代码块、需运行的精确命令及预期输出。
使用方式
计划默认保存到：docs/superpowers/plans/YYYY-MM-DD-<feature-name>.md，用户对计划位置有偏好时覆盖此默认值。
计划编写时要记住：始终给出精确文件路径；计划中包含完整代码（而不是“添加校验”这类描述）；给出精确命令与预期输出；用 @ 语法引用相关技能；遵循 DRY、YAGNI、TDD 与频繁提交。
计划评审循环：每完成一块（chunk）计划后，派发 plan-document-reviewer 子代理（见 plan-document-reviewer-prompt.md），提供精心构造的评审上下文（绝不使用会话历史），并给出块内容与规格文档路径。若发现 ❌ 问题，就在该块中修复并重新派发评审，重复直到 ✅ 通过；通过后进入下一块（最后一块则交接执行）。块边界使用 ## Chunk N: <name> 标题界定，每块不超过 1000 行且逻辑自洽。循环指导：由写计划的同一代理修复以保留上下文；若循环超过 5 次则提交人工指导；评审意见仅供参考，若认为反馈不正确可说明分歧。
适用场景
适用于有规格或需求、需要多步骤实施、且在写代码之前希望先产出详尽可执行计划的任务，尤其适合需要拆分为小步、按测试驱动方式推进的开发工作。
执行交接
计划保存后提示：“Plan complete and saved to docs/superpowers/plans/<filename>.md. Ready to execute?”若运行环境支持子代理（如 Claude Code），REQUIRED 使用 superpowers:subagent-driven-development，不提供选项——子代理驱动是标准做法，每个任务使用全新子代理加两阶段评审。若环境不支持子代理，则在当前会话用 superpowers:executing-plans 执行，分批执行并设检查点供评审。
限制
资料未说明具体收费、价格、平台支持范围及实际效果；除上述流程与约定外，未提供其他集成信息。