名称: tdd迁移流水线 描述: 仅协调器工作流，用于通过完整TDD和代理委派迁移/重写代码库 允许工具: [Task, TodoWrite, Read, Bash]
TDD迁移流水线
仅协调器工作流，用于迁移或重写代码库。您不读取文件、编写代码或自行验证任何内容。您只指导代理并传递上下文（路径，而非内容）。
使用时机
- 将代码库从一种语言/框架迁移到另一种
- 使用TDD保证重写系统
- 具有行为契约的大规模重构
- 当您希望在协调器中零上下文增长时
核心原则
- 零协调器执行 - 只指导并传递上下文
- 所有工作由代理完成 - 您从不读取/写入/验证
- 上下文窗口保持平坦 - 传递路径，而非内容
- 新代码放在单独目录中 - 从不修改源
您的约束
- 从不说“让我读取…”或“查看…”
- 只说“代理X：用Z做Y”
- 您的上下文不应在执行期间增长
- 所有代理必须使用
qlty和tldr技能
流水线阶段
阶段1: 规范
指导spec-agent（使用scout或architect）：
- 使用tldr技能分析{source_path}
- 输出：spec.md，包含行为契约、类型、边界情况
代理提示模板：
使用tldr命令（tldr结构，tldr提取，tldr调用）分析{source_path}处的代码库。
创建spec.md，包含：
- 所有行为契约（每个函数/类的承诺）
- 输入/输出类型
- 边界情况和不变量
- 组件间的依赖关系
写入：{target_dir}/spec.md
阶段2: 失败测试
指导test-agent（使用arbiter）：
- 读取spec.md
- 在{target_dir}/tests/中编写失败测试
- 测试应在实现前定义预期行为
指导review-agent（使用critic）：
- 验证测试完全覆盖规范
- 无行为覆盖缺口
阶段3: 对抗性（迭代3次）
指导premortem-agent（使用premortem技能）：
- 审查规范 + 测试
- 识别故障模式、竞争条件、边界情况
- 不要询问 - 直接将缓解措施添加到规范中
- 运行3次迭代，每次都有新视角
关键点： 每次迭代应找到新问题，而非重复先前的问题。
阶段4: 阶段化计划
指导planner-agent（使用architect或plan-agent）：
- 输入：spec.md + 测试 + 缓解措施
- 输出：phased-plan.yaml
- 要求：
- 依赖排序的阶段
- 每个阶段 = 一个可测试单元
- 每个阶段清晰的输入/输出
阶段5: 构建循环（每个阶段）
对于phased-plan.yaml中的每个阶段：
指导builder-agent（使用kraken或spark）：
- 编写代码以通过此阶段的测试
- 使用qlty进行质量检查
- 每次更改后运行测试
指导review-agent（使用critic或judge）：
- 验证实现匹配规范
- 检查先前阶段的回归
- 验证无破坏性更改
阶段6: 集成验证
指导integration-agent（使用atlas或validator）：
- 使用tldr对比{reference_repo}
- 检查：
- 无竞争条件
- 无挂起或死锁
- 无与原始相比的破坏性更改
- 所有行为契约得以保留
- 输出：validation-report.md
调用
调用此工作流时，指定：
SOURCE: {源代码路径}
TARGET_DIR: {迁移代码的新文件夹}
TARGET_LANG: {typescript|python|go|rust|等}
REFERENCE_REPO: {最终对比的URL或路径}
SKILLS: [tldr-code, qlty-check, {领域特定}]
代理映射
| 阶段 | 代理类型 | 子代理 |
|---|---|---|
| 规范 | 研究 | scout 或 architect |
| 测试 | 验证 | arbiter |
| 审查 | 审查 | critic 或 judge |
| 对抗性 | 审查 | premortem 技能 |
| 计划 | 计划 | architect 或 plan-agent |
| 构建 | 实现 | kraken（大型）或 spark（小型） |
| 集成 | 验证 | atlas 或 validator |
示例协调
# 阶段1
Task(scout): "分析 /src/old-system 使用 tldr 结构和 tldr 提取。创建 spec.md 在 /migration/spec.md，包含所有行为契约。"
# 阶段2
Task(arbiter): "读取 /migration/spec.md。编写失败测试到 /migration/tests/，定义预期行为。"
Task(critic): "审查 /migration/spec.md 与 /migration/tests/。报告任何行为缺口。"
# 阶段3（迭代3次）
Task(premortem): "审查 /migration/spec.md 和 /migration/tests/。识别故障模式。直接将缓解措施添加到规范中。迭代1/3。"
[重复使用“迭代2/3”，“迭代3/3”]
# 阶段4
Task(architect): "从 /migration/spec.md 和 /migration/tests/，创建 /migration/phased-plan.yaml，包含依赖排序的阶段。"
# 阶段5（循环）
Task(kraken): "从 /migration/phased-plan.yaml 实现阶段1。代码写入 /migration/src/。运行测试后。"
Task(critic): "审查 /migration/src/ 对比 /migration/spec.md。检查规范合规性和回归。"
[重复每个阶段]
# 阶段6
Task(atlas): "运行完整集成测试在 /migration/src/。使用 tldr 对比 /src/old-system。输出 /migration/validation-report.md。"
反模式（不要做）
- 将文件读入上下文（“让我检查代码…”）
- 直接编写代码（“我将实现这个函数…”）
- 自行验证任何内容（“查看测试，我看到…”）
- 修改源目录
- 跳过对抗性阶段
- 未先运行测试就进行构建
成功标准
- [ ] 所有测试通过
- [ ] qlty 报告干净
- [ ] tldr 对比显示无破坏性更改
- [ ] 无竞争条件或挂起
- [ ] validation-report.md 确认行为等价