implement-with-subagents

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Implement with subagents

通过子代理完成实现工作

Keep orchestration and implementation ownership separate: the controller schedules, and one implementation subagent owns each independent work item through completion.

将编排与实现职责分离：控制器负责调度，每个独立工作项由一个实现子代理全权负责直至完成。

Procedure

流程

Read the repository instructions and inspect the current branch and worktree. Preserve unrelated changes. Stop before delegation when a task-scoped commit cannot be produced safely from the current state.
Resolve and read the installed
```
implement
```
skill. Treat it as a required dependency. If it is unavailable, stop before making changes and report the missing dependency; never reproduce its procedure from memory.
Build the work queue from the supplied tickets or plan tasks:
- preserve explicit boundaries and dependency order;
- treat an unsplit implementation request as one work item;
- keep checklist steps inside their containing work item; and
- group supplied items only when they cannot safely produce separate, behavior-preserving commits.
Process the queue sequentially on the current branch. Before each item, record
```
HEAD
```
and require the preceding item to be committed with a clean task-owned diff relative to the recorded pre-existing worktree state.
Select the portable Solver role for the next item and map it to the runtime's implementation-capable subagent type. Record the portable role and actual runtime selection when the environment exposes it. Spawn one owner. Do not implement any part of the item in the controller. If an implementation slot is temporarily unavailable, wait for capacity. If subagents cannot be started, stop and report the blocker rather than falling back to controller implementation.
Give the owner a decision-complete packet containing:
- the exact ticket or plan task and its acceptance criteria;
- the relevant specification and repository instructions;
- exclusive ownership of that work item on the current branch;
- the pre-existing worktree state that must be preserved;
- an instruction to invoke the installed
```
implement
```
  skill; and
- an instruction to return the commit, the evidence required by the installed
```
implement
```
  skill's current finish contract, and any unresolved blocker.
Wait for that owner to finish before starting another. Do not split its implementation across additional agents. When its result is incomplete, dirty, uncommitted, or fails a required check, send the evidence back to the same owner and let it repair its item. Stop on a material blocker the owner cannot resolve within the supplied contract.
Independently accept the item before advancing. Treat the owner's report as claims rather than acceptance evidence:
- verify
```
HEAD
```
  advanced by at least one task-scoped commit;
- inspect the complete commit range and diff from the recorded
```
HEAD
```
  to the current
```
HEAD
```
  for the work item's acceptance criteria and scope;
- rerun the verification requested by the user and repository for this item;
- confirm the returned evidence satisfies the installed
```
implement
```
  skill's current finish contract; and
- verify the task-owned diff is empty relative to the recorded pre-existing state.
Send every failed acceptance check back to the same owner, then repeat step 8. Start the next item only after acceptance passes. After the last item, run any final verification required by the user or repository that the item-level acceptance passes did not cover. If a later action changes files, return the changes to their owning subagent for validation and commit.

阅读仓库说明并检查当前分支和工作区。保留无关变更。如果无法从当前状态安全生成任务范围的提交，则在委派前停止操作。
查找并阅读已安装的
```
implement
```
skill。将其视为必需依赖项。如果该skill不可用，则在进行变更前停止操作并报告缺失的依赖项；绝不能凭记忆重现其流程。
根据提供的工单或计划任务构建工作队列：
- 保留明确的边界和依赖顺序；
- 将未拆分的实现请求视为一个工作项；
- 将检查清单步骤保留在其所属的工作项内；
- 仅当无法安全生成独立且保留原有行为的提交时，才对提供的项目进行分组。
在当前分支上按顺序处理队列。处理每个项目前，记录
```
HEAD
```
，并要求前一个项目已提交，且相对于记录的原有工作区状态，仅存在任务相关的干净差异。
为下一个项目选择可移植的Solver角色，并将其映射到运行时的可实现子代理类型。当环境暴露相关信息时，记录可移植角色和实际运行时选择。生成一个负责该项目的代理。控制器不得实现项目的任何部分。如果实现插槽暂时不可用，则等待可用容量。如果无法启动子代理，则停止操作并报告阻塞问题，而非退回到控制器实现。
向负责代理提供一个决策完整的数据包，包含：
- 确切的工单或计划任务及其验收标准；
- 相关规范和仓库说明；
- 当前分支上该工作项的专属所有权；
- 必须保留的原有工作区状态；
- 调用已安装的
```
implement
```
  skill的指令；
- 返回提交、
```
implement
```
  skill当前完成契约要求的证据，以及任何未解决阻塞问题的指令。
