Writing Plans（撰写实现计划）
把需求拆成假设执行者对代码库一无所知也能照做的、每步 2-5 分钟的具体任务，杜绝「TBD」「补充细节」类占位符
明确面向已有规格或需求、且即将进行多步骤开发的工程师或编码代理；通过文件映射、任务拆分、接口说明、测试步骤和提交步骤提供较高的实际任务价值。边界也有体现，例如要求多子系统拆分并避免YAGNI，但未说明何时不应使用该技能、如何处理非软件任务或极小改动，因此保守给分。
规则较具体且可重复，包括固定的计划路径格式、任务粒度、精确文件路径、TDD循环、预期测试结果和自审清单。可靠性受限于对代码库、测试框架和代理能力的假设，以及对using-git-worktrees、executing-plans或subagent-driven-development等外部技能的依赖；没有提供失败恢复、冲突处理或计划保存失败的处理方案，也没有该技能自身的行为测试证据。
技能主要生成计划，未显示恶意行为、凭据窃取或隐蔽外传；同时通过要求测试、审查、用户选择执行方式和避免重构来降低风险。可是它要求保存文件、频繁提交并可能把精确的git commit作为计划步骤，缺少明确的提交前用户确认、回滚策略、敏感数据处理规则和高风险操作升级条件。该技能本身未描述网络、凭据或生产环境边界。
技能文本对输出结构、任务接口、测试命令、预期结果和自审步骤有较好的可追溯性，且明确要求区分规格覆盖和占位符扫描。证据仍主要是规范性文字，没有该SKILL.md的执行记录、专门测试、评测结果或独立佐证；仓库测试文件不能证明这个选定技能已经被测试，因此不能把其作为独立验证。
触发条件、起始公告、默认保存位置、计划头部、任务模板和执行交接格式都较清楚，工程师可以据此形成可操作的计划。缺少最小输入示例、不同语言或项目类型的兼容性说明、测试工具不可用时的替代方案、成本预估和退出条件；对用户偏好覆盖默认路径有说明，但其他配置和故障排查不足。
仓库提供MIT许可、版本元数据和社区问题渠道，但这些是仓库级信息，不能充分证明选定技能自身的版本、变更记录、维护责任或更新路径。发布者在给定信息中未通过FollowSkills企业注册表验证，身份按未知处理；没有因品牌加分，也没有因此扣分。技能文件仅有名称和描述元数据，缺少版本标记、兼容性声明和维护说明。
- 在执行计划中的写文件或git提交步骤前，要求用户明确确认范围、目标分支和是否允许提交；为部分完成或测试失败定义回滚和暂停规则。
- 不要把仓库级测试、README声明或发布者身份当作该SKILL.md已执行或已验证的证据；应补充针对技能行为的静态或行为评测。
- 使用前确认目标项目的实际测试命令、目录结构和工具链；若无法提供精确代码或测试预期，应暂停并请求更多上下文，而不是生成占位内容。
- 对包含凭据、个人数据、生产配置或外部系统操作的任务增加敏感信息审查和人工审批步骤。
它能做什么 & 适用场景
把已批准的设计/需求转成一份足够详细的实现计划，假设读这份计划的工程师对这个代码库和领域一无所知、品味也一般。要求每个任务都精确到文件路径、完整代码、测试步骤，明确列出禁止出现的占位符类型（「待定」「添加合适的错误处理」「跟任务N类似」等），并且计划写完后要对着原始需求做一次自查，逐条确认覆盖、找占位符、核对前后任务之间类型/签名是否一致。
先做文件结构规划：明确哪些文件要新建/修改，每个文件职责单一，经常一起改的文件放在一起；任务粒度上，一个任务是「自带完整测试循环、值得一次独立评审」的最小单位；每个计划开头必须有固定的头部（目标、架构、技术栈、全局约束——约束条款要从需求里逐字复制，而不是转述）；每个任务要写清楚创建/修改哪些文件（含行号）、消费上游任务的哪些接口、产出给下游任务用的接口、每一步都是 2-5 分钟的具体动作（写测试→跑测试确认失败→写最简实现→跑测试确认通过→提交），代码块必须是完整代码而不是描述；写完后做自查——需求覆盖度、占位符扫描、跨任务的类型一致性；最后向用户提供两种执行方式选择（subagent-driven-development 或 executing-plans）。
- brainstorming 阶段的设计已经获批，需要转成一份可以直接照着做的、任务粒度精确到分钟级的实现计划
- 计划里某个任务写成了「参照任务3的做法」而不是把代码重复写一遍——按 SKILL.md 的规则这是计划失败，要求补全
- 写完计划后对照原始需求做逐条自查，发现某个需求点没有对应任务，回头补上而不是留到执行阶段才发现缺口
优缺点一览
- 明确列出禁止出现的占位符类型（TBD、添加适当的验证、参照某任务）并说明为什么——执行者可能是乱序读任务的独立 agent，「参照任务N」这种引用对它没有意义
- 任务结构模板里强制要求「消费的接口/产出的接口」两个字段，让跨任务的接口一致性成为写计划时就要处理的问题，而不是留到执行阶段才发现类型对不上
- 计划头部要求把约束条款「逐字复制」而不是转述，减少传话过程中丢失精确数值/格式要求的风险
- 只在会自动读取和遵循 SKILL.md 指令的 harness 里可靠工作（Claude Code、Codex CLI 等）；纯聊天式界面里等于一份说明文档，需要人工照做。
- 对每一步都要求完整代码而非描述，计划文档本身会写得很长，对简单需求可能显得过度工程化
- 计划质量高度依赖上游 brainstorming 阶段设计的完整度，如果设计本身有空白，这个 skill 不会主动补齐领域知识空白，只会忠实地把空白也变成计划里的空白
如何安装
作为 obra/superpowers 插件的一部分安装，不能单独安装某一个 skill：
- Claude Code：官方市场
/plugin install superpowers@claude-plugins-official；或先注册 Superpowers 自建市场/plugin marketplace add obra/superpowers-marketplace，再/plugin install superpowers@superpowers-marketplace - 也支持 Antigravity、Codex App/CLI、Cursor、Factory Droid、GitHub Copilot CLI、Kimi Code、OpenCode、Pi 等 harness，具体命令见仓库 README
装好后这个 skill 会和其余 13 个 Superpowers skill 一起启用，由 using-superpowers 统一引导、按场景自动触发，无需单独调用。
如何使用
在 brainstorming 阶段设计获批之后自动触发，用来把设计转成结构化的任务清单，写完计划后引导用户在 subagent-driven-development 和 executing-plans 之间选择执行方式。
对比同类
跟一份粗粒度的任务列表（比如「实现用户认证」「加前端页面」这种大颗粒条目）相比，这个 skill 产出的计划粒度精确到「写这一段测试代码、跑这条命令、期望这个输出」，理论上大幅降低了执行者（尤其是独立子代理）需要自行补全信息、也就更容易出现理解偏差的空间。