tdd-identify 是一个 TDD 诊断与路由技能，用于在测试驱动开发过程中“卡住”的时刻，判断当前应该采用哪一种 Kent Beck 的 TDD 技术。它不直接编写代码或运行测试，而是通过一组有序问题把当前情境映射到对应的 tdd-* 技能上。
用途
当测试处于红灯状态却不知道如何让它变绿；当你能看到实现但不确定是直接写出来还是先伪造再泛化；当你盯着下一个测试却无法决定写哪一个；当测试碰到缓慢或外部依赖而不知如何隔离；当你刚修复一个 bug 却不确定该留下什么类型的测试时，可以使用本技能。
不适用的情况：尚未决定是否使用 TDD（属于工作流问题，应参考 tdd-red-green-refactor 或 Superpowers 的 test-driven-development）；已经明确知道该用哪种技术（直接前往对应技能）；以及伪装成 TDD 问题的领域建模问题（应路由到 ddd-design）。
主要能力与决策路径
技能按以下顺序引导判断：
-
测试是红的且不知道写什么代码：如果清楚生产代码长什么样，用 tdd-obvious-implementation 直接写；如果只知道特定输入的答案而不知道通用算法，用 tdd-fake-it 返回常量，让下一个测试迫使泛化；如果已经伪造完成需要泛化，用 tdd-triangulate 写第二个不同输入的测试。
-
要写的测试感觉太大：如果看不到如何为该测试编写生产代码，用 tdd-child-test 把大测试搁置，先写一个能完成的小测试；如果积压了多个测试不知先写哪个，用 tdd-one-step-test 选择能学到最多且能快速实现的。
-
测试触及缓慢、外部或不可靠的东西：数据库、网络、文件系统、时间等用 tdd-mock-object 使用测试替身，并确保在别处也针对真实对象测试；测试单独运行通过但一起运行失败，用 tdd-test-isolation 让每个测试拥有自己的夹具，避免共享可变状态。
-
使用不完全理解的第三方库：用 tdd-learning-test 编写针对该库的测试，以发现其行为并在升级时捕获破坏。
-
刚修复一个 bug：用 tdd-regression-test 编写本可捕获该 bug 的测试，并与修复一起提交。
-
审查测试坏味道：慢测试、不稳定测试、相互依赖的测试、mock 不属于自己的东西、测试框架而非自己的代码，可通过 tdd-anti-patterns 审查。
决策启发式
Beck 的决策树（转述）：知道要写什么就写（obvious-implementation）；不知道但知道单个案例的答案就伪造（fake-it）；两者都不行就三角化（triangulate）；仍然卡住就去洗个澡。谨慎使用 mock 对象，mock 会把测试耦合到实现，只在边界（外部服务、缓慢资源、时间）处 mock。对测试规模存疑时，总是选择 child-test，更小的测试教得更快。
反模式
把每种技术当作“毕业等级”，obvious-implementation 并不优于 fake-it，它们适用于不同时刻，资深实践者会全部使用；条件反射式地 mock 一切，mock 是最后手段而非默认；修复后跳过回归测试步骤，bug 会回来而你没有东西能捕获它。
适用场景
适合正在实践 TDD 的开发者，在红灯阶段、测试设计阶段、依赖隔离、第三方库学习、bug 修复后补测试以及测试审查等环节使用。
限制
本技能只做技术路由与决策辅助，不执行测试、不生成代码，也不替代具体的 tdd-* 技能。其内容基于 Kent Beck《Test-Driven Development By Example》（Addison-Wesley, 2002）第三部分的模式目录以及 Beck 关于 TDD 的规则文章和会议演讲。关于该技能的具体安装方式、平台支持与收费情况，资料中暂未提供。