用途：在 Pi 会话中执行已存在的 3-PLAN.md 实施计划。核心原则是每个任务使用全新子代理，配合规格审查与质量审查，先验证再推进。
主要能力：定位并审阅计划，提取每个任务的目标、文件、验收标准、验证命令、依赖、步骤与提交说明；按依赖顺序逐任务派发实施子代理；处理实施状态（DONE、DONE_WITH_CONCERNS、NEEDS_CONTEXT、BLOCKED）；先做规格合规审查，再做代码质量审查；任务完成后标记状态；最后运行计划中的最终验证命令、检查 git 状态汇总差异，并向用户汇报验证证据、提交与剩余风险。
使用方式：用户提供计划路径，或使用已知的 ~/.pi/plans/... 任务文件夹中的 3-PLAN.md；审阅计划中的矛盾、缺失验证命令、不清晰任务或不安全提交说明，发现阻塞性疑问先向用户提出；确认不在 main 或 master 分支再实施，否则需获明确同意或创建/切换分支或工作树。任务跟踪优先用 @tintinweb/pi-tasks，不可用则用通用 Pi 任务工具，都没有则用 3-PLAN.md 中的 Markdown 复选框。默认一次只派发一个实施子代理，除非计划明确说明任务独立且文件安全可并行。三个提示模板：implementer-prompt.md、spec-reviewer-prompt.md、code-quality-reviewer-prompt.md，按技能目录解析路径。
适用场景：已有 3-PLAN.md、任务大多独立或顺序清晰、希望留在当前 Pi 会话作为协调者、且子代理工具可用时。若子代理工具不可用、任务紧密耦合需要连续实现上下文，或用户希望批量执行加人工检查点，则应改用 Pi 适配的 executing-plans 技能。
限制与禁忌：未经明确同意不得在 main 或 master 上开始实施；不得跳过规格合规审查或代码质量审查，也不得在规格审查通过前开始质量审查；存在未解决的严重或重要审查问题时不得推进；除计划明确声明外不得并行派发多个实施子代理；不要把实施者的自审当作独立审查；子代理失败时应派发聚焦修复子代理或询问用户，不要静默绕过。成本上，子代理调用次数与协调开销高于直接执行，换取更高把握和更早发现问题。