用途
subagent-driven-development 用于在当前会话中执行一份实施计划（implementation plan），前提是计划中的任务大体相互独立。它为每个任务分派一个全新的实施子智能体，任务完成后立即进行任务审查（规格符合性 + 代码质量），并在全部任务结束后做一次覆盖整个分支的广义审查。
何时使用
依据技能中的决策流程：有实施计划且任务基本独立时，若用户选择了内联方式或没有子智能体工具，则走 executing-plans（内联执行）；否则使用本技能。若没有计划，则应先进行手动执行或头脑风暴。
与内联执行计划相比的差异：本技能为每个任务使用全新子智能体（避免上下文污染），而不是用同一个上下文做所有任务；在每个任务后即进行审查（规格 + 质量），而不只是在最后审查；代价是每个任务和每次审查都消耗一份新上下文，而内联方式只消耗一份上下文加一个最终审查者。两者都在当前会话中运行，共享同一计划工作区与 ledger，并且都不在任务之间暂停。
流程概览
准备阶段：创建工作区（使用 superpowers:using-git-worktrees 创建或验证现有工作区），进行 ledger 检查，读取计划，做一次预检审查。
每个任务的循环：分派实施者子智能体（./implementer-prompt.md）；实施者可提问，回答并提供上下文；实施者实现、测试、提交、自审；生成审查包并分派任务审查者（./task-reviewer-prompt.md）；若规格通过且质量获批则追加完成记录并标记 todo 完成；否则若发现与计划文本冲突，先裁决并记入 ledger；进入修复轮次（共 5 轮，R≤3 时继续由原实施者修复，R≥4 时换新实施者并使用更强模型）；分派限定范围的再审查（./re-review-prompt.md）；若所有发现都已处理则完成，否则检查是否到第 5 轮；到第 5 轮则对每条未决发现进行裁决；若有承载性发现则裁决并继续，仅在所有前进路径都靠猜时停止；否则将发现连同裁决存入 ledger。
全部任务完成后：分派最终代码审查者（../requesting-code-review/code-reviewer.md）；若有最终发现，执行一次修复分派、一次限定范围再审查并裁决残余项；最终审查干净后删除本计划的工作区；最后使用 superpowers:finishing-a-development-branch。
准备细节
确保工作发生在隔离工作区中；未经用户明确同意，绝不在 main/master 分支上开始实施。对话记忆无法在压缩后保留，真实会话中曾出现控制器失忆后重新分派整个已完成任务序列的情况，这是观察到的最昂贵失败，因此进度必须记录在 ledger 文件中，而不仅记录在 todo 里。
每个计划拥有一个工作区：技能开始时运行 bash scripts/sdd-workspace PLAN_FILE，它会打印该计划的 git 忽略目录（位于 <repo-root>/.superpowers/sdd/ 下），用于存放本计划的全部工件：ledger、brief、报告、审查包。不得读写其他计划的目录。
在 <workspace>/progress.md 检查本计划的 ledger。若其首行命名了你的计划文件，则带有 “Task <N>: complete” 行的任务已完成，不要重新分派，从第一个没有该行的任务继续。末行是修复轮次的任务处于循环中，从下一轮继续。首行命名其他计划文件的 ledger，或位于旧扁平路径 .superpowers/sdd/progress.md 的游离 ledger，属于其他计划的进度，保持原样并新建自己的 ledger。ledger 首行写明身份：# SDD ledger — plan: <plan file path>。ledger 是恢复地图：它记录的提交在 git 中真实存在，即使上下文已不记得创建过；压缩后应信任 ledger 和 git log 而非自己的回忆。git clean -fdx 会销毁工作区（它是被 git 忽略的临时区），若发生可从 git log 恢复。
读一次计划，记录其上下文和全局约束，为每个任务创建一个 todo。若计划指定了 Spec，也要读取：spec 是计划据以论证的权威，计划内部的冲突依据 spec 解决。无法访问 spec 的计划要在 ledger 中注明，此时所作的裁决为临时性。
分派任务 1 之前，扫描一次计划以查找冲突：任务之间或任务与计划全局约束相矛盾之处；计划明确要求但审查标准视为缺陷的内容（例如不做任何断言的测试、逻辑块的逐字复制）。扫描输出应为一张表而非结论。对每一对共享文件或接口的任务各一行：两个任务、一方产出与另一方消费的对照、以及所发现的内容。每个任务各一行：其文本是否自洽——它规定的测试与其规定的代码、它创建的文件与其后续触碰的文件。没有这些行，就不能称“扫描是干净的”。把表写入 ledger。执行开始前对所有发现进行裁决——每条发现针对强制它的计划文本——并将每条裁决记入 ledger。若扫描干净则直接继续。
模型选择
使用能胜任各角色的最弱模型以节省成本并提高速度。机械性实现任务（孤立函数、清晰规格、1-2 个文件）使用快速廉价模型；大多数规格良好的实现任务都是机械性的。集成与判断任务（多文件协调、模式匹配、调试）使用标准模型。架构与设计任务使用最强可用模型；最终全分支审查也属此类，应以最强可用模型分派，而非会话默认模型。审查任务按同样的判断标准选择模型，并随 diff 的规模、复杂度和风险伸缩；小的机械性 diff 不需要最强模型，微妙的并发改动则需要。小修复 diff 的限定范围再审查使用廉价到中档模型。修复循环升级（第 4-5 轮）使用至少比卡住的实施者高一档的模型。分派子智能体时始终显式指定模型；省略模型会继承会话模型（往往是最强最贵的），从而悄悄破坏本条。轮次数比 token 价格更重要：墙钟时间和上下文成本随子智能体轮数增长，最便宜的模型在多步任务上常花 2-3 倍轮次，总体更贵。审查者和依据文字描述工作的实施者以中档模型为下限；当任务的计划文本包含要写的完整代码时，实现只是誊写加测试，用最便宜档；单文件机械修复也用最便宜档。任务复杂度信号（实现任务）：触及 1-2 个文件且有完整规格 → 廉价模型；触及多个文件且有集成关注点 → 标准模型；需要设计判断或广泛代码库理解 → 最强模型。
任务循环
批量处理小而同形的工作：当计划列出多个彼此独立、类型相同的小改动（同一处一行修复、常量变更、字段添加，跨文件重复）时，不要每个任务分派一个子智能体，而应编写一份分派 brief 列出每个文件及其改动，把整批交给单个子智能体，并把其 diff 作为一个单元审查。只有需要独立判断、独立测试或独立审查面的工作才一个任务一次分派。
粘贴进分派提示的一切，以及子智能体打印回的一切，都会在本会话余下的上下文中常驻，并在之后每一轮被重新读取；工件应以文件方式移交。
等待已分派的子智能体时：绝不用短超时轮询等待接口，也不要陷入一次静默无期限等待。当你有本地工作（更新 ledger、打包下一次审查、阅读报告）时继续工作，子结果会自行到达。真正空闲时，在有界时段内等待（在平台允许时每次五到十分钟），时段之间发布一行状态并核对活跃子项：列出它们，追查已完成但未报告的子项。有界时段保留长等待的几乎全部效率，同时保证卡住或丢失的子项在几分钟内而非会话结束时被发现。
分派实施者
分派前记录 BASE（git rev-parse HEAD），审查包与修复轮 diff 需要它。任务 brief：分派实施者前运行 bash scripts/task-brief PLAN_FILE N，它把任务的完整文本提取到唯一命名的文件并打印路径。组织分派时让 brief 保持为需求的唯一来源。分派内容应包含：(1) 一行说明本任务在项目中的位置；(2) brief 路径，以“先读这个——它是你的需求，其中的确切值需逐字使用”引入；(3) brief 无法知道的、来自早前任务的接口与决策；(4) 你对 brief 中任何歧义的解决；(5) 报告文件路径与报告约定。确切值（数字、魔法字符串、签名、测试用例）只出现在 brief 中。绝不要让子智能体读取整个计划文件。
报告文件：以 brief 命名实施者的报告文件（brief …/task-N-brief.md → report …/task-N-report.md），并把路径放进分派提示。实施者把完整报告写入该文件，只返回状态、提交、一行测试摘要和关切。
一份分派提示描述一个任务，而非会话历史。不要把累积的先前任务摘要（“Tasks 1-3 之后的状态”）粘贴进后续分派——真实会话中曾出现 42k 字符的分派，其中 99% 是粘贴的历史。
适用场景
适用于已有实施计划、任务基本独立、且环境中具备子智能体分派能力的开发会话，尤其适合需要高质量与快速迭代、并希望在长会话中抵御上下文压缩风险的实现工作。
限制
技能文本中未提供关于收费、价格、平台支持范围、具体安装步骤或效果保证的说明；这些事实暂未提供。停止条件严格限定为上文的四类情形。