Develop TDD 是一个测试驱动开发（TDD）子代理技能，运行在任务工作树中，由 develop-change 派发。它一次只处理一个计划任务，或处理 TEST 一致性审查发现的问题。
用途 该技能用于在隔离的任务工作树中，以红-绿 TDD 循环实现一个计划任务的行为，或修复 TEST 一致性审查发现的问题。它强调：没有失败的测试就不写生产代码。
主要能力
- 红-绿循环：一次一个行为。RED 阶段写一个最小测试并观察其因正确原因失败；GREEN 阶段写最小代码使其通过；REFACTOR 阶段处理重复、命名和辅助函数，保持行为不变且测试通过；然后提交并进入下一个测试。
- 测试标注：每个新测试需声明其验证内容，格式为注释或测试名中的
# verifies: <IDs>。应标注存在的最低需求层级：有 LLR 时验证 LLR（父 REQ 被传递覆盖）；无 LLR 时直接验证 REQ 或 RC。若无法标注，说明被测需求不存在，需先运行 grill-requirements（或针对风险控制行为运行 analyze-risks）。 - 验证 RED：运行测试并观察其因正确原因失败（功能缺失，而非拼写错误）。立即通过的测试不能证明任何东西。
- 验证 GREEN：运行测试，然后运行指南文件 Test runs 部分指定的选择；输出需干净。若指南文件无 Test runs 部分，或运行器无法选择，则使用项目的 verify_commands。
- 类规则：从 .guardrails/config.yaml 读取 safety_class。B 和 C 级适用健壮性规则：每个 REQ 和 LLR 都需有正常用例测试和异常输入测试（错误输入、边界值、资源耗尽、依赖失败）。仅有正常路径测试的需求不算已验证。C 级还要求变更触及的每个 SDD 项在其自身接口（其 LLR）上测试，而不仅是端到端。
- 缺陷处理：缺陷即缺失的测试。将其复现为标注了所违反 REQ 的失败测试，然后修复。若缺陷揭示了 RMF 遗漏的危害，需在关闭前运行 analyze-risks。
使用方式 在开始时声明："Using the develop-tdd skill for task ."。前置条件：由 develop-change 派发，附带一个计划任务或 TEST 一致性审查的发现、任务工作树路径，以及 guidelines-file.sh TEST 为任务各路径打印的指南文件。按提示创建任务工作树，仅在其中工作，在任务分支上提交并保留，不合并、不再次派发。修复派发与普通任务一样：每个发现都在循环下修复，引用其命名的条款，或报告为未修复并说明原因。
在 RED 之前，为任务选择指南文件： sh .guardrails/scripts/guidelines-file.sh TEST <the paths the task touches> 对每个路径，遵循其打印的唯一文件（单元的、项目的或已安装的默认）；不读其他指南文件。测试附加位置和可使用的替身（doubles）在该文件中说明。若退出码为 2 或文件缺失，停止并重新安装 guardrails 脚本和模板（ratchet 的升级）；绝不在没有指南文件的情况下继续。与技能矛盾的条款视为对该条款的发现：本技能优先，派发报告需指明该条款。
派发报告 仅返回以下格式，不含差异、日志或叙述： task: <ID> worktree: <path to the task worktree> files touched: <paths> tests added: <test name — verifies: <IDs>> (one per line) red -> green: <test name> — watched fail for the right reason before the implementation existed (one per line, one per test) inherited: <test name> — from <old ID> result: <N passed, N failed> fixed: <finding-N — what changed, or "not fixed — <reason>"> (a fix dispatch only, one per finding) surprises: <anything unexpected, or "none"> 每个新测试写一行 red -> green:，这是测试在实现存在前失败的唯 一记录。inherited: 行命名被取代项的既有测试，该任务将其指向后继项；它是覆盖，不是红先证据：后继项仍需自己的 red -> green: 测试。绝不重新标注任务前已通过的任何其他测试。worktree: 是提示中声明的路径；在其他地方工作视为任务未工作，需在 surprises: 下说明。
适用场景 适用于在 guardrails 框架下、由 develop-change 派发的单个计划任务的 TDD 实现，或 TEST 一致性审查发现的修复。
限制
- 仅在工作树中工作，不合并任务分支。
- 没有失败的测试就不写生产代码；若先写了代码，删除并从测试重新开始。
- 每个路径只读一个指南文件；项目文件省略的规则即省略。
- 若指南文件缺失或退出码为 2，必须停止并重新安装，不得继续。
- 无法标注测试时，需先运行 grill-requirements 或 analyze-risks。
- 派发报告格式固定，不返回差异、日志或叙述。
完成条件 任务的每个行为都有测试，且该测试被观察为因正确原因失败然后通过；修复派发中，每个发现都已修复或报告为未修复并附原因。选择为绿色且输出干净。工作已提交在任务分支上且未合并。派发报告已返回，每个新测试一行 red -> green:。