需要迁移或重写代码库并保证完整 TDD、行为等价且…

适用于从一种语言/框架迁移到另一种、用 TDD 重写系统或大规模重构，并希望 orchestrator 不读文件、不写代码、上下文不增长。

适用场景

解决思路

1. 以 orchestrator-only 方式运行：你不读文件、不写代码、不自行验证；只指示 agents 并传递上下文（路径，不是内容）。
2. 只有 instruct 和 pipe context 由 orchestrator 执行；所有实际工作由 agents 完成。
3. 保持 orchestrator 的上下文窗口平坦：传递路径，而不是文件内容。
4. 新代码放在独立目录中；绝不修改源目录。
5. 约束措辞：不要说“let me read...”或“looking at...”；只说“Agent X: do Y with Z”。
6. 确保所有 agents 使用 qlty 和 tldr skills。
7. 调用时指定：SOURCE 为源代码路径；TARGET_DIR 为迁移后代码的新文件夹；TARGET_LANG 为 typescript|python|go|rust|etc；REFERENCE_REPO 为最终 diff 比较用的 url 或路径；SKILLS 为 [tldr-code, qlty-check, {domain-specific}]。
8. Phase 1 SPEC：指示 spec-agent（使用 scout 或 architect）用 tldr-skill 分析 {source_path}；运行 tldr structure、tldr extract、tldr calls；创建 spec.md，包含所有行为契约（每个函数/类承诺什么）、输入/输出类型、边界情况和不变式、组件之间的依赖；写入 {target_dir}/spec.md。
9. Phase 2 FAILING TESTS：指示 test-agent（使用 arbiter）读取 spec.md；在 {target_dir}/tests/ 中编写 failing tests；测试应在实现之前定义预期行为。
10. Phase 2 继续：指示 review-agent（使用 critic）验证测试完整覆盖 spec；确认行为覆盖无缺口。
11. Phase 3 ADVERSARIAL（运行 3 轮）：指示 premortem-agent（使用 premortem skill）审查 spec + tests；识别失败模式、竞态条件、边界情况；不要询问，直接把缓解措施添加到 spec；用全新视角运行 3 轮；每轮应发现新问题，而不是重复之前的问题。
12. Phase 4 PHASED PLAN：指示 planner-agent（使用 architect 或 plan-agent）；输入 spec.md + tests + 缓解措施；输出 phased-plan.yaml；要求阶段按依赖排序；每个阶段=一个可测试单元；每个阶段有清晰输入/输出。
13. Phase 5 BUILD LOOP（每个 phase）：对 phased-plan.yaml 中的每个 phase，指示 builder-agent（使用 kraken 或 spark）编写代码以通过该 phase 的测试；使用 qlty 做质量检查；每次更改后运行测试。
14. Phase 5 继续：对每个 phase，指示 review-agent（使用 critic 或 judge）验证实现符合 spec；检查之前阶段的回归；验证没有破坏性变更。
15. Phase 6 INTEGRATION VALIDATION：指示 integration-agent（使用 atlas 或 validator）用 tldr 与 {reference_repo} 做 diff；检查无竞态条件、无挂起或死锁、相对原始系统无破坏性变更、所有行为契约保留；输出 validation-report.md。
16. Agent Mapping：Spec 用 research agent 的 scout 或 architect；Tests 用 validate agent 的 arbiter；Review 用 review agent 的 critic 或 judge；Premortem 用 review agent 的 premortem skill；Plan 用 plan agent 的 architect 或 plan-agent；Build 用 implement agent 的 kraken（大）或 spark（小）；Integration 用 validate agent 的 atlas 或 validator。
17. 示例 Phase 1 调用：Task(scout): 使用 tldr structure 和 tldr extract 分析 /src/old-system；在 /migration/spec.md 创建 spec.md，包含所有行为契约。
18. 示例 Phase 2 调用：Task(arbiter): 读取 /migration/spec.md；将定义预期行为的 failing tests 写入 /migration/tests/。Task(critic): 审查 /migration/spec.md 与 /migration/tests/；报告任何行为缺口。
19. 示例 Phase 3 调用：Task(premortem): 审查 /migration/spec.md 和 /migration/tests/；识别失败模式；直接将缓解措施添加到 spec；Pass 1/3。然后用 Pass 2/3、Pass 3/3 重复。
20. 示例 Phase 4 调用：Task(architect): 从 /migration/spec.md 和 /migration/tests/ 创建 /migration/phased-plan.yaml，阶段按依赖排序。
21. 示例 Phase 5 调用：Task(kraken): 实现 /migration/phased-plan.yaml 中的 phase 1；代码放入 /migration/src/；之后运行测试。Task(critic): 对照 /migration/spec.md 审查 /migration/src/；检查 spec 合规性和回归。对每个 phase 重复。
22. 示例 Phase 6 调用：Task(atlas): 对 /migration/src/ 运行完整集成测试；使用 tldr 与 /src/old-system 做 diff；输出 /migration/validation-report.md。
23. 不要做：把文件读入 orchestrator 上下文（“let me check the code...”）；直接写代码（“I'll implement this function...”）；自行验证（“looking at the tests, I see...”）；修改源目录；跳过 adversarial phase；没有先写测试就运行 build。
24. 成功标准检查：所有测试通过；qlty 报告 clean；tldr diff 显示无破坏性变更；无竞态条件或挂起；validation-report.md 确认行为等价。

适用边界 · 注意事项

• 没有可用的 agent 编排框架、Task 工具或对应子代理（scout、arbiter、kraken、atlas 等）时不适用。
• 没有 tldr、qlty 等技能/工具，或无法使用它们时不适用。
• 只是小型、快速、单文件修改，或不能新建独立目录/必须直接改源代码时不适用。