用途：当任务最难的部分是决定 TDD 从哪里开始时使用本技能。核心原则是：从能证明行为、且所需无关准备最少的最高价值边界开始。
主要能力：按变更类型给出首个规格建议。API 契约、参数、状态码、JSON 结构用 request spec（spec/requests/）；记录或值对象上的领域规则用 model spec（spec/models/）；跨协作者的多步编排用 service spec（spec/services/）；入队、执行、重试、丢弃行为用 job spec（spec/jobs/）；关键 Turbo/Stimulus 或浏览器可见流程用 system spec（spec/system/），仅在浏览器交互是真正风险时使用；引擎路由、生成器、宿主集成用 engine spec（spec/requests/ 或引擎路径），普通应用规格会漏掉引擎接线；Bug 修复用复现规格，在观察到 Bug 的位置编写；层间不确定时优先更高边界。
使用方式：先命名要证明的行为或不变式，再定位行为首次被观察到的边界，选择最小但有力的切片，按 Rails 惯例给出可能路径，只写一个最小失败示例，运行并确认失败原因是行为缺失而非环境损坏，然后交接给 rspec-best-practices、rspec-service-testing、rails-engine-testing 或对应实现技能。写并运行首个失败规格后，暂停并展示测试设计评审，确认行为、边界、边界用例与失败原因后再实现。
限制与注意：不要仅因方便选择首个规格；真正风险在请求、任务、引擎或持久化接线时，不要从更低层单元开始；不要一次写三种规格再运行；不要默认所有场景都用 request spec 或 model spec；不要过早跳到 system spec；首个规格若需要过多工厂准备，说明边界选错。