用途：这是一份测试驱动开发（TDD）实践规范，适用于新功能、缺陷修复、重构和行为变更；一次性原型、生成代码、配置文件为例外，需与人类伙伴确认。
核心能力：确立“铁律”——没有先失败的测试就不写生产代码。流程为红-绿-重构。RED：写一个只验证单一行为、名称清晰、使用真实代码（非必要不用 mock）的最小测试。验证 RED：必须运行 npm test path/to/test.test.ts，确认测试确实失败、失败信息符合预期、因功能缺失而非拼写错误而失败。GREEN：写刚好让测试通过的最简代码，不添加额外功能或重构。验证 GREEN：必须运行 npm test，确认该测试通过、其他测试仍通过、输出干净。REFACTOR：仅在绿色后消除重复、改进命名、抽取辅助函数，保持测试绿色，不新增行为，然后重复下一轮。
关键理由：代码写后才补的测试会立即通过，证明不了任何事，可能测错对象、测实现而非行为、遗漏边界情况。手工测试是临时的，无记录、无法在代码变更时复跑。
使用方式：按上述步骤循环；若无法测试，先写期望的 API 与断言或请教人类伙伴。缺陷修复时先写复现该缺陷的失败测试，再修复。常见反模式包括：测试 mock 行为而非真实行为、为生产类添加仅供测试的方法、不理解依赖就 mock，可参考 testing-anti-patterns.md。
限制与红线：测试立即通过、无法解释为何失败、先写代码后补测试、以“就这一次”“手动测过了”“删掉太浪费”等理由跳过 TDD，均属违规，应删除代码从头开始。完成前须逐项核对清单：每个新函数有测试、亲眼看过每个测试先失败、失败原因符合预期、写的是最小代码、所有测试通过、输出干净、使用真实代码、覆盖边界与错误。
关于价格、平台或收费信息，资料暂未提供。