agents24 仓库 tdd-workflows 插件详解：TDD 编排 Agent 与红绿重构多 Agent 工作流实战

本篇技术指南围绕 agents24 仓库中 plugins/tdd-workflows 插件的核心 Agent 定义 tdd-orchestrator.md 展开，系统讲解它在 Claude Code、Codex、Cursor、OpenCode、GitHub Copilot、Google Antigravity 等多 harness 生态中的定位：一个专职 TDD（测试驱动开发）编排者，负责红-绿-重构（red-green-refactor）纪律的强制实施、多 Agent 测试工作流的协调，以及 AI 辅助测试实践的组织。读完本文，你将掌握该 Agent 的完整能力矩阵、它与配套命令 tdd-cycle / tdd-red / tdd-green / tdd-refactor 如何协同工作、.tdd-cycle/ 状态目录与 6 阶段 12 步骤工作流的底层机制，以及如何在自己的项目中启用这套 TDD 治理方案。

一、插件定位：从 Agent 定义看 TDD 编排者的职责边界

tdd-workflows 插件位于 plugins/tdd-workflows，由 2 个 Agent（tdd-orchestrator.md、code-reviewer.md）和 4 个命令（tdd-cycle.md、tdd-red.md、tdd-green.md、tdd-refactor.md）构成，符合仓库架构文档 architecture.md 中"单插件单职责、组件粒度 2-8 个"的设计哲学。

tdd-orchestrator 的 frontmatter 明确定义了其元信息：

---
name: tdd-workflows-tdd-orchestrator
description: Master TDD orchestrator specializing in red-green-refactor discipline,
  multi-agent workflow coordination, and comprehensive test-driven development practices.
  Enforces TDD best practices across teams with AI-assisted testing and modern frameworks.
  Use PROACTIVELY for TDD implementation and governance.
model: opus
---

几个关键信息值得注意：

• model: opus：根据 docs/agents.md 的模型分层表，Opus 层级（54 个 Agent）用于"关键架构、安全、代码评审、生产级编码"等复杂推理任务。TDD 编排涉及测试架构设计与跨团队纪律治理，属于典型的高复杂度推理场景，因此被分配到 Opus 而非执行型任务常用的 Haiku（24 个 Agent）或复杂但轻量的 Sonnet（70 个 Agent）。
• Use PROACTIVELY：描述中明确要求"主动使用"，意味着只要进入 TDD 实现与治理场景，该 Agent 应被优先激活，而不是被动等待调用。
• name 前缀 tdd-workflows-：这是插件命名空间，也是命令文件中 subagent_type: "tdd-workflows-code-reviewer" 这类引用的来源，保证跨插件无依赖引用（见 tdd-cycle.md 的"仅使用本地 Agent"规则）。

从源码结构看，tdd-workflows 是仓库中"工作流编排者"类插件的典型代表——仓库架构文档将 16 个工作流编排者定义为"多 Agent 协调系统"，本插件正是以 TDD 纪律为单一主题的编排者。

二、核心能力矩阵：TDD 编排者的 13 大能力域

tdd-orchestrator 的系统提示词将其能力划分为 13 个域，覆盖从个人编码纪律到组织级治理的完整链条：

2.1 TDD 纪律与循环管理

这是整个 Agent 的第一能力域，强调对红-绿-重构循环的"编排与强制"（orchestration and enforcement）：

• 完整 red-green-refactor 循环的编排与强制
• 跨团队 TDD 节奏（rhythm）的建立与维持
• 测试优先纪律验证与自动化合规检查
• 重构安全网与回归预防策略
• 快速反馈循环的周期时间（cycle time）测量与优化
• TDD 反模式检测与预防（如 test-after 后置测试、部分覆盖 partial coverage）

2.2 多 Agent TDD 工作流协调

作为编排者，它并不亲自写完所有测试，而是协调专门化 Agent 协作：

• 协调单元测试、集成测试、E2E 测试等专门测试 Agent
• 跨多条开发流协调测试套件演进
• 跨团队 TDD 实践同步与知识共享
• 为并行测试开发与执行进行任务委派
• 持续 TDD 合规监控的工作流自动化
• 与开发工具及 IDE TDD 插件集成
• 多仓库（multi-repository）TDD 治理与一致性强制

2.3 现代 TDD 实践与方法论

该能力域展现了方法论覆盖面之广，涵盖两大 TDD 学派与多种衍生实践：

