Subagent-Driven Development（子代理驱动开发）
同一会话内为每个任务派发全新子代理实现，配两阶段审查，用进度台账防止压缩后重复劳动
为已有实施计划且任务大体独立的当前会话提供清晰的多代理执行与审查流程；每项任务都有实现者、任务审查和最终分支审查，具有明确的质量优势。边界也有说明，例如紧密耦合任务、并行会话和缺少计划时应使用其他流程。未提供量化成功率或适用规模证据。
流程包含任务简报、报告文件、进度账本、状态处理、基于提交范围的审查包和修复后复审，支持一定程度的可恢复性与复现性。可靠性依赖当前代理具备子代理调度、文件读写、Git、测试和相关共享技能；本文件未定义这些依赖的兼容性、失败重试上限或工具不可用时的替代路径，也没有该技能自身的执行测试证据。
要求未经明确同意不得在主分支开始实现，并要求使用隔离工作树、审查循环和完成分支流程，降低直接破坏代码的风险。实现者会修改文件、运行测试并提交，且流程要求连续执行、不在任务间向人类确认，外部影响和错误代理行为的即时遏制有限。未明确列出权限边界、敏感数据处理、提交回滚步骤或任务级用户批准点。
文本对过程控制和报告格式有较强的可追溯设计，包括基础提交、头提交、差异包、测试报告和账本记录。但这里没有该技能的行为测试、运行结果、独立评估或跨环境验证；示例中的测试通过是说明性内容而非本次审查可验证的证据。流程要求代理自报测试结果，独立复核测试真实性的机制不足。
触发条件、适用场景、流程图、状态定义、模型选择指导、文件交接规则和提示模板都较完整，熟悉该框架的操作者可以按步骤执行。首次使用者仍需了解计划文件、工具调用、Git 工作树、共享技能和 scripts 路径；输入输出、运行成本、不同代理平台兼容性、工具缺失时的故障排查和安全退出说明不完整。
仓库上下文提供 MIT 许可证和版本 6.1.1，但选定技能文件本身没有版本、变更记录或维护责任说明。它引用多个其他技能、模板和脚本，依赖关系可能随仓库变化而失效；未提供该技能专门的更新策略、兼容性矩阵或响应路径。发布者未被企业注册表验证，因此不能提供额外治理加分。
- 连续执行规则可能在长任务中减少用户介入；在涉及高影响代码、生产配置或敏感数据时，应在任务边界增加人工批准和停止条件。
- 在采用该流程前，应确认相关共享技能、脚本、子代理工具和 Git 工作树能力存在且版本兼容。
- 不要把实现者报告或示例中的测试通过当作独立验证；应核实测试命令、覆盖范围、输出和实际提交差异。
- 流程要求提交代码但未给出细化的回滚操作；应在执行前确认分支、工作树、提交和未提交改动的恢复方案。
它能做什么 & 适用场景
Superpowers 工作流里承担实际编码的核心 skill：为计划里的每个任务派发一个全新的实现子代理（不继承会话历史），完成后生成 diff 包、派发任务评审子代理做「规格符合度」+「代码质量」两阶段审查，通过才标记完成，全部任务做完后再做一次整分支的最终评审。专门设计了一套「进度台账」机制应对长会话被压缩（compaction）后 Claude 忘记做过什么，靠 git log 和台账文件而不是记忆恢复进度，这是本文档篇幅最长（418 行）也是规则最密集的一个 skill。
读计划、记全局约束、建 todo；每个任务：派发实现子代理（用 implementer-prompt.md 模板）→ 子代理有疑问就答疑 → 子代理实现/测试/提交/自查 → 生成评审包（review-package 脚本）→ 派发任务评审子代理（task-reviewer-prompt.md 模板）→ 未通过则派修复子代理并重新评审 → 通过后在台账追加一行「任务N完成」；全部任务完成后派发最终整分支评审；最后交给 finishing-a-development-branch 收尾。还包含模型分级策略（机械任务用便宜模型、需要判断的任务用中档、架构设计用最强模型）、给评审子代理构造 prompt 的详细规则（不能预判评审结论、不能让评审重跑实现者已经跑过的测试、约束条款要从计划里逐字复制）、以及「产物用文件传递而不是塞进上下文」的具体做法。
- 有一份 writing-plans 产出的计划，任务之间基本独立，且想留在当前会话里快速迭代（不想切到新会话）
- 长时间会话中途被压缩，需要靠进度台账和 git log 恢复「做到哪了」而不是凭记忆瞎猜继续
- 根据任务复杂度自动选择子代理用什么档位的模型（机械改动用便宜模型、架构判断用最强模型）控制成本
优缺点一览
- 两阶段审查（规格符合度 + 代码质量）+ 全流程结束后的整分支审查，比大多数「写完就完」的工作流严谨得多
- 进度台账机制专门解决了 agent 长会话的一个真实痛点——上下文压缩后忘记进度、重新执行已完成任务，是很实际的工程考量
- 对评审 prompt 的构造给了非常具体的反模式清单（不许预判结论、不许要求评审重跑测试、约束条款必须逐字复制而不是转述），减少评审子代理被「带节奏」的空间
- 只在会自动读取和遵循 SKILL.md 指令的 harness 里可靠工作（Claude Code、Codex CLI 等）；纯聊天式界面里等于一份说明文档，需要人工照做。
- 418 行是这批 skill 里最长的，规则密度很高，人工通读理解成本不低
- 整套流程涉及大量子代理调用（每任务至少 2 次，问题多时更多），token 和时间成本明显高于直接自己写代码，适合看重质量胜过速度的场景
如何安装
作为 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 统一引导、按场景自动触发，无需单独调用。
如何使用
当你有一份多任务的实现计划、任务之间相对独立、且想在当前会话内快速迭代时使用；跟 executing-plans 二选一，不建议同时用于同一份计划。
对比同类
跟 executing-plans 相比，这个 skill 是「重装版」：子代理隔离更彻底、审查更严格（两阶段+终审）、有台账防丢进度，但代价是更多子代理调用和更高 token 消耗；executing-plans 更轻量，适合没有子代理能力或想要更少开销的场景。