implement-with-subagents

使用子 Agent 实现

核心原则

根据完整任务图，一次性确定实现任务的归属。若只有一个任务项，或任务图中没有并行节点，则由主控负责；若任务图中存在并行工作，则将每个任务项都分配给工作 Agent，包括顺序执行的首尾任务。两种模式都要保留依赖检查和独立的最终审查。委派任务时，修复工作由实现负责人承担，并复用数量受限的工作区检出。

选择模式

• 仅在评估提供的编排而不运行时使用 review；该模式没有外部依赖。
• 仅在执行提供的工单或计划任务时使用 implement。此模式不会调用单独的 /implement 技能。

审查流程

1. 仅检查允许访问的仓库和编排状态。不要启动 Agent、编辑、提交、更改分支、执行工作树生命周期操作或联系远程服务。
2. 评估完整任务图及其记录的预检选择。若单个任务项或没有并行节点的任务图被强制分配给工作 Agent，则指出这一点；这些情况下由主控实现并自行审查，不进行单独的任务验收。只要任务图中存在并行节点，就将每个任务项都分配给工作 Agent，包括顺序执行的首尾任务。对于委派执行，评估任务范围内的提交、负责人自审、针对性验证，以及集成前的控制器验收。仅有负责人报告不满足任务验收要求。不同工作树并不会让共享文件编辑，或依赖于尚未集成代码的工作变得独立。将提供的就绪状态、独立性和容量视为权威信息：委派执行时，并发分派整个就绪前沿。若状态未显示某项前置条件缺失，包括测试切入点、tdd 和审查者能力，则应在执行时检查，不应据此阻止分派。检查优先复用的分配方式、活动写入者使用不同槽位，以及只读辅助人员使用现有检出。
3. 只有在每项前置任务的任务提交都已无冲突地集成、委派任务已先行验收，且受影响的检查已在该确切集成提交上重新运行并通过后，才释放依赖任务。任务分支上的检查通过并不足够。普通合并后，不要要求主控进行第二次酌情验收；若跨文件交互、共享接口变更或合并解决方式可能改变语义，则检查合并后的差异。只有检查确认其输入和环境在集成提交上未变时，才可复用已通过的检查。已验收的任务项已完成，不得再次分配。
4. 报告下一步操作、依据以及任何验收缺口。实现前停止。检查发布资格、安全退役和检出状态，但不要修改它们。若依赖图无效或存在不安全的重叠，则暂停分派，并将具体问题交还计划负责人；不要擅自安排执行顺序或删除任务及依赖关系。指出必须在集成提交上重新运行的任何检查，即使另一个阻碍也会导致无法分派。

实现模式

前置条件

在实现之前，确定会改变行为的事项，以及用户认可的测试切入点。 这些事项的负责人会直接使用单独安装的 tdd 技能。如果某个行为事项没有经过认可的切入点，应先取得同意，再实现该事项；如果 tdd 不可用，则在行为相关工作开始前停止。 文档及其他没有实际测试切入点的事项，应改用有针对性的验证。切勿隐式安装依赖。

在任一路径开始实现前，都要建立独立的只读审查能力；不要启动仅用于建立能力的审查者。最终审查时，使用一个全新的 Agent：不得进行任何写入，也不得继承实现对话；向其提供一份自包含的简报，其中包括已批准的源内容、计划、仓库规范、固定基线和确切的候选头提交。要求其依据需求和规范，给出带证据的发现以及 ship、fix-first 或 rethink 判定；覆盖情况说明应遵循行为审查与修复。实现期间也要应用该参考文档，处理相关边界修复和浏览器故障诊断；PR 反馈不属于此工作流。无需设置外部审查技能或跟踪工具。如果无法进行独立审查，应报告缺少的能力；绝不可免除最终审查。只有在风险不同或范围较大、足以证明需要单独分配任务时，才增加审查者。

开始实现前，请完整阅读实现模式流程。该流程负责预检、任务分派、负责人任务说明、任务验收、集成、修复和最终验证。如果依赖项、任务范围内的提交或能力门槛无法满足，则停止。在委派运行中，应等待工作者有空，而不是改由负责人亲自实现。

完成门槛

在 review 模式下，只有完成非变更性评估、提供证据并说明任何验收差距后，才算完成。在 implement 模式下，只有在每个已排队事项都有任务范围内且经过自我审查的提交（委派执行时，须在集成前验收），所有受影响的检查及完整必需测试套件都在最终集成头提交上通过、合并后的审查仍然有效，并且集成工作区干净时，才算完成。保留起始工作区中的所有无关用户工作。逐一说明本次运行创建的工作者工作区是已通过验证回读后退役，还是有理由予以保留；保留任务分支引用。即使代码验证已通过，只要符合条件的退役失败或缺少清理能力，工作流仍未完成。报告事项与提交的对应关系、确切的集成头提交、最终验证和审查证据、工作区处置情况以及任何阻碍；否则，应在首个未完成的门槛处停止。PR 和跟踪工具交付不属于此技能。