agents24 tdd-workflows 插件实战用 tdd-cycle 命令编排严格的 12 步 Red-Green-Refactor 测试驱动开发循环【免费下载链接】agentsMulti-harness agentic plugin marketplace for Claude Code, Codex, Cursor, OpenCode, GitHub Copilot, and Google Antigravity项目地址: https://gitcode.com/GitHub_Trending/agents24/agents本文系统讲解 GitHub 推荐项目精选 / agents24 / agents 仓库中tdd-workflows插件核心命令tdd-cycle的完整机制一个由 6 大阶段、12 个执行步骤、4 个强制用户审批检查点构成的自动化 TDD 编排工作流。你将掌握该命令的状态机设计、.tdd-cycle/工作区产物约定、覆盖率与重构触发阈值、增量开发模式以及失败恢复协议并理解它与tdd-red/tdd-green/tdd-refactor三个独立命令及两个本地 Agent 的分工协作关系。一、tdd-cycle 是什么插件生态中的全流程 TDD 编排器tdd-workflows是当前仓库 94 个 marketplace 插件之一见 docs/plugins.md 的 Workflows 分类定位为Test-driven development methodology。插件结构遵循仓库统一的plugins/name/约定plugins/tdd-workflows/ ├── agents/ │ ├── code-reviewer.md # tdd-workflows-code-reviewer 本地代码评审 Agent │ └── tdd-orchestrator.md # tdd-workflows-tdd-orchestrator 主编排 Agentopus 模型 └── commands/ ├── tdd-cycle.md # 全流程 12 步编排本文主体 ├── tdd-red.md # 独立 RED 阶段命令 ├── tdd-green.md # 独立 GREEN 阶段命令 └── tdd-refactor.md # 独立 REFACTOR 阶段命令安装方式与仓库其他插件一致/plugin marketplace add wshobson/agents # 注册目录不加载任何内容 /plugin install tdd-workflows # 安装插件agents commands 一起安装后即可通过 docs/usage.md 中定义的 slash command 格式/plugin-name:command-name [arguments]调用/tdd-workflows:tdd-cycle 用户可以实现密码重置功能 --coverage 85命令头部 frontmatter 声明了其职责与参数形态description: Execute a comprehensive TDD workflow with strict red-green-refactor discipline argument-hint: feature or module to implement [--incremental|--suite] [--coverage 80]即命令接受一个特性/模块描述作为位置参数可选--incremental/--suite模式标志与--coverage覆盖率目标默认 80。二、六条不可违背的行为规则tdd-cycle开篇即声明CRITICAL BEHAVIORAL RULES任何违反都被视为失败严格按步骤顺序执行不得跳步、重排或合并步骤必须落盘输出文件每一步必须在进入下一步前把产物写入.tdd-cycle/目录后续步骤从文件读取前序产物而非依赖上下文窗口记忆——这是该设计对抗 LLM 长对话上下文丢失的关键机制检查点必须停顿到达PHASE CHECKPOINT时必须停下等待用户显式批准用 AskUserQuestion 提供清晰选项才能继续失败即停任何一步失败Agent 错误、测试失败、依赖缺失立即停止并向用户呈现错误与处理选项不得静默继续只用本地 Agent所有subagent_type只引用本插件自带的 Agenttdd-workflows-code-reviewer或general-purpose不产生跨插件依赖禁止自主进入计划模式不得调用 EnterPlanMode——这个命令本身就是计划直接执行。从源码结构看规则 2 的文件即状态设计配合.tdd-cycle/state.json使得整个工作流天然具备断点续跑与可审计能力。三、Pre-flight会话检测、状态初始化与参数解析3.1 会话恢复检测执行前先检查.tdd-cycle/state.json是否存在若存在且status为in_progress读取并展示当前步骤向用户提供从断点恢复 / 归档后重新开始两个选项若存在且status为complete询问是否归档并开启新一轮。这保证了多次会话之间不会产生状态冲突。3.2 状态文件初始化创建.tdd-cycle/目录并写入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 }字段语义如下字段含义feature从$ARGUMENTS解析出的特性描述statusin_progress/complete驱动会话恢复逻辑modesuite默认整批测试套件推进或incremental逐个测试推进coverage_target覆盖率目标来自--coverage默认 80current_step/current_phase当前执行步骤号 / 阶段号检查点处为checkpoint-N字符串completed_steps/files_created已完成步骤列表 / 已生成产物清单用于审计与恢复started_at/last_updated开始与最近更新时间戳$ARGUMENTS中--incremental、--suite、--coverage三个标志被显式解析未指定时回退默认值mode: suitecoverage: 80标志之前的全部文本作为特性描述$FEATURE注入到后续所有 Task prompt 的占位符中。四、Configuration覆盖率阈值与重构触发器命令内置两组硬性质量参数覆盖率阈值指标阈值行覆盖率line coverage由--coverage指定默认 80%分支覆盖率branch coverage固定 75%关键路径覆盖率critical path coverage固定 100%重构触发器Refactoring Triggers——任一命中即必须触发重构圈复杂度Cyclomatic complexity 10方法长度 20 行类长度 200 行重复代码块 3 行这些阈值在 Phase 4 的 Step 7 中被显式引用为应用重构触发器的操作依据与 tdd-refactor.md 中代码坏味道检测清单重复代码提取方法、长方法分解、大类拆分、长参数列表转参数对象等相互印证。五、六阶段十二步全流程详解Phase 1测试规格与设计Step 1–2Step 1需求分析。调用general-purpose子 Agent 分析$FEATURE交付物包括带明确 pass/fail 条件的验收标准、边界用例清单null/空值、边界值、错误状态、并发访问、需求到测试用例的完整场景矩阵、测试分类unit/integration/contract/property-based、需要 mock 的外部依赖清单。产物落盘为.tdd-cycle/01-requirements.md随后更新state.json。Step 2测试架构设计。读取01-requirements.md作为上下文调用测试自动化专家子 Agent 输出测试目录结构与命名约定、fixture 设计共享 setup/teardown、测试数据工厂、mock/stub 策略哪些 mock、哪些用真实实现、测试数据策略生成器、工厂、边界数据集、执行顺序与并行化方案、与项目现有测试框架匹配的框架配置。产物为.tdd-cycle/02-test-architecture.mdcurrent_step置为checkpoint-1。PHASE CHECKPOINT 1强制停顿向用户呈现两份文档摘要并给出三个选项1. Approve — 进入 RED 阶段/2. Request changes/3. Pause。只有选择 1 才允许进入 Phase 2选择 2 则修订后重新检查点选择 3 则更新状态并停止。Phase 2RED——先写失败测试Step 3–4Step 3编写必然失败的单元测试。注入01-requirements.md与02-test-architecture.md要求测试初始必须失败、不得实现任何生产代码覆盖边界用例、错误场景与 happy path沿用项目既有测试框架与约定遵循 Arrange-Act-Assert 模式测试命名用should_X_when_Y确保失败原因是正确的缺实现而非语法错误。产物.tdd-cycle/03-failing-tests.md测试文件清单、测试数量、覆盖领域。Step 4验证测试确实失败。这里切换为本地代码评审 Agenttdd-workflows-code-reviewer执行验证运行测试套件确认新测试全部失败失败原因正确缺实现而非测试自身错误无意外通过的假阳性未破坏既有测试检查测试质量命名有意义、断言正确、错误信息可读。产物.tdd-cycle/04-failure-verification.md。GATE 门禁除非所有测试都以恰当方式失败否则不得进入 Phase 3验证失败则修复测试后重新验证。tdd-workflows-code-reviewer的职责在 agents/code-reviewer.md 中有完整定义——它兼任静态分析、安全审查、性能评估与TDD/测试覆盖分析。PHASE CHECKPOINT 2汇报测试数量、覆盖领域、验证结论三个选项同上Approve / Request changes / Pause。Phase 3GREEN——让测试通过Step 5–6Step 5最小实现。注入需求、架构与失败测试三份文档严格要求只以让测试变绿为目标不添加任何额外功能或优化用最简单能通过测试的实现遵循项目既有代码风格保持方法小而专注除非测试要求否则不添加错误处理记录为重构阶段预留的捷径与技术债。产物.tdd-cycle/05-implementation.md。Step 6验证测试全部通过。调用general-purpose运行完整测试套件、确认全部新测试通过green、确认未破坏既有测试、对照目标检查覆盖率指标、确认实现真正最小化无镀金 gold plating。产物.tdd-cycle/06-green-verification.md。GATE 门禁所有测试必须通过才能继续失败则返回 Step 5 修复。此处的最小实现方法论与 tdd-green.md 完全一致——后者更详细地给出了三种实现策略Fake It适当返回硬编码值、Obvious Implementation解决方案清晰直白时、Triangulation仅当多个测试共同要求时才泛化。PHASE CHECKPOINT 3汇报通过/失败计数与覆盖率指标等待批准进入 REFACTOR。Phase 4REFACTOR——在绿灯保护下提升质量Step 7–8Step 7代码重构。再次调用tdd-workflows-code-reviewer要求适当应用 SOLID 原则、消除重复代码、改善命名、在测试支持下优化性能、每步重构后必须运行测试且保持全绿、应用上文的重构触发器复杂度 10 / 方法 20 行 / 类 200 行 / 重复 3 行。产物.tdd-cycle/07-refactored-code.md。Step 8测试重构。调用general-purpose消除测试重复提取公共 fixture、改善测试命名使其具备文档价值、保证覆盖不缩水、优化测试执行速度、验证覆盖率指标持平或提升。产物.tdd-cycle/08-refactored-tests.md。PHASE CHECKPOINT 4汇报代码变更摘要、测试改进摘要与覆盖率结论批准后进入集成测试阶段。Phase 5集成与扩展测试Step 9–11Step 9先写失败的集成测试。基于07-refactored-code.md测试组件交互、API 契约与数据流遵循 red-green-refactor 先失败聚焦架构中识别的集成点包含 API 边界的契约测试沿用项目测试模式。产物.tdd-cycle/09-integration-tests.md。Step 10实现集成代码。只实现让集成测试通过所需的部分聚焦组件交互与数据流。产物.tdd-cycle/10-integration-impl.md。Step 11性能与边界测试。增加压力测试与边界测试、错误恢复测试、适当的性能基准全部新测试必须通过。产物.tdd-cycle/11-extended-tests.md。Phase 6最终评审Step 12Step 12最终代码评审。读取全部.tdd-cycle/*.md产物调用tdd-workflows-code-reviewer做综合评审验证 red-green-refactor 纪律是否被完整遵循、代码质量与 SOLID 遵守度、测试质量与覆盖完整性、是否出现反模式test-after、跳过重构等、提出剩余改进建议。产物.tdd-cycle/12-final-review.mdcurrent_step置为complete。六、Completion收尾汇总与产物清单state.json置status: complete并刷新last_updated随后向用户输出最终摘要包含Files Created全部 12 份.tdd-cycle/产物TDD Metrics测试总数、行/分支/函数覆盖率、完成的阶段链Specification RED GREEN REFACTOR Integration Review、运行模式incremental/suiteArtifacts从01-requirements.md到12-final-review.md的逐项映射Next Steps审查产物 → 运行完整测试套件 → 创建 PR → 在 CI 中持续监控覆盖率。最终产物的 12 个文件构成一条完整、可追溯的 TDD 证据链需求 → 架构 → 失败测试 → 失败验证 → 实现 → 绿灯验证 → 重构后代码 → 重构后测试 → 集成测试 → 集成实现 → 扩展测试 → 最终评审。七、Incremental 增量模式当传入--incremental标志时编排器将 RED-GREEN-REFACTOR 从整批测试套件粒度收缩为单测试粒度写一个失败的测试只让这一个测试通过需要则重构对下一个测试重复。该模式在state.json的mode字段中持久化适合大型特性分片推进或对已有代码库做增量 TDD 改造与 agents/tdd-orchestrator.md 中Legacy code characterization通过补测试刻画遗留代码与 Incremental TDD adoption strategies for existing codebases 的能力定位一致。八、Validation Checklists 与 Anti-Patterns质量守门双清单三个阶段的校验清单Checklist 全部勾选才算通过RED 阶段校验所有测试写在实现之前所有测试以有意义的错误信息失败失败源于缺失实现无意外通过的测试GREEN 阶段校验所有测试通过无超出测试需求的额外代码覆盖率满足最低阈值未通过修改测试来使其通过REFACTOR 阶段校验重构后所有测试仍通过代码复杂度降低重复消除性能提升或保持测试可读性提升必须规避的反模式Anti-Patterns to Avoid在测试前写实现test-first 倒置编写一开始就通过的测试跳过重构阶段无测试地开发多个特性修改测试使其通过忽视失败测试在实现之后补写测试test-after这些清单与 tdd-red.md 中质量检查清单可读测试名、一测一行为、无实现泄漏、有意义的测试数据、测试即活文档及反模式清单立即通过的测试、测实现而非行为、复杂 setup、多职责测试、绑定实现细节的脆弱测试互为补充构成同一套 TDD 纪律的两层表达。九、Failure Recovery纪律被破坏时的恢复协议一旦 TDD 纪律被破坏命令规定了五步恢复流程STOP——立即停止识别被违反的是哪个阶段回滚到最后一个有效状态得益于.tdd-cycle/落盘产物与state.json可精确定位断点从正确阶段恢复执行记录经验教训。值得说明的是state.json中的completed_steps、files_created、current_step三个字段正是为此恢复协议服务的它们让回滚到最后一个有效状态从口头承诺变为可执行的机械操作。十、配套命令与 Agenttdd-cycle 之外的组合用法tdd-cycle是全流程编排入口但插件同时提供了三个可独立调用的阶段命令见 docs/usage.md 的 Testing Quality 命令表/tdd-workflows:tdd-red 用户可以实现密码重置功能 # 只写失败测试 /tdd-workflows:tdd-green # 只做最小实现 /tdd-workflows:tdd-refactor # 只在全绿前提下重构三者与tdd-cycle的边界tdd-cycle内部各步骤实质上是这三个命令的纪律化串联并在每阶段之间插入强制审批检查点与落盘证据链而独立命令适合已经熟悉流程、只想聚焦单一阶段的场景。其中 tdd-refactor.md 还包含完整的 TypeScript 重构示例Extract Method、Value Objects、依赖注入、异步模式可作为 Step 7 重构技术的手把手参考。支撑这两个命令层的是插件自带的两个本地 Agenttdd-workflows-tdd-orchestratoropus 模型agents/tdd-orchestrator.md主编排者掌握 Chicago/London 双流派、ATDD/BDD、属性测试、突变测试等 11 大类能力与tdd-workflows-code-revieweragents/code-reviewer.md负责 Step 4/7/12 的评审与门禁。二者均遵循Use only local agents规则整个插件无任何跨插件依赖符合仓库插件单一职责、最小 Token 占用、可组合的设计原则见 docs/plugins.md 的 Plugin Design Principles 章节。十一、适用前提与限制运行环境本命令面向 Claude Code 等支持 slash command、Task 子 Agent 与 AskUserQuestion 的 Agent harness仓库通过 tools/adapters 将同一套 Markdown 源转译到 Codex、Cursor、OpenCode、Antigravity 等环境但tdd-cycle的完整交互语义检查点、AskUserQuestion、子 Agent 协作以原生支持的 harness 为准Agent 依赖Step 4、7、12 强依赖tdd-workflows-code-reviewer安装插件时该 Agent 随插件一并装入插件是安装单元见 docs/usage.md 的安装说明工作区约定命令会在当前项目根目录创建.tdd-cycle/目录并写入 12 份产物与state.json这既是证据链也是后续会话恢复的依据不应手工删除覆盖率工具Step 6 的覆盖率核对依赖项目已有的测试覆盖率工具链coverage_target默认 80% 可通过--coverage覆盖分支 75% 与关键路径 100% 为命令内置固定值。综上tdd-cycle的工程价值在于它把 TDD 从个人纪律固化为可执行的机器流程——用强制检查点对抗 LLM 的一条路走到底倾向用落盘产物对抗上下文丢失用双 GATE 门禁与三份校验清单保证每一阶段质量达标最终交付一条从需求到最终评审的完整、可审计、可断点续跑的证据链。【免费下载链接】agentsMulti-harness agentic plugin marketplace for Claude Code, Codex, Cursor, OpenCode, GitHub Copilot, and Google Antigravity项目地址: https://gitcode.com/GitHub_Trending/agents24/agents创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 agents24 tdd-workflows 插件实战：用 tdd-cycle 命令编排严格的 12 步 Red-Green-Refactor 测试驱动开发循环
agents24 tdd-workflows 插件实战用 tdd-cycle 命令编排严格的 12 步 Red-Green-Refactor 测试驱动开发循环【免费下载链接】agentsMulti-harness agentic plugin marketplace for Claude Code, Codex, Cursor, OpenCode, GitHub Copilot, and Google Antigravity项目地址: https://gitcode.com/GitHub_Trending/agents24/agents本文系统讲解 GitHub 推荐项目精选 / agents24 / agents 仓库中tdd-workflows插件核心命令tdd-cycle的完整机制一个由 6 大阶段、12 个执行步骤、4 个强制用户审批检查点构成的自动化 TDD 编排工作流。你将掌握该命令的状态机设计、.tdd-cycle/工作区产物约定、覆盖率与重构触发阈值、增量开发模式以及失败恢复协议并理解它与tdd-red/tdd-green/tdd-refactor三个独立命令及两个本地 Agent 的分工协作关系。一、tdd-cycle 是什么插件生态中的全流程 TDD 编排器tdd-workflows是当前仓库 94 个 marketplace 插件之一见 docs/plugins.md 的 Workflows 分类定位为Test-driven development methodology。插件结构遵循仓库统一的plugins/name/约定plugins/tdd-workflows/ ├── agents/ │ ├── code-reviewer.md # tdd-workflows-code-reviewer 本地代码评审 Agent │ └── tdd-orchestrator.md # tdd-workflows-tdd-orchestrator 主编排 Agentopus 模型 └── commands/ ├── tdd-cycle.md # 全流程 12 步编排本文主体 ├── tdd-red.md # 独立 RED 阶段命令 ├── tdd-green.md # 独立 GREEN 阶段命令 └── tdd-refactor.md # 独立 REFACTOR 阶段命令安装方式与仓库其他插件一致/plugin marketplace add wshobson/agents # 注册目录不加载任何内容 /plugin install tdd-workflows # 安装插件agents commands 一起安装后即可通过 docs/usage.md 中定义的 slash command 格式/plugin-name:command-name [arguments]调用/tdd-workflows:tdd-cycle 用户可以实现密码重置功能 --coverage 85命令头部 frontmatter 声明了其职责与参数形态description: Execute a comprehensive TDD workflow with strict red-green-refactor discipline argument-hint: feature or module to implement [--incremental|--suite] [--coverage 80]即命令接受一个特性/模块描述作为位置参数可选--incremental/--suite模式标志与--coverage覆盖率目标默认 80。二、六条不可违背的行为规则tdd-cycle开篇即声明CRITICAL BEHAVIORAL RULES任何违反都被视为失败严格按步骤顺序执行不得跳步、重排或合并步骤必须落盘输出文件每一步必须在进入下一步前把产物写入.tdd-cycle/目录后续步骤从文件读取前序产物而非依赖上下文窗口记忆——这是该设计对抗 LLM 长对话上下文丢失的关键机制检查点必须停顿到达PHASE CHECKPOINT时必须停下等待用户显式批准用 AskUserQuestion 提供清晰选项才能继续失败即停任何一步失败Agent 错误、测试失败、依赖缺失立即停止并向用户呈现错误与处理选项不得静默继续只用本地 Agent所有subagent_type只引用本插件自带的 Agenttdd-workflows-code-reviewer或general-purpose不产生跨插件依赖禁止自主进入计划模式不得调用 EnterPlanMode——这个命令本身就是计划直接执行。从源码结构看规则 2 的文件即状态设计配合.tdd-cycle/state.json使得整个工作流天然具备断点续跑与可审计能力。三、Pre-flight会话检测、状态初始化与参数解析3.1 会话恢复检测执行前先检查.tdd-cycle/state.json是否存在若存在且status为in_progress读取并展示当前步骤向用户提供从断点恢复 / 归档后重新开始两个选项若存在且status为complete询问是否归档并开启新一轮。这保证了多次会话之间不会产生状态冲突。3.2 状态文件初始化创建.tdd-cycle/目录并写入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 }字段语义如下字段含义feature从$ARGUMENTS解析出的特性描述statusin_progress/complete驱动会话恢复逻辑modesuite默认整批测试套件推进或incremental逐个测试推进coverage_target覆盖率目标来自--coverage默认 80current_step/current_phase当前执行步骤号 / 阶段号检查点处为checkpoint-N字符串completed_steps/files_created已完成步骤列表 / 已生成产物清单用于审计与恢复started_at/last_updated开始与最近更新时间戳$ARGUMENTS中--incremental、--suite、--coverage三个标志被显式解析未指定时回退默认值mode: suitecoverage: 80标志之前的全部文本作为特性描述$FEATURE注入到后续所有 Task prompt 的占位符中。四、Configuration覆盖率阈值与重构触发器命令内置两组硬性质量参数覆盖率阈值指标阈值行覆盖率line coverage由--coverage指定默认 80%分支覆盖率branch coverage固定 75%关键路径覆盖率critical path coverage固定 100%重构触发器Refactoring Triggers——任一命中即必须触发重构圈复杂度Cyclomatic complexity 10方法长度 20 行类长度 200 行重复代码块 3 行这些阈值在 Phase 4 的 Step 7 中被显式引用为应用重构触发器的操作依据与 tdd-refactor.md 中代码坏味道检测清单重复代码提取方法、长方法分解、大类拆分、长参数列表转参数对象等相互印证。五、六阶段十二步全流程详解Phase 1测试规格与设计Step 1–2Step 1需求分析。调用general-purpose子 Agent 分析$FEATURE交付物包括带明确 pass/fail 条件的验收标准、边界用例清单null/空值、边界值、错误状态、并发访问、需求到测试用例的完整场景矩阵、测试分类unit/integration/contract/property-based、需要 mock 的外部依赖清单。产物落盘为.tdd-cycle/01-requirements.md随后更新state.json。Step 2测试架构设计。读取01-requirements.md作为上下文调用测试自动化专家子 Agent 输出测试目录结构与命名约定、fixture 设计共享 setup/teardown、测试数据工厂、mock/stub 策略哪些 mock、哪些用真实实现、测试数据策略生成器、工厂、边界数据集、执行顺序与并行化方案、与项目现有测试框架匹配的框架配置。产物为.tdd-cycle/02-test-architecture.mdcurrent_step置为checkpoint-1。PHASE CHECKPOINT 1强制停顿向用户呈现两份文档摘要并给出三个选项1. Approve — 进入 RED 阶段/2. Request changes/3. Pause。只有选择 1 才允许进入 Phase 2选择 2 则修订后重新检查点选择 3 则更新状态并停止。Phase 2RED——先写失败测试Step 3–4Step 3编写必然失败的单元测试。注入01-requirements.md与02-test-architecture.md要求测试初始必须失败、不得实现任何生产代码覆盖边界用例、错误场景与 happy path沿用项目既有测试框架与约定遵循 Arrange-Act-Assert 模式测试命名用should_X_when_Y确保失败原因是正确的缺实现而非语法错误。产物.tdd-cycle/03-failing-tests.md测试文件清单、测试数量、覆盖领域。Step 4验证测试确实失败。这里切换为本地代码评审 Agenttdd-workflows-code-reviewer执行验证运行测试套件确认新测试全部失败失败原因正确缺实现而非测试自身错误无意外通过的假阳性未破坏既有测试检查测试质量命名有意义、断言正确、错误信息可读。产物.tdd-cycle/04-failure-verification.md。GATE 门禁除非所有测试都以恰当方式失败否则不得进入 Phase 3验证失败则修复测试后重新验证。tdd-workflows-code-reviewer的职责在 agents/code-reviewer.md 中有完整定义——它兼任静态分析、安全审查、性能评估与TDD/测试覆盖分析。PHASE CHECKPOINT 2汇报测试数量、覆盖领域、验证结论三个选项同上Approve / Request changes / Pause。Phase 3GREEN——让测试通过Step 5–6Step 5最小实现。注入需求、架构与失败测试三份文档严格要求只以让测试变绿为目标不添加任何额外功能或优化用最简单能通过测试的实现遵循项目既有代码风格保持方法小而专注除非测试要求否则不添加错误处理记录为重构阶段预留的捷径与技术债。产物.tdd-cycle/05-implementation.md。Step 6验证测试全部通过。调用general-purpose运行完整测试套件、确认全部新测试通过green、确认未破坏既有测试、对照目标检查覆盖率指标、确认实现真正最小化无镀金 gold plating。产物.tdd-cycle/06-green-verification.md。GATE 门禁所有测试必须通过才能继续失败则返回 Step 5 修复。此处的最小实现方法论与 tdd-green.md 完全一致——后者更详细地给出了三种实现策略Fake It适当返回硬编码值、Obvious Implementation解决方案清晰直白时、Triangulation仅当多个测试共同要求时才泛化。PHASE CHECKPOINT 3汇报通过/失败计数与覆盖率指标等待批准进入 REFACTOR。Phase 4REFACTOR——在绿灯保护下提升质量Step 7–8Step 7代码重构。再次调用tdd-workflows-code-reviewer要求适当应用 SOLID 原则、消除重复代码、改善命名、在测试支持下优化性能、每步重构后必须运行测试且保持全绿、应用上文的重构触发器复杂度 10 / 方法 20 行 / 类 200 行 / 重复 3 行。产物.tdd-cycle/07-refactored-code.md。Step 8测试重构。调用general-purpose消除测试重复提取公共 fixture、改善测试命名使其具备文档价值、保证覆盖不缩水、优化测试执行速度、验证覆盖率指标持平或提升。产物.tdd-cycle/08-refactored-tests.md。PHASE CHECKPOINT 4汇报代码变更摘要、测试改进摘要与覆盖率结论批准后进入集成测试阶段。Phase 5集成与扩展测试Step 9–11Step 9先写失败的集成测试。基于07-refactored-code.md测试组件交互、API 契约与数据流遵循 red-green-refactor 先失败聚焦架构中识别的集成点包含 API 边界的契约测试沿用项目测试模式。产物.tdd-cycle/09-integration-tests.md。Step 10实现集成代码。只实现让集成测试通过所需的部分聚焦组件交互与数据流。产物.tdd-cycle/10-integration-impl.md。Step 11性能与边界测试。增加压力测试与边界测试、错误恢复测试、适当的性能基准全部新测试必须通过。产物.tdd-cycle/11-extended-tests.md。Phase 6最终评审Step 12Step 12最终代码评审。读取全部.tdd-cycle/*.md产物调用tdd-workflows-code-reviewer做综合评审验证 red-green-refactor 纪律是否被完整遵循、代码质量与 SOLID 遵守度、测试质量与覆盖完整性、是否出现反模式test-after、跳过重构等、提出剩余改进建议。产物.tdd-cycle/12-final-review.mdcurrent_step置为complete。六、Completion收尾汇总与产物清单state.json置status: complete并刷新last_updated随后向用户输出最终摘要包含Files Created全部 12 份.tdd-cycle/产物TDD Metrics测试总数、行/分支/函数覆盖率、完成的阶段链Specification RED GREEN REFACTOR Integration Review、运行模式incremental/suiteArtifacts从01-requirements.md到12-final-review.md的逐项映射Next Steps审查产物 → 运行完整测试套件 → 创建 PR → 在 CI 中持续监控覆盖率。最终产物的 12 个文件构成一条完整、可追溯的 TDD 证据链需求 → 架构 → 失败测试 → 失败验证 → 实现 → 绿灯验证 → 重构后代码 → 重构后测试 → 集成测试 → 集成实现 → 扩展测试 → 最终评审。七、Incremental 增量模式当传入--incremental标志时编排器将 RED-GREEN-REFACTOR 从整批测试套件粒度收缩为单测试粒度写一个失败的测试只让这一个测试通过需要则重构对下一个测试重复。该模式在state.json的mode字段中持久化适合大型特性分片推进或对已有代码库做增量 TDD 改造与 agents/tdd-orchestrator.md 中Legacy code characterization通过补测试刻画遗留代码与 Incremental TDD adoption strategies for existing codebases 的能力定位一致。八、Validation Checklists 与 Anti-Patterns质量守门双清单三个阶段的校验清单Checklist 全部勾选才算通过RED 阶段校验所有测试写在实现之前所有测试以有意义的错误信息失败失败源于缺失实现无意外通过的测试GREEN 阶段校验所有测试通过无超出测试需求的额外代码覆盖率满足最低阈值未通过修改测试来使其通过REFACTOR 阶段校验重构后所有测试仍通过代码复杂度降低重复消除性能提升或保持测试可读性提升必须规避的反模式Anti-Patterns to Avoid在测试前写实现test-first 倒置编写一开始就通过的测试跳过重构阶段无测试地开发多个特性修改测试使其通过忽视失败测试在实现之后补写测试test-after这些清单与 tdd-red.md 中质量检查清单可读测试名、一测一行为、无实现泄漏、有意义的测试数据、测试即活文档及反模式清单立即通过的测试、测实现而非行为、复杂 setup、多职责测试、绑定实现细节的脆弱测试互为补充构成同一套 TDD 纪律的两层表达。九、Failure Recovery纪律被破坏时的恢复协议一旦 TDD 纪律被破坏命令规定了五步恢复流程STOP——立即停止识别被违反的是哪个阶段回滚到最后一个有效状态得益于.tdd-cycle/落盘产物与state.json可精确定位断点从正确阶段恢复执行记录经验教训。值得说明的是state.json中的completed_steps、files_created、current_step三个字段正是为此恢复协议服务的它们让回滚到最后一个有效状态从口头承诺变为可执行的机械操作。十、配套命令与 Agenttdd-cycle 之外的组合用法tdd-cycle是全流程编排入口但插件同时提供了三个可独立调用的阶段命令见 docs/usage.md 的 Testing Quality 命令表/tdd-workflows:tdd-red 用户可以实现密码重置功能 # 只写失败测试 /tdd-workflows:tdd-green # 只做最小实现 /tdd-workflows:tdd-refactor # 只在全绿前提下重构三者与tdd-cycle的边界tdd-cycle内部各步骤实质上是这三个命令的纪律化串联并在每阶段之间插入强制审批检查点与落盘证据链而独立命令适合已经熟悉流程、只想聚焦单一阶段的场景。其中 tdd-refactor.md 还包含完整的 TypeScript 重构示例Extract Method、Value Objects、依赖注入、异步模式可作为 Step 7 重构技术的手把手参考。支撑这两个命令层的是插件自带的两个本地 Agenttdd-workflows-tdd-orchestratoropus 模型agents/tdd-orchestrator.md主编排者掌握 Chicago/London 双流派、ATDD/BDD、属性测试、突变测试等 11 大类能力与tdd-workflows-code-revieweragents/code-reviewer.md负责 Step 4/7/12 的评审与门禁。二者均遵循Use only local agents规则整个插件无任何跨插件依赖符合仓库插件单一职责、最小 Token 占用、可组合的设计原则见 docs/plugins.md 的 Plugin Design Principles 章节。十一、适用前提与限制运行环境本命令面向 Claude Code 等支持 slash command、Task 子 Agent 与 AskUserQuestion 的 Agent harness仓库通过 tools/adapters 将同一套 Markdown 源转译到 Codex、Cursor、OpenCode、Antigravity 等环境但tdd-cycle的完整交互语义检查点、AskUserQuestion、子 Agent 协作以原生支持的 harness 为准Agent 依赖Step 4、7、12 强依赖tdd-workflows-code-reviewer安装插件时该 Agent 随插件一并装入插件是安装单元见 docs/usage.md 的安装说明工作区约定命令会在当前项目根目录创建.tdd-cycle/目录并写入 12 份产物与state.json这既是证据链也是后续会话恢复的依据不应手工删除覆盖率工具Step 6 的覆盖率核对依赖项目已有的测试覆盖率工具链coverage_target默认 80% 可通过--coverage覆盖分支 75% 与关键路径 100% 为命令内置固定值。综上tdd-cycle的工程价值在于它把 TDD 从个人纪律固化为可执行的机器流程——用强制检查点对抗 LLM 的一条路走到底倾向用落盘产物对抗上下文丢失用双 GATE 门禁与三份校验清单保证每一阶段质量达标最终交付一条从需求到最终评审的完整、可审计、可断点续跑的证据链。【免费下载链接】agentsMulti-harness agentic plugin marketplace for Claude Code, Codex, Cursor, OpenCode, GitHub Copilot, and Google Antigravity项目地址: https://gitcode.com/GitHub_Trending/agents24/agents创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考