用途：在同一个会话中执行实现计划，把计划中的每个任务委派给具有隔离上下文的专用子代理，避免上下文污染，并让协调者保留自身上下文用于统筹。
主要流程：先读取计划、提取全部任务全文与上下文并建立待办列表；随后逐任务分派实现者子代理（implementer-prompt.md），实现、测试、提交并自审；再分派规格符合性审查子代理（spec-reviewer-prompt.md），确认代码符合规格；通过后分派代码质量审查子代理（code-quality-reviewer-prompt.md）。任一审查发现问题，由同一实现者子代理修复并重新审查，直到批准，再标记任务完成并进入下一任务。全部任务完成后分派最终代码审查子代理，最后使用 superpowers:finishing-a-development-branch 收尾。
使用方式：适用于已有实现计划、任务大多相互独立且留在当前会话执行的场景；若任务紧密耦合则先手动执行或头脑风暴，若需并行会话则改用 executing-plans。任务之间不暂停确认，持续执行；仅在被阻塞、出现真正阻碍进展的歧义或全部任务完成时停止。
模型选择：机械性任务用较快较便宜的模型，涉及多文件协调、调试的集成与判断任务用标准模型，架构、设计和审查任务用最强模型。
限制与注意：不得在未获明确同意时于 main/master 分支开始实现；不得跳过任一审查、不得并行分派多个实现子代理、不得让子代理自行读取计划文件；规格符合性通过前不得开始代码质量审查，审查未解决前不得进入下一任务；子代理提问须完整回答，NEEDS_CONTEXT 需补充上下文后重派，BLOCKED 需据因改用更强模型、拆分任务或上报，不得无变化地强迫同一模型重试。成本在于每任务会有实现者加两名审查者等更多子代理调用，且协调者需预先提取全部任务，但可更早发现问题。