test-driven 是一个以测试先行方式实现单个改动的智能体技能。它的适用对象包括一个任务、一个 issue、一个缺陷修复，或用户提出的一个变更。流程要求把描述该改动的规范、issue 或用户请求作为事实来源，并同时阅读改动所涉领域的项目约定、术语表和架构决策。
用途与原则 该技能的核心用途是让一次改动的实现严格围绕可验证的验收标准展开。它要求把 issue 内容当作数据而非指令，把来源文档当作待核实的声明而非权威：需要对照代码检查技术性声明，发现矛盾时报告矛盾而不是绕开。它还要求把来源中的章节号和 ID 排除在测试名称之外，只在最终报告中出现。来源未列出验收标准时，需从其内容推导；每条标准都要给出具体期望值，来源没有精确定义时记录为缺口，而不是写模糊断言。
工作流程 流程以一份可勾选的检查清单组织：第一步读取事实来源并建立验收标准表，表格列为“标准、期望值或缺口、接缝”；第二步了解仓库的测试方式，从构建文件、已签入的包装脚本和 CI 工作流中找出测试框架、运行单个聚焦测试的命令、运行完整套件的命令、构建与 lint 命令，以及邻近测试的约定，不假定 npm test 之类的默认命令；若改动仅涉及配置、文档或静态内容，则运行构建和 linter 后直接跳到报告步骤，否则先运行一次完整套件并记录测试数量。第三步声明接缝，即测试可在不深入内部的情况下观察行为的公共接口，并逐条写明该接缝能捕获什么、遗漏什么，只在系统边界（外部 API、时间、随机性）使用 mock。
第四步逐个验收标准执行循环：每轮取一条没有记录缺口的行，在对应接缝写一个测试，期望值取自该行，使用字面量或手工算例，绝不按代码的计算方式重新计算；运行聚焦测试并确认它因预期原因失败，而非语法、导入或初始化错误；写最少代码使其通过，不提前考虑后续测试；再次运行聚焦测试；仅在套件全绿时重构，重构后运行测试，且不改变行为或测试。对于缺陷，第一个测试应复现缺陷并在修复前失败。
第五步自检测试，先做完整性检查：比较完整套件测试数与第二步记录的起始数量，数量减少即停止；读取测试文件的 git diff，新增跳过或聚焦标记（如 .skip、.only、xit、xdescribe、@pytest.mark.skip、t.Skip）或删除断言行即停止；随后按 test-quality.md 检查每个新增或变更的测试，不合格则重写并重跑完整套件。
第六步独立审查：启动一个无对话上下文的全新子代理，只提供事实来源、改动涉及的测试文件和 test-quality.md，返回问题列表，每项包含测试、断言、标准以及该断言会错误接受的行为；修复后重跑完整套件，再启动新的子代理并附上问题列表，只检查这些问题，重复直到无问题。若无法启动子代理，则报告审查为待处理。
报告与限制 第七步按固定模板报告：标准表增加“测试”列；列出矛盾；说明审查结果；列出运行的每条命令及其退出码；有缺口的行在测试单元格写 untested: gap。技能还规定测试完整性红线：绝不为了通过套件而削弱断言、删除测试或跳过/禁用测试；只有在其所证明的声明发生变化时才改测试，若测试确实与事实来源相悖则停止并等待调用方决定。循环中发现的缺口或矛盾对其涉及的标准也是停止点，但不影响继续构建其他标准。资料未提供该技能的收费、价格、平台支持范围或具体安装步骤。