用途
tdd-migrate 是一个 TDD（测试驱动开发）迁移工作流技能，核心目标是用智能体完成迁移中的全部实际工作，使主上下文只承担编排职责，从而保持干净、不随任务规模增长。
典型使用场景包括：
- 将某个模块从一种语言移植到另一种语言，例如“Port X from Python to TypeScript”。
- 按照既有模式批量创建多个适配器，例如“Create N adapters following existing pattern”。
- 将模块迁移到新架构。
- 对多个相似条目进行 TDD 实现。
主要能力
该技能通过分阶段工作流组织迁移任务：
- Phase 0：创建 YAML TODO 列表。
- Phase 1：TLDR 分析。
- Phase 2：编写失败测试。
- Phase 3：最小实现。
- Phase 4：构建并通过测试。
- Phase 5：QLTY 检查。
- Phase 6：评审智能体验证。
- Phase 7：TLDR 差异对比（新文件与参考文件）。
- Phase 8：修复问题（如有）。
其中 Phase 1 至 Phase 4 可按条目并行执行 scout，Phase 5 与 Phase 6 可并行执行。
关键原则是：主上下文只做编排；不直接读取文件（交给 scout）；不直接实现（交给 kraken/spark）；不直接运行测试（交给 validator）；只负责传递上下文和协调。所有实际工作由智能体完成。
不同任务对应的智能体：
- 探索/分析：scout
- 编写测试并实现：kraken
- 快速修复：spark
- 运行测试/验证：validator
- 代码评审：critic
在条目相互独立时，所有条目可并行实现；评审与 QLTY 可并行运行；TLDR 分析与规划可并行。每个主要步骤之后进行评审：实现后由 critic 评审，修复后由 validator 重新验证。
使用方式
调用参数格式：
/tdd-migrate <source_path> <target_path> --pattern <reference> --items "item1,item2,item3"
参数说明：
- source_path：要分析的路径（现有代码）。
- target_path：创建新代码的位置。
- pattern：要遵循的参考文件/模式。
- items：以逗号分隔的待创建条目列表。
Step 0：创建 YAML TODO
将 YAML 计划文件写入 thoughts/shared/plans/<name>-tdd.yaml，示例结构如下：
---
title: <Migration Name>
date: <today>
type: implementation-plan
approach: TDD (test → build → pass → review)
items:
- name: item1
file: <target_path>/item1.ts
test: <target_path>/__tests__/item1.test.ts
deps: []
- name: item2
# ...
reference: <pattern_file>
workflow:
per_item:
1: Write failing test
2: Implement minimal
3: Build
4: Pass test
5: QLTY check
6: Review
final:
7: Integration test
8: TLDR diff
Step 1：启动 Scout 智能体（并行）
Task (scout): Analyze <source_path> with TLDR
Task (scout): Analyze <pattern> to understand structure
Task (scout): Read migration handoff if exists
Step 2：启动 Kraken 智能体（每个条目并行）
对每个条目启动一个 kraken，执行完整 TDD：
Task (kraken): Implement <item> using TDD workflow
1. Read pattern file
2. Write failing test
3. Implement
4. Run: bun test <test_file>
5. Run: qlty check <impl_file>
Step 3：评审与验证（并行）
Task (critic): Review all new files against pattern
Task (validator): Run full test suite
Task (validator): QLTY check all files
Step 4：修复问题
如果 critic/validator 发现问题：
Task (spark): Fix <specific issue>
Task (validator): Re-validate
Step 5：TLDR 差异对比
Task (validator): TLDR diff new files vs reference
- tldr structure <new_file> --lang <lang>
- tldr structure <reference> --lang <lang>
- Compare patterns
Step 6：更新连续性
用已完成的工作更新 ledger。
示例：Rigg Adapters
/tdd-migrate /Users/cosimo/Documents/rigg/src/sdk/providers \
/Users/cosimo/Documents/rigg/src/sdk/providers \
--pattern lmstudio.ts \
--items "xai,cerebras,togetherai,deepinfra,perplexity"
资料中给出的结果为：5 个并行 kraken 智能体、39 个测试通过、所有适配器正常工作、总耗时约 15 分钟。
智能体提示词
Scout（分析）：
Explore <path> to understand:
1. Structure/patterns
2. Interfaces/types
3. Dependencies
Return actionable summary for implementation.
Kraken（TDD）：
Implement <item> using TDD:
1. Read <pattern> for structure
2. Write failing test to <test_path>
3. Implement minimal to <impl_path>
4. Run: <test_command>
5. Run: qlty check <impl_path>
Report: status, issues, files created.
Critic（评审）：
Review <files> against <pattern>:
1. Pattern compliance
2. Type safety
3. Missing registrations
4. Security issues
DO NOT edit. Report issues only.
Spark（修复）：
Fix <specific issue>:
1. Read <file>
2. Make minimal edit
3. Verify fix
Validator（测试）：
Validate <files>:
1. Run <test_command>
2. Run qlty check
3. Report pass/fail/issues
适用场景
- 多条目、模式一致的代码迁移或批量创建。
- 需要保持主上下文干净、避免上下文膨胀的复杂迁移任务。
- 希望以 TDD 方式保证迁移质量、并引入独立评审与验证的工程流程。
限制与反模式
应避免的反模式（资料中明确列出）：
- 在主上下文中读取文件（应启动 scout 智能体）。
- 在主上下文中编写代码（应启动 kraken/spark 智能体）。
- 在主上下文中运行测试（应启动 validator 智能体）。
- 跳过评审（应始终启动 critic）。
- 顺序处理条目（应并行启动 kraken）。
- 在主上下文中修复（应启动 spark）。
成功标准：
- 所有测试通过。
- QLTY 报告无问题。
- Critic 未发现严重问题。
- TLDR 差异显示符合模式。
- 所有条目正确注册/导出。
关于该技能的具体收费、价格、支持平台、安装命令等事实，资料中暂未提供。