用途：按用户给出的规格或工单实现工作。
主要能力与流程顺序：
- 尽可能在预先约定的接缝处使用 /tdd。
- 构建期间只做聚焦检查：频繁类型检查，并只运行所改动代码对应的单个测试文件，不跑全套、不做完整构建、不跑项目门。
- 实现完成后只做一次评审：使用 /code-review，两个维度并行，在从未见过你推理过程的新上下文中进行，并把指定的只读提示逐字粘贴进每个维度提示中。该提示要求评审者只读、不得构建/跑全套/提交/编辑文件，只读 diff 及周围文件；最多只允许运行一个聚焦测试，且必须事先说明它要消除的不确定性并指名所运行的单个文件或包，否则不得运行，只把疑虑作为发现报告。
- 一批修复所有发现，而不是逐个修复。仅当 P0 或 P1 修复改变了某维度覆盖的行为时，才重新运行该一个维度；其他情况只对改动过的片段做一次聚焦评审。
- 将工作提交到当前分支，即最终评审过的树。
- 之后在该已提交的树上只运行一次项目完整门：本仓库中为 bun run quality（biome、typecheck、duplication）与 bun run test:hooks（所有 scripts/*.test.mjs）。两者正是 CI 所跑，绿灯即等价于绿灯 PR。注意没有推送时钩子，apps/macOS 没有任何验证（#1758）。
适用场景：需要依据规格或工单落地代码改动，并希望控制验证成本、避免在会被评审改动的树上过早跑昂贵验证的流程。
限制：运行止于评审过的、提交在本分支上的 diff，不推送、不打开 PR，这两步由 /ship 另行调用。当 mcp__argo__report_ready 可用时，在评审与提交后调用它，给出简短理由并说明改动文件数与提交数，以完成本次 implement 运行并让 Argo 名单显示 Ready。