用途
子智能体驱动开发用于在当前会话中执行包含独立任务的实现计划。它通过为每个任务分派一个全新的实现子智能体来执行计划：每个任务完成后做一次任务审查（规格合规性 + 代码质量），全部任务结束后再做一次覆盖整个分支的宽范围审查。
核心原则：每个任务一个全新子智能体 + 任务审查（规格 + 质量）+ 结尾宽范围审查 = 高质量、快速迭代。
主要能力
- 为每个任务分派具有隔离上下文的专用实现子智能体，避免上下文污染。
- 每个任务后执行任务审查，检查规格合规性与代码质量。
- 全部任务完成后执行覆盖整个分支的最终代码审查。
- 通过账本文件记录进度，支持在上下文压缩后恢复。
- 设有修复循环（每任务最多五轮）与熔断机制。
- 按任务复杂度选择模型，以节省成本、提升速度。
使用方式
何时使用
当有实现计划、任务基本独立、且伙伴未选择内联执行或存在子智能体工具时使用本技能。若伙伴选了内联执行或没有子智能体工具，则使用 executing-plans；若没有实现计划或任务紧密耦合，则手动执行或先头脑风暴。
准备
确保工作发生在隔离的工作区里：用 using-git-worktrees 创建一个，或核实已有的那个。没有人类伙伴的明确同意，绝不在 main/master 分支上开始实现。
每个计划拥有自己的工作区：技能启动时运行 bash scripts/sdd-workspace PLAN_FILE，它会打印这个计划专属的、被 git 忽略的目录（位于 <repo-root>/.superpowers/sdd/ 之下），本计划的一切产物都放在那里：账本、简报、报告、审查包。
到 <工作区>/progress.md 查本计划的账本。创建账本时，把它的身份写在第一行：# SDD ledger — plan: <计划文件路径>。
把计划读一遍，记下它的上下文和全局约束，并为每个任务建一条待办。如果计划点名了一份规格（Spec），把规格也读了。
在分派任务 1 之前，把计划通扫一遍找冲突，把结果写成一张表并写进账本。在执行开始之前就对你找到的每一条作出裁决，并把每条裁决记进账本。
模型选择
在能胜任的前提下，为每个角色选用最弱的模型，以节省成本、提升速度。机械性实现任务用快而便宜的模型；集成与判断类任务用标准模型；架构与设计类任务用可用的最强模型；审查任务按 diff 的体量、复杂度和风险来缩放；修复循环的升级（第 4-5 轮）用比卡住的实现者至少高一档的模型。分派子智能体时永远显式指定模型。
任务循环
-
分派实现者：分派之前记录 BASE（
git rev-parse HEAD）。运行bash scripts/task-brief PLAN_FILE N抽取任务简报。分派应包含任务位置、简报路径、前序任务的接口和决策、对歧义的裁定、报告文件路径和报告契约。绝不并行分派多个实现子智能体。 -
处理报告：实现子智能体会回传 DONE、DONE_WITH_CONCERNS、NEEDS_CONTEXT 或 BLOCKED 四种状态之一，分别处理。
-
审查任务：运行
bash scripts/review-package PLAN_FILE BASE HEAD，把打印出的文件路径交给审查者。审查者的输入包括简报文件、报告文件、审查包，外加约束该任务的全局约束。 -
修复循环：当审查报告规格 ❌、任何 Critical 或 Important 发现、或确认为真实缺口的 ⚠️ 条目时触发。一轮修复 = 一次修复分派 + 一次定向复审。每个任务最多五轮。第 1-3 轮唤回原来那个实现者；第 4-5 轮用更强的模型分派一个全新实现者。
-
完成任务：当审查干净地返回，往账本追加完成行，标记待办完成，继续下一个。
最终审查
运行 bash scripts/review-package PLAN_FILE MERGE_BASE HEAD，把打印出的路径放进最终审查的分派里。用可用的最强模型分派，使用 requesting-code-review 的 code-reviewer.md。如果最终审查返回了发现，用一个修复子智能体带着完整的发现清单去分派，然后对这波修复跑恰好一次定向复审。
收尾
在删除任何东西之前，把账本里每一条含 Ruling: 的记录都收集起来，放进最终消息的「我作出的裁决」一节里。当覆盖整个分支的最终审查干净、且它的修复已合并时，删除本计划的工作区（rm -rf <工作区>）。使用 finishing-a-development-branch。
适用场景
- 有实现计划，且计划中的任务基本相互独立。
- 需要为每个任务提供隔离上下文，避免上下文污染。
- 需要在任务级别进行规格合规性与代码质量审查。
- 需要在全部任务完成后进行覆盖整个分支的宽范围审查。
限制
- 任务紧密耦合时不适用，应手动执行或先头脑风暴。
- 没有子智能体工具时，应使用 executing-plans（内联执行）。
- 没有人类伙伴的明确同意，绝不在 main/master 分支上开始实现。
- 只有四件事会让流程停下：不可逆或破坏性的操作；涉及安全的动作；这个工作树之外、按惯例应当先问一声的副作用（合并、推送到共享分支、发布）；以及一个坏到每条前进路径都只能靠猜的计划。
- 每个任务最多五轮修复，触及上限时逐条裁定未解决的发现。
- 最终审查后没有第二波修复。