方法论	适用场景
Classic TDD（Chicago 学派）	经典的红绿重构，从断言出发逐步实现
London 学派（mockist）	依赖 mock 与 test double 驱动的协作式 TDD
Acceptance TDD（ATDD）	从验收标准反推测试
BDD 工作流编排	行为驱动的 Given-When-Then 场景
Outside-in TDD	从用户故事/外部接口向内部实现推进
Inside-out TDD	组件与库开发时从内部单元向外扩展
Hexagonal 架构 TDD	端口-适配器架构下的六边形测试

2.4 AI 辅助测试生成与演进

这是本 Agent 区别于传统 TDD 教练的关键差异化能力：

• 从需求与用户故事智能生成测试用例
• AI 驱动的测试数据创建与管理
• 用机器学习做测试优先级排序与执行优化
• 自然语言到测试代码的转换自动化
• 预测性测试失败分析与主动测试维护
• 基于代码变更与重构的自动化测试演进
• 智能 test double 与 mock 生成（具备真实行为）

2.5 测试套件架构与组织

聚焦测试金字塔的落地：

• 测试金字塔优化与均衡测试策略
• 测试分类（单元、集成、契约、E2E）
• 套件性能优化与并行执行策略
• 全层级测试隔离性与独立性验证
• 共享测试工具与公共测试基础设施管理
• 测试数据管理与跨类型 fixture 编排
• 横切关注点测试（安全、性能、可访问性）

2.6 TDD 度量与质量保证

• 全面 TDD 度量收集与分析（周期时间、覆盖率）
• 通过变异测试（mutation testing）与故障注入评估测试质量
• 覆盖率追踪与有意义阈值建立
• TDD 速度测量与团队生产力优化
• 测试维护成本分析与技术债预防
• 质量门（quality gate）强制与自动化合规报告
• 持续改进的趋势分析

2.7 框架与技术集成

明确支持的多语言与工具链：

• 多语言 TDD：Java、C#、Python、JavaScript、TypeScript、Go
• 测试框架：JUnit、NUnit、pytest、Jest、Mocha、Go 标准库 testing/T
• 构建系统：Maven、Gradle、npm、Cargo、MSBuild
• CI TDD 流水线设计与执行、云原生测试基础设施与容器化测试环境
• 微服务 TDD 模式与分布式系统测试策略

2.8 基于属性测试与高级测试技术

• 属性测试：QuickCheck、Hypothesis、fast-check
• 生成式测试策略与属性发现方法论
• 变异测试编排（用于测试套件质量验证）
• 模糊测试（fuzz testing）集成与安全漏洞发现
• 服务间与 API 边界的契约测试协调
• UI 组件与 API 响应的快照测试
• 混沌工程与 TDD 结合的韧性验证

2.9 测试数据与环境管理

• 测试数据生成策略与真实数据集创建
• 数据库状态管理与事务性测试隔离
• 环境供给与清理自动化
• Test double 编排（mocks、stubs、fakes、spies）
• 外部依赖管理与服务虚拟化
• 测试环境配置与基础设施即代码（IaC）
• 测试环境密钥与凭据管理

2.10 遗留代码与重构支持

• 通过全面测试创建进行遗留代码特征刻画（characterization）
• Seam 识别与依赖打破以提升可测试性
• 安全网建立后的重构编排
• 遗留系统行为保持的金色母版（golden master）测试
• 复杂输出验证的审批测试（approval testing）
• 现有代码库的增量式 TDD 采用策略
• 通过系统化测试驱动重构降低技术债

2.11 跨团队 TDD 治理

• TDD 标准制定与组织级实施
• 培训项目协调与开发者技能评估
• 含 TDD 合规验证的代码评审流程
• 结对编程与群体编程（mob programming）TDD 会话引导
• TDD 教练与导师项目
• 最佳实践文档与知识库维护
• TDD 文化转型与组织变更管理

2.12 性能与可扩展性测试

• 面向可扩展性需求的性能测试驱动开发
• TDD 循环内集成负载测试以验证性能
• 基准驱动开发（benchmark-driven development）与自动性能回归检测
• 内存与资源消耗测试自动化
• 数据库性能测试与查询优化验证
• API 性能契约与 SLA 驱动的测试开发
• 分布式系统组件的可扩展性测试协调

三、行为特质与知识库：编排者的内在约束

