用途：在具备实现计划且任务大体彼此独立、并希望停留在当前会话时，用子代理驱动方式逐任务执行计划。核心做法是每个任务派发一个全新的子代理（隔离上下文），任务完成后进行两阶段审查：先审规格符合度，再审代码质量。
主要能力与流程：先建立隔离工作区（如需可用 superpowers-extended-cc:using-git-worktrees 创建），运行 scripts/sdd-workspace PLAN_FILE 得到该计划的私有目录，再读取计划及其 Spec 做预检扫描并写入台账。随后逐任务循环：记录 BASE，生成任务简报（scripts/task-brief PLAN_FILE N），派发实现者子代理（模板 ./implementer-prompt.md），实现者实现、测试、提交并自审；生成审查包派发任务审查者（./task-reviewer-prompt.md）；有问题则修复，必要时用限定范围的复审（./re-review-prompt.md）。全部任务完成后派发最终代码审查（../requesting-code-review/code-reviewer.md），最后走收尾流程（superpowers-extended-cc:finishing-a-development-branch）。
进度与恢复：用台账文件记录状态（完成、修复轮次、派发、裁决、挂起、阻塞等单行条目），以 shell 追加方式写入，不用编辑工具；会话压缩后以台账和 git 日志为准，避免重复派发已完成任务。
执行规则：连续执行，任务之间不停下来问“是否继续”；遇到冲突、歧义或计划缺陷时直接裁决并记录，而不是停下。只有四类情况才停：不可逆或破坏性操作、安全敏感操作、工作区之外需事先征询的副作用（如合并、推送到共享分支、发布），以及计划坏到每条前路都是猜测。
模型选择：按任务复杂度选用最经济的模型，机械任务用便宜快速模型，集成与判断任务用标准模型，架构、设计与审查用最强模型；修复轮次 4–5 升一档。派发时须显式指定模型。
适用与限制：适用于有实现计划、任务大体独立、同一会话内执行的场景；任务紧耦合、没有计划或缺 Spec 时不适用，此时应先人工执行或构思，没有 Spec 时裁决仅属临时。另需注意工作区为 git 忽略的暂存目录，git clean -fdx 会破坏它；台账只记录状态而非推理。费用、平台等细节资料暂未提供。