等待该负责代理完成后再启动下一个项目。不得将其实现拆分到多个代理中。当结果不完整、存在脏数据、未提交或未通过必要检查时，将证据返回给同一负责代理，让其修复该项目。如果负责代理无法在给定契约内解决重大阻塞问题，则停止操作。
在推进前独立验收项目。将负责代理的报告视为声明而非验收证据：
- 验证
```
HEAD
```
  至少前进了一个任务范围的提交；
- 检查从记录的
```
HEAD
```
  到当前
```
HEAD
```
  的完整提交范围和差异，确认是否符合工作项的验收标准和范围；
- 重新运行用户和仓库针对该项目要求的验证；
- 确认返回的证据满足已安装的
```
implement
```
  skill当前完成契约的要求；
- 验证相对于记录的原有状态，仅存在任务相关的差异且已提交（即工作区干净）。
将所有未通过的验收检查返回给同一负责代理，然后重复步骤8。仅当验收通过后才启动下一个项目。最后一个项目完成后，运行用户或仓库要求的任何最终验证，确保项目级验收未覆盖的部分也符合要求。如果后续操作修改了文件，将变更返回给所属子代理进行验证和提交。

Ownership boundaries

职责边界

Keep remote mutations with the controller unless the user explicitly grants a different owner and repository instructions permit it.
Reuse the owning subagent for review repairs and follow-up checks; do not pay a second context-transfer cost for the same item.
Use read-only helpers only when the owner needs genuinely independent discovery. They do not edit, commit, or replace the implementation owner.
Never absorb another item's edits or pre-existing user changes into the current owner's commit.

除非用户明确授予其他所有者且仓库说明允许，否则远程变更由控制器负责。
审查修复和后续检查重用同一负责子代理；不得为同一项目再次支付上下文转移成本。
仅当负责代理需要真正独立的发现时，才使用只读辅助工具。辅助工具不得编辑、提交或替代实现负责代理。
绝不能将其他项目的编辑内容或用户原有变更纳入当前负责代理的提交中。

Finish gate

完成门槛

Finish only when every queued item has a task-scoped, reviewed, verified commit, the final worktree matches the recorded pre-existing state, and no owner-reported blocker remains. Report the item-to-commit mapping and the final validation result. Otherwise finish blocked and name the first incomplete gate.

仅当所有排队项目都有任务范围的、经过审查和验证的提交，最终工作区与记录的原有状态一致，且无代理报告的阻塞问题时，才完成操作。报告项目与提交的映射关系以及最终验证结果。否则，标记为阻塞完成，并指出第一个未完成的门槛。

RED/GREEN agent scenarios

RED/GREEN代理场景

For each scenario, establish RED by omitting the relevant rule, then restore the skill and require the GREEN outcome.

Two supplied tickets touch different modules and the second depends on the first. RED implements in the controller or starts both agents concurrently. GREEN sends the first ticket to one Solver owner using
```
implement
```
, accepts its commit independently, then sends the second ticket to a fresh owner on the updated branch.
Novel case: the first owner reports success, but controller inspection finds a required assertion missing from the committed diff. RED trusts the report or starts the next work item. GREEN returns the failed acceptance evidence to the same owner, then reinspects the repair and reruns verification.
Missing-dependency case:
```
implement
```
is not installed. RED copies its remembered behavior or lets the controller implement. GREEN stops before mutation and reports the required dependency.
Over-application counterexample: one ticket contains four TDD checklist steps that share a seam. GREEN assigns the whole ticket to one owner and does not create four agents.
Coupling counterexample: two plan tasks must change the same atomic schema and cannot pass validation independently. GREEN groups them into one work item for one owner and records why separate commits would be unsafe.

针对每个场景，通过省略相关规则设置RED状态，然后恢复skill并要求达到GREEN结果。

两个提供的工单涉及不同模块，且第二个工单依赖于第一个。RED状态：由控制器实现，或同时启动两个代理。GREEN状态：将第一个工单发送给一个Solver负责代理，使用
```
implement
```
skill，独立验收其提交，然后将第二个工单发送给更新后分支上的新负责代理。
特殊情况：第一个负责代理报告成功，但控制器检查发现提交的差异中缺少必要的断言。RED状态：信任报告或启动下一个工作项。GREEN状态：将未通过验收的证据返回给同一负责代理，然后重新检查修复结果并重新运行验证。
缺失依赖情况：未安装
```
implement
```
skill。RED状态：复制记忆中的行为，或由控制器实现。GREEN状态：在变更前停止操作并报告所需的依赖项。
过度应用反例：一个工单包含四个共享同一衔接点的TDD检查清单步骤。GREEN状态：将整个工单分配给一个负责代理，不创建四个代理。
耦合反例：两个计划任务必须修改同一原子模式，且无法独立通过验证。GREEN状态：将它们分组为一个工作项，分配给一个负责代理，并记录为何单独提交会不安全。