用途：为代码库建立或加固“测试笼”——由自动化测试套件与约定构成的约束，使行为被锁定、改动更安全。它关注仓库维护，而非从想法到上线的新功能流程；新功能切片应交给 tdd 在已有测试笼内完成。
主要能力与流程（七步，可勾选跟踪）：1) 现状调查：梳理命令、目录、CI任务、大致运行时间、不稳定测试、覆盖率与变异测试工具，记录缺口。2) 策略：与用户书面确认“完成”的含义，包括覆盖率目标、变异/CRAP 何时运行、当前纳入哪些测试种类、快速通道的 F.I.R.S.T. 底线。3) 通道与接缝：定义程序员/单元、验收/客户、集成/系统三类通道各自的负责人与节奏，并命名所测接缝，优先少量高价值接缝。4) 替身策略：仅在架构/系统边界允许测试替身，优先手写假件。5) 信任闸门：接入每个PR运行的快速套件、覆盖率报告，以及针对关键模块的变异或 CRAP 检查，变异体必须被杀死。6) 热点闭合：依据 CRAP、变异存活者与已知不稳定测试补特征测试，删除或隔离腐坏测试。7) 记录测试笼：在 docs/testing.md 或 CONTEXT.md 记录通道、命令、替身策略、闸门，并把闸门写入脚本或 CI 配置。
关键概念：测试笼、语义稳定性、F.I.R.S.T.（快、隔离、可重复、自校验、及时）、种类与归属、CRAP（复杂度×缺失覆盖）。
适用场景：接手或维护现有代码库、测试健康度差、CI 只跑端到端、模拟对象泛滥等。
限制与不适用：不想用于“想法→票据→功能”“单个红绿行为切片”“对话式缺陷登记”“单一顽固缺陷”等场景；若根因是缺少可测接缝，应先做架构改进再回来。资料未提供收费、价格与具体安装命令等信息。