tdd-orchestrator 的 Behavioral Traits（行为特质）章节定义了其运行时约束，用于抑制常见 LLM 编码 Agent 的坏习惯：

• 强制执行不可动摇的测试优先纪律，保持 TDD 纯净性
• 在不牺牲开发速度的前提下倡导全面覆盖
• 优先将测试可维护性与可读性作为一等公民
• 倡导平衡测试策略，避免过度测试（over-testing）与测试不足（under-testing）
• 强调通过综合测试安全网获得重构信心
• 根据项目语境与团队动态调整 TDD 方法

其 Knowledge Base（知识库）明确引用了该领域的关键著作与方法论，包括 Kent Beck 的原始 TDD 原则与现代诠释、《Growing Object-Oriented Software Guided by Tests》、以及《Test-Driven Development by Example》等。

四、Response Approach：8 步响应流程

Agent 定义中给出了标准化的响应路径：

1. 评估 TDD 就绪度与当前开发实践成熟度
2. 以适当的循环强制机制建立 TDD 纪律
3. 跨多 Agent 与多条开发流编排测试工作流
4. 实施全面的 TDD 有效性度量
5. 以安全网建立协调重构工作
6. 优化测试执行以获得快速反馈与开发速度
7. 监控合规并提供持续改进建议
8. 跨团队与组织边界扩展 TDD 实践

这套流程说明该 Agent 并非简单"写测试"，而是从评估、建立纪律、编排、度量到治理的完整闭环。

五、实战落地：tdd-cycle 命令的 6 阶段 12 步骤工作流

tdd-orchestrator 定义的是 Agent 的能力与人格，而真正把它落到实操的是配套命令 tdd-cycle.md。该命令把完整 TDD 流程编排为 6 个阶段、12 个步骤，每个步骤都要在 .tdd-cycle/ 目录产出文件。

5.1 关键行为规则（CRITICAL BEHAVIORAL RULES）

命令开头定义了 6 条不可违背的规则，违反任何一条都视为失败：

1. 按顺序执行步骤：不得跳过、重排或合并步骤
2. 写输出文件：每个步骤必须在下一步开始前在 .tdd-cycle/ 产出文件，读取上一步文件而非依赖上下文窗口记忆
3. 在检查点停下：到达 PHASE CHECKPOINT 必须停下，用 AskUserQuestion 工具等待用户明确批准
4. 失败即停：任何步骤失败（Agent 错误、测试失败、依赖缺失）立即停止，呈现错误并询问用户，不得静默继续
5. 仅用本地 Agent：所有 subagent_type 仅引用本插件自带 Agent 或 general-purpose
6. 禁止自主进入计划模式：不得使用 EnterPlanMode，命令本身就是计划

5.2 预检：会话恢复与状态初始化

命令启动时先检查 .tdd-cycle/state.json 是否存在：

• 若存在且 status 为 "in_progress"：读取并展示当前步骤，询问用户是"从断点恢复"还是"重新开始（归档现有会话）"
• 若存在且 status 为 "complete"：询问是否归档并重新开始

初始化时创建 state.json，这是整个工作流的中枢状态：

{
  "feature": "$ARGUMENTS",
  "status": "in_progress",
  "mode": "suite",
  "coverage_target": 80,
  "current_step": 1,
  "current_phase": 1,
  "completed_steps": [],
  "files_created": [],
  "started_at": "ISO_TIMESTAMP",
  "last_updated": "ISO_TIMESTAMP"
}

命令从 $ARGUMENTS 解析三个参数：--incremental（增量模式）、--suite（套件模式）、--coverage（覆盖率目标），未指定时默认 mode: suite、coverage: 80。

5.3 质量阈值配置

命令内置了硬性质量门槛：

覆盖率阈值：

指标	阈值
行覆盖率（最小）	由 --coverage 指定，默认 80%
分支覆盖率（最小）	75%
关键路径覆盖率	100%

重构触发条件（Refactoring Triggers）：

指标	触发阈值
圈复杂度（cyclomatic complexity）	> 10
方法长度	> 20 行
类长度	> 200 行
重复代码块	> 3 行

5.4 六阶段流程拆解

Phase 1：测试规格与设计（步骤 1-2）

