用途：在当前会话内执行实现计划，通过子代理逐个完成任务，并在每个任务后做两阶段审查——先审查是否符合规范，再审查代码质量。核心原则是：每个任务使用全新子代理，配合规范与质量两阶段审查，从而兼顾质量与迭代速度。
前提：计划必须包含影响分析（Impact Analysis）。审查时是拿代码与计划比对，因此错误的计划会传播到每个任务。派发第一个实现者前先阅读计划，发现可疑之处应先与人类伙伴沟通，而不是在其基础上继续构建。
适用判断：有实现计划、任务基本独立、且希望留在当前会话中执行时适用；若无计划应先手工执行或头脑风暴，任务紧密耦合时应手工执行，若需并行会话则使用 executing-plans。与 executing-plans 相比，其特点包括：同一会话无上下文切换、每任务全新子代理避免上下文污染、每任务两阶段审查（先规范后质量）、无需人工逐步介入的更快迭代。
流程：读取计划并提取所有任务全文、记录上下文、创建 TodoWrite；随后对每个任务依次执行——派发实现子代理（./implementer-prompt.md），若其提问则先回答并提供上下文，再让其实现、测试、提交并自审；派发规范审查子代理（./spec-reviewer-prompt.md），确认代码符合规范，不符合则由同一实现者修复并重审；规范通过后派发代码质量审查子代理（./code-quality-reviewer-prompt.md），未通过则修复并重审；通过后在 TodoWrite 标记完成。所有任务完成后，派发最终代码审查子代理审查整体实现，并使用 superpowers:finishing-a-development-branch。
主要能力与优势：子代理自然遵循 TDD；每任务新鲜上下文、互不干扰；子代理可在工作前及工作中提问；控制器提供任务全文，避免子代理读文件的开销并精确裁剪上下文；自审加两阶段审查，规范审查防止过度或不足实现，质量审查保障实现质量，审查循环确保修复有效。
限制与成本：每个任务需要多次子代理调用（实现者加两个审查者），控制器需提前提取所有任务并做更多准备工作，审查循环会增加迭代次数；但可更早发现问题，通常比后期调试更省。
红线：绝不跳过任何一种审查；不在问题未修复时继续；不并行派发多个实现子代理；不让子代理自行读取计划（应提供全文）；不省略场景上下文；不忽视子代理提问；不接受规范上的“差不多”；不跳过复查；不用自审替代实际审查；规范未通过前不开始质量审查；任一审查有未决问题时不得进入下一任务。若子代理任务失败，应派发修复子代理并给出具体指示，不要手工修改以免污染上下文。
集成：需要工作流技能 superpowers:writing-plans（创建所执行的计划）、superpowers:requesting-code-review（审查者模板）、superpowers:finishing-a-development-branch（全部任务后完成开发）；子代理应使用 superpowers:test-driven-development。替代工作流为 superpowers:executing-plans（用于并行会话）。提示模板包括 ./implementer-prompt.md、./spec-reviewer-prompt.md、./code-quality-reviewer-prompt.md。