用途：调查 Ruby 或 Rails 代码库中的 bug、错误或回归时，该技能要求先复现问题，再定位出错的代码路径，最后规划最小、安全的修复方案。技能文档设置了强制限制（HARD-GATE）：在没有一条可复现路径之前，不能猜测修复方案，必须先完成三件事：复现 bug、选择合适的失败测试边界、规划最小安全修复。
主要能力：提供一套按顺序执行的流程，并规定最终分诊结果必须包含七个命名输出：
- 捕获报告：复述实际行为、预期行为与复现步骤。
- 界定范围：判断问题出在请求处理、领域逻辑、后台 worker、集成边界还是外部依赖。
- 收集现有证据，包括日志、错误信息、边缘输入、近期改动或缺失的防护。
- 选择第一个失败测试，并给出修复前运行的确切命令。
- 定义最小安全修复路径，指出可能涉及的文件与最窄的行为改动。
- 产出一个在修复前会失败的骨架测试。
- 交接：继续进入 test-planning-process、tdd-process 和实现技能。
还有一个“Bug 形态 → 首选测试”的快速对照：HTTP/API 症状用集成/请求 spec 或控制器测试；数据/逻辑症状用单元或服务测试；时序/异步症状用后台 worker 或单元测试；集成/依赖回归用组件/集成测试。另有 BOUNDARY_GUIDE.md 提供完整映射与分层诊断建议，assets/examples.md 提供 Minitest 等价示例。
使用方式：按七个步骤依次执行，先确定失败在哪个边界被观察到，再写失败测试；文档以 POST /orders 下单失败为规范示例，给出 spec/requests/orders_spec.rb、bundle exec rspec spec/requests/orders_spec.rb 命令、预期 RED 状态、最小修复路径（Orders::CreateOrder 处理库存校验并返回 { success: false, error: "Out of stock" }）以及 RSpec 骨架测试代码。文档要求除非缺陷报告指向定价、纯模型或纯类场景，否则不要替换该示例。
适用场景：Ruby/Rails 项目中调查 bug、错误或回归；需要先建立可失败复现测试再修复的团队；需要按用户或运维可见边界选择首个失败测试的排查工作。
限制与注意事项：文档明确列出常见陷阱：请求层可见的 bug 不要用单元测试；不要把复现、重构和新功能捆绑在一起，只在最小安全范围内修 bug；不要把不稳定的证据当作可以直接打补丁的绿灯，先稳定复现；解释中出现“大概”“可能”意味着复现步骤尚未完成。语言要求：除非明确要求，输出必须为英文。该技能可链式使用 test-planning-process、tdd-process、refactor-process 和 review-process，分别用于选择最强首个失败测试、正确运行 TDD 循环、在风险重构区域先保持行为不变，以及对最终修复做回归与覆盖审查。