用途：在实现任何新功能、修复缺陷、重构或改变行为之前，先编写测试，并通过“红-绿-重构”循环驱动实现。核心原则是：没有先失败的测试，就不写生产代码；若先写了代码，就删除后重新开始。
主要能力：提供严格的 TDD 工作流与自检规则，包括：红阶段写一个行为单一且命名清晰的失败测试；必须运行测试并确认它因功能缺失而失败，而不是报错或写错；绿阶段只写能通过测试的最小代码；再次运行并确认该测试与其他测试都通过、输出干净；重构阶段仅在绿灯后进行去重、改名、抽取辅助函数，不增加行为；然后进入下一个失败测试。文档还给出反模式与常见借口，例如“稍后补测试”“已经手动测过”“保留作参考”，均要求停止并重新以 TDD 开始。
使用方式：按单个测试推进，先写断言与期望 API，再运行测试命令，例如 npm test path/to/test.test.ts，确认失败原因符合预期后写实现，再运行相同命令确认通过。测试应使用真实代码，仅在不可避免地情况下使用 mock；若测试难以编写，应简化和解耦设计。文档包含一个空邮箱校验的缺陷修复示例，并说明测试文件组织与验证清单。插件部分说明：用户使用 aix-test-driven-development 别名时调用本技能，生成产物写入 .aix/ 目录，写文件前可用 mkdir -p .aix 创建目录，默认可覆盖其中生成文件；除非明确要求，否则不要写到项目根目录。
适用场景：新功能、缺陷修复、重构、行为变更。例外情况如一次性原型、生成代码、配置文件，需向协作的人类伙伴确认。
限制：文档未提供具体测试框架、运行时或语言环境要求，相关信息暂未提供；不提供收费、价格或平台信息；所有规则不替代与人类伙伴确认例外。