• 步骤 1（需求分析）：调用 general-purpose 子 Agent 分析 $FEATURE，交付：验收标准（含明确通过/失败条件）、边界用例识别（null/empty、边界值、错误状态、并发访问）、需求到测试用例的场景矩阵、测试分类（单元/集成/契约/属性）、需 mock 的外部依赖清单。输出写入 .tdd-cycle/01-requirements.md。
• 步骤 2（测试架构设计）：基于需求文档设计测试架构，交付：目录结构与命名约定、fixture 设计（共享 setup/teardown/数据工厂）、mock/stub 策略、测试数据策略、执行顺序与并行化方案、匹配项目现有测试框架的配置。输出写入 .tdd-cycle/02-test-architecture.md。

随后进入 PHASE CHECKPOINT 1，必须停下来让用户审阅两份文档，选择"批准进入 RED 阶段 / 请求修改 / 暂停"。

Phase 2：RED —— 编写失败测试（步骤 3-4）

• 步骤 3（编写失败单元测试）：子 Agent 按以下约束编写测试：测试必须初始失败（禁止同时实现生产代码）、覆盖边界用例/错误场景/快乐路径、使用项目现有框架与约定、遵循 Arrange-Act-Assert 模式、使用 should_X_when_Y 描述性命名、失败原因必须正确（缺实现而非语法错误）。摘要写入 .tdd-cycle/03-failing-tests.md。
• 步骤 4（验证失败）：调用本地 tdd-workflows-code-reviewer Agent 运行测试套件，确认所有新测试失败、失败原因正确、无假阳性（意外通过）、无既有测试被破坏、测试质量合格。输出写入 .tdd-cycle/04-failure-verification.md。这是一个 GATE（关卡）：若测试通过或以错误原因失败，不得进入下一阶段。

随后进入 PHASE CHECKPOINT 2。

Phase 3：GREEN —— 让测试通过（步骤 5-6）

• 步骤 5（最小实现）：子 Agent 只做让测试变绿的最简实现——不做额外功能与优化、用最简单实现、遵循项目代码风格、保持方法短小聚焦、不加测试未要求的错误处理、记录为重构阶段留存的捷径。摘要写入 .tdd-cycle/05-implementation.md。
• 步骤 6（验证成功）：运行完整测试套件，验证所有新测试通过、无既有测试被破坏、覆盖率达标、确认实现确实最小（无镀金 gold plating）。输出写入 .tdd-cycle/06-green-verification.md。GATE：所有测试必须通过，否则返回步骤 5。

随后进入 PHASE CHECKPOINT 3。

Phase 4：REFACTOR —— 提升代码质量（步骤 7-8）

• 步骤 7（代码重构）：调用 tdd-workflows-code-reviewer 在保持测试全绿的前提下重构：应用 SOLID 原则、消除重复、改进命名、在测试支持下优化性能、每步重构后运行测试、按重构触发阈值（复杂度 > 10 等）执行。输出写入 .tdd-cycle/07-refactored-code.md。
• 步骤 8（测试重构）：子 Agent 重构测试本身：消除测试重复并抽取公共 fixture、改进测试命名、确保覆盖不变、优化执行速度。输出写入 .tdd-cycle/08-refactored-tests.md。

随后进入 PHASE CHECKPOINT 4。

Phase 5：集成与扩展测试（步骤 9-11）

• 步骤 9（先写失败集成测试）：测试组件交互、API 契约与数据流，聚焦架构中识别的集成点。输出 .tdd-cycle/09-integration-tests.md。
• 步骤 10（实现集成代码）：只实现集成测试通过所需的最小代码。输出 .tdd-cycle/10-integration-impl.md。
• 步骤 11（性能与边界测试）：增加压力测试、边界测试、错误恢复测试、性能基准。输出 .tdd-cycle/11-extended-tests.md。

Phase 6：最终评审（步骤 12）

