用途：帮助在实践测试驱动开发（TDD）时，按代码类型选择伦敦派（mock 为主）或芝加哥派（状态为主）的测试风格。判断原则：领域逻辑与纯函数、值对象、算法计算偏向芝加哥派；控制器、服务、外部依赖（数据库、API、网络 I/O）偏向伦敦派；实际项目中可混合使用。
主要能力：给出 TDD 红-绿-重构循环的纪律（先写失败测试并确认失败、写最小实现、测试保持通过时重构）；对比两种流派在协作者（真实对象 vs mock/stub）、验证方式（状态断言 vs 交互断言）、隔离度、重构难易与设计反馈上的差异；列出常见陷阱（过度 mock、测试私有内部实现、测试痛苦反映设计问题）；并提供智能体协作方式，如 qe-test-generator 生成测试、qe-test-implementer 写最小实现、qe-test-refactorer 安全重构。
使用方式：按上下文先判定代码类型，再写失败测试，实现最小通过代码，最后重构；伦敦派示例使用 jest.fn() 模拟依赖并断言调用，芝加哥派示例构造真实对象并断言最终状态。存在代理协作接口示例（如 Task 调用与 FleetManager 协调 red-green-refactor 工作流），命令保持原样。
适用场景：新功能采用测试先行；为遗留代码补测试后重构；团队教学 TDD；在 mock 与真实对象之间做选择。
限制与提醒：资料未提供具体收费、价格与平台信息；需警惕智能体跳过 Red 阶段、默认对所有内容使用 jest.mock()、伦敦派过度 mock 导致测试脆弱、芝加哥派集成范围扩大后测试变慢，以及重构阶段偷工减料等问题。