用途：在用户明确指定 tdd，或上游任务明确调用该技能时，以测试先行的方式实现功能或修复缺陷。
核心理念：测试应通过最稳定的契约边界验证可观察行为，而非偶然的实现细节。代码可以完全重写，只要行为不变，测试就不应失败。好的测试接近集成风格，通过公开 API 走真实代码路径，读起来像规格说明；坏的测试耦合实现，例如 mock 内部协作者、测私有方法或断言偶然的调用顺序。持久化、幂等、并发、队列与恢复等契约，可能需要新进程、独立连接、提交后读取或持久状态断言来验证，不能仅凭绿色响应或 mock 交互代替真实不变量。
语言与工具：行为优先于实现、只在系统边界 mock、深模块等原则与语言无关；文中的 TypeScript/Jest 示例仅用于说明。写测试前应检测项目所用语言、测试运行器、断言风格与 mock 约定并沿用，例如 Python 用 pytest 惯用法与 fixture，PHP 用 PHPUnit 约定，JS/TS 用项目已有的 Jest/Vitest/node:test。
反模式：横向切片。不要先写全部测试再写全部实现。批量写出的测试测的是想象的行为而非实际行为，容易测数据结构与函数签名等形状，对真实变化不敏感。正确做法是纵向切片（曳光弹）：一个测试→一个实现→重复，每个测试回应上一轮学到的内容。
契约门：编辑前先阅读仓库说明与权威任务、简报、规格或评审结论，检查实现与测试以判断契约是否就绪。若行为、范围、公开接口、验收与授权已固定，视为已批准，直接开始第一个 RED 循环，不要求用户再次确认已有决定。技术细节若不影响产品行为或范围，可从仓库证据中解决。若工件冲突，或行为、范围、接口、优先级、授权仍有实质待决，则不要写入仓库，应报告证据冲突并提出一个具体的阻塞性问题。缺少工单、路线图或单独测试计划等仪式性产物，在直接请求权威且完整时不构成阻塞。
工作流：1) 首次 RED：功能选已批准契约中最薄的端到端行为，缺陷则先在能证明问题的边界复现故障；写一个聚焦测试并运行，只有因预期缺失或错误行为而失败才算有效 RED，语法错误、夹具损坏、依赖不可用或无关的既有失败不算。2) GREEN：写最小的根因正确改动使聚焦行为通过，且不违反已知契约。运行聚焦测试确认 GREEN 后再继续。3) 增量循环：每次一个测试，只写通过当前测试所需的代码，不预判未来测试，测试聚焦可观察行为，下一测试来自上一轮证据；完成前覆盖任务负责的成功、失败、边界与同根回归面。4) 重构：全部测试通过后寻找重构点，如提取重复、加深模块、在自然处应用 SOLID，每步后运行测试；RED 状态绝不重构，先到 GREEN。聚焦循环通过后运行相关更大范围测试，区分无关的既有失败与任务引入的回归，不得静默修复或隐藏无关失败。
每轮检查清单：测试描述行为而非实现；测试使用稳定可观察边界；测试能在内部重构后存活；RED 因预期原因失败；代码对当前测试最小；未添加投机性功能。文中提及 tests.md 与 mocking.md 作为示例与 mock 指南，但未提供其内容。