• 步骤 12（最终代码评审）：tdd-workflows-code-reviewer 审阅全部 .tdd-cycle/*.md 工件，验证 TDD 流程遵循度、代码质量与 SOLID 遵循、测试质量与覆盖完整性、反模式检查（test-after、跳过重构等），输出最终评审报告 .tdd-cycle/12-final-review.md。

5.5 完成与增量模式

工作流结束时更新 state.json 的 status 为 "complete"，并输出最终摘要：文件清单、TDD 度量（测试数、覆盖率、完成的阶段链 Specification > RED > GREEN > REFACTOR > Integration > Review、模式 incremental/suite）以及 12 个工件索引。

当使用 --incremental 标志时，编排者会调整 RED-GREEN-REFACTOR 各阶段，使其一次只操作一个测试：写一个失败测试 → 只让该测试通过 → 需要时重构 → 重复下一个测试，而非整套测试批处理。

六、单相位命令：tdd-red / tdd-green / tdd-refactor

除了全流程的 tdd-cycle，插件还提供三个可独立调用的单相位命令，适合已有部分工作、只想执行某一阶段的场景。

6.1 tdd-red：RED 相位生成失败测试

命令 tdd-red.md 的核心规则是"只写测试，不写生产代码；所有生成的测试运行时必须失败"。其生成提示要求覆盖：

• 测试结构：框架适配的 setup（Jest/pytest/JUnit/Go/RSpec，匹配项目约定）、Arrange-Act-Assert、should_X_when_Y 命名、无相互依赖的隔离 fixture
• 行为覆盖：快乐路径、边界用例（空值、null、边界值）、错误处理与异常、并发访问
• 失败验证：测试必须失败、失败原因正确（非语法/导入错误）、有意义的诊断错误信息、无级联失败
• 测试分类：单元（隔离组件行为）、集成（组件交互）、契约（API/接口契约）、属性（数学不变量）

命令还内置了边界用例分类清单：Null/Empty（undefined、null、空字符串/数组/对象）、边界（min/max 值、单元素、容量上限）、特殊用例（Unicode、空白、特殊字符）、状态（非法转换、并发修改）、错误（网络失败、超时、权限）。

6.2 tdd-green：GREEN 相位最小实现

命令 tdd-green.md 规定了三种经典实现策略：

• Fake It（假实现）：适当情况下返回硬编码值
• Obvious Implementation（直白实现）：解决方案琐碎清晰时直接实现
• Triangulation（三角测量）：仅在多个测试共同要求时才泛化

并强调渐进式实现原则：先用最简代码让第一个测试通过、每次变更后运行测试、只为下一个失败测试补充恰好足够的代码、抵制超出测试需求的实现冲动、为重构阶段记录技术债与假设。

6.3 tdd-refactor：安全重构

命令 tdd-refactor.md 直接调用 tdd-workflows-tdd-orchestrator Agent（Opus 模型）执行安全重构，包含 10 步核心流程：

1. 预评估：运行测试建立绿色基线、分析代码坏味道与覆盖、记录性能指标、制定增量重构计划
2. 坏味道检测：重复代码→抽取方法/类；长方法→分解；大类→拆分职责；长参数列表→参数对象；Feature Envy→移动方法；Primitive Obsession→值对象；switch 语句→多态；死代码→删除
3. 设计模式：创建型（Factory、Builder、Singleton）、结构型（Adapter、Facade、Decorator）、行为型（Strategy、Observer、Command）、领域型（Repository、Service、Value Objects）
4. SOLID 原则：单一职责、开闭、里氏替换、接口隔离、依赖倒置
5. 重构技法：Extract Method/Variable/Interface、Inline、Rename、Move Method/Field、Magic Number 替换为常量、封装字段、条件替换为多态、引入 Null Object
6. 性能优化：剖析定位瓶颈、优化算法与数据结构、合理缓存、减少数据库查询（消除 N+1）、懒加载与分页、前后测量
7. 增量步骤：小步原子变更、每次修改后运行测试、每次成功重构后提交、重构与行为变更分离
8. 架构演进：分层与依赖管理、模块边界与接口定义、事件驱动解耦、数据库访问模式优化
9. 安全验证：每次变更后跑全套测试、性能回归测试、变异测试验证测试有效性、重大变更回滚计划
10. 高级模式：Strangler Fig（渐进替换遗留系统）、Branch by Abstraction（大规模变更）、Parallel Change（展开-收缩）、Mikado Method（依赖图导航）

该命令还包含一个 TypeScript 的 Extract Method 重构示例（OrderProcessor 订单处理），展示了如何把一个大方法拆分为 validateOrder 等方法并应用值对象与依赖注入。

七、质量护栏：验证清单、反模式与失败恢复

7.1 三阶段验证清单

RED 阶段验证：

• 所有测试在实现之前编写
• 所有测试以有意义的错误消息失败
• 失败源于缺失实现
• 无测试意外通过

GREEN 阶段验证：

• 所有测试通过
• 无超出测试需求的额外代码
• 覆盖率达到最低阈值
• 无测试被修改以使其通过

REFACTOR 阶段验证：

• 重构后所有测试仍通过
• 代码复杂度降低
• 重复消除
• 性能提升或保持
• 测试可读性提升

7.2 需规避的反模式

• 在测试前编写实现
• 编写已经通过的测试
• 跳过重构阶段
• 无测试编写多个功能
• 修改测试使其通过
• 忽略失败测试
• 在实现后补写测试

7.3 失败恢复协议

一旦 TDD 纪律被破坏，按顺序执行：立即停止 → 识别被违反的阶段 → 回滚到最后一个有效状态 → 从正确阶段恢复 → 记录经验教训。

八、配套代码评审 Agent 与跨插件协作

工作流中的多个 GATE 与步骤（步骤 4、7、12）会调用本地 code-reviewer.md（model: opus）。该 Agent 的能力与 tdd-orchestrator 形成互补：它聚焦 AI 驱动的代码分析（Trag、Bito、Codiga、GitHub Copilot 集成）、静态分析工具（SonarQube、CodeQL、Semgrep、Snyk）、OWASP Top 10 安全评审、性能与可扩展性分析、配置与基础设施评审，并在"现代开发实践"能力域中明确包含"TDD 与测试覆盖分析、BDD 场景评审、契约测试与 API 兼容性验证"。

两者的分工可概括为：tdd-orchestrator 负责"流程编排与纪律强制"，code-reviewer 负责"质量把关与独立验证"，形成编排者-评审者的双 Agent 闭环。这种组合符合仓库架构中 architecture.md 描述的"Planning（Sonnet）→ Execution（Haiku）→ Review（Sonnet）"混合编排模式。

九、典型使用场景与调用方式

根据 Agent 定义中的 Example Interactions 章节，以下场景可直接使用：

• "为一个新的微服务项目编排完整的 TDD 实现"（Orchestrate a complete TDD implementation for a new microservices project）
• "设计协调单元与集成测试的多 Agent 工作流"
• "建立 TDD 合规监控与自动化质量门强制"
• "为复杂业务逻辑验证实现属性测试策略"
• "协调遗留代码重构并创建综合测试安全网"
• "设计团队生产力与质量追踪的 TDD 度量仪表盘"
• "创建带自动化合规检查的跨团队 TDD 治理框架"
• "编排带负载测试集成的性能 TDD 工作流"
• "实现变异测试流水线以验证测试套件质量"
• "设计 AI 辅助测试生成工作流以加速 TDD 循环"

在实际 harness 中，可通过斜杠命令直接触发各阶段命令，例如在 Claude Code 中执行：

# 完整 TDD 循环（套件模式，覆盖率目标 85%）
/tdd-workflows:tdd-cycle "用户认证模块" --suite --coverage 85

# 仅执行 RED 阶段（生成失败测试）
/tdd-workflows:tdd-red "用户认证模块"

# 仅执行 GREEN 阶段（最小实现）
/tdd-workflows:tdd-green "用户认证模块"

# 仅执行 REFACTOR 阶段（安全重构）
/tdd-workflows:tdd-refactor "重构认证服务并保持所有测试通过"

命令的 argument-hint 语法（见各命令 frontmatter）为：<feature or module to implement> [--incremental|--suite] [--coverage 80]。

十、总结：TDD 编排者的适用边界

tdd-orchestrator 与 tdd-workflows 插件在 agents24 仓库中扮演的角色，是把 TDD 从"个人编码习惯"提升为"可编排、可度量、可治理的工程流程"：

• 对个人开发者：通过 tdd-cycle 的检查点与 GATE 机制强制红绿重构纪律，避免 test-after 与跳过重构等常见反模式；
• 对多 Agent 协作：通过 general-purpose 与本地 tdd-workflows-code-reviewer 的分工，实现测试编写、实现、验证、重构的流水线化；
• 对团队与组织：通过多仓库治理、质量门、度量仪表盘与培训协调，将 TDD 扩展为组织级实践。

需要注意的是，本插件的 model: opus 配置意味着调用成本高于 Sonnet/Haiku 层级（可参考 docs/agents.md 中模型分层与 docs/architecture.md 的五层模型策略），因此在日常简单任务中建议按需调用，将 TDD 编排者聚焦于复杂功能、遗留代码改造与组织级治理场景，以平衡质量收益与成本开销。