Rails Bug Triage
Use this skill when a bug report exists but the right reproduction path and fix sequence are not yet clear.
Core principle: Do not guess at fixes. Reproduce the bug, choose the right failing spec, then plan the smallest safe repair.
Process
- Capture the report: Restate the expected behavior, actual behavior, and reproduction steps.
- Bound the scope: Identify whether the issue appears in request handling, domain logic, jobs, engine integration, or an external dependency.
- Gather current evidence: Logs, error messages, edge-case inputs, recent changes, or missing guards.
- Choose the first failing spec: Pick the boundary where the bug is visible to users or operators.
- Define the smallest fix path: Name the likely files and the narrowest behavior change that should make the spec pass.
- Hand off: Continue through
rails-tdd-slices -> rspec-best-practices -> implementation skill.
Triage Output
Return findings in this shape:
- Observed behavior
- Expected behavior
- Likely boundary
- First failing spec to add
- Smallest safe fix path
- Follow-up skills
Example (wrong status code bug):
1. Observed: POST /orders returns 500 when product is out of stock
2. Expected: Returns 422 with { error: "Out of stock" }
3. Boundary: Request layer — visible in HTTP contract
4. First spec: spec/requests/orders/create_spec.rb
5. Fix path: Orders::CreateOrder should return { success: false, error: "Out of stock" }
when inventory check fails; controller renders 422
6. Next: rails-tdd-slices → write request spec → rspec-best-practices → fix
Skeleton failing spec:
# spec/requests/orders/create_spec.rb
RSpec.describe "POST /orders", type: :request do
context "when product is out of stock" do
let(:product) { create(:product, stock: 0) }
it "returns 422 with an error message" do
post orders_path, params: { order: { product_id: product.id, quantity: 1 } }, as: :json
expect(response).to have_http_status(:unprocessable_entity)
expect(response.parsed_body["error"]).to eq("Out of stock")
end
end
end
Run it before implementing the fix: bundle exec rspec spec/requests/orders/create_spec.rb
Boundary Guide
See BOUNDARY_GUIDE.md for the full bug-shape → spec-type mapping and layer diagnosis tips.
Quick reference:
| Bug shape |
Likely first spec |
| HTTP symptoms (status, JSON, redirect) |
Request spec |
| Data symptoms (wrong value, validation) |
Model or service spec |
| Timing symptoms (missing job, email) |
Job spec |
| Engine routing/generator regression |
Engine spec in dummy app |
Pitfalls
| Pitfall |
What to do |
| Unit spec when the bug is visible at request level |
Start where the failure is actually observed |
| Bundling reproduction, refactor, and new features |
Fix the bug in the smallest safe slice only |
| Flaky evidence treated as green light to patch |
Stabilize reproduction before touching code |
| The explanation relies on "probably" or "maybe" |
Ambiguity means the reproduction step isn't done yet |
Integration
| Skill |
When to chain |
| rails-tdd-slices |
To choose the strongest first failing spec for the bug |
| rspec-best-practices |
To run the TDD loop correctly after the spec is chosen |
| refactor-safely |
When the bug sits inside a risky refactor area and behavior must be preserved first |
| rails-code-review |
To review the final bug fix for regressions and missing coverage |
| rails-architecture-review |
When the bug points to a deeper boundary or orchestration problem |
Assets
1---2name: rails-bug-triage3description: Use when investigating a bug, error, or regression in a Ruby on Rails codebase. Creates a failing RSpec reproduction test, isolates the broken code path, and produces a minimal fix plan. Trigger words: debug, broken, error, regression, stack trace, failing test, RSpec, bug report, Rails app.4license: MIT5---67# Rails Bug Triage89Use this skill when a bug report exists but the right reproduction path and fix sequence are not yet clear.1011**Core principle:** Do not guess at fixes. Reproduce the bug, choose the right failing spec, then plan the smallest safe repair.1213## Process14151. **Capture the report:** Restate the expected behavior, actual behavior, and reproduction steps.162. **Bound the scope:** Identify whether the issue appears in request handling, domain logic, jobs, engine integration, or an external dependency.173. **Gather current evidence:** Logs, error messages, edge-case inputs, recent changes, or missing guards.184. **Choose the first failing spec:** Pick the boundary where the bug is visible to users or operators.195. **Define the smallest fix path:** Name the likely files and the narrowest behavior change that should make the spec pass.206. **Hand off:** Continue through `rails-tdd-slices` -> `rspec-best-practices` -> implementation skill.2122## Triage Output2324Return findings in this shape:25261. **Observed behavior**272. **Expected behavior**283. **Likely boundary**294. **First failing spec to add**305. **Smallest safe fix path**316. **Follow-up skills**3233**Example (wrong status code bug):**3435```361. Observed: POST /orders returns 500 when product is out of stock372. Expected: Returns 422 with { error: "Out of stock" }383. Boundary: Request layer — visible in HTTP contract394. First spec: spec/requests/orders/create_spec.rb405. Fix path: Orders::CreateOrder should return { success: false, error: "Out of stock" }41 when inventory check fails; controller renders 422426. Next: rails-tdd-slices → write request spec → rspec-best-practices → fix43```4445**Skeleton failing spec:**4647```ruby48# spec/requests/orders/create_spec.rb49RSpec.describe "POST /orders", type: :request do50 context "when product is out of stock" do51 let(:product) { create(:product, stock: 0) }5253 it "returns 422 with an error message" do54 post orders_path, params: { order: { product_id: product.id, quantity: 1 } }, as: :json55 expect(response).to have_http_status(:unprocessable_entity)56 expect(response.parsed_body["error"]).to eq("Out of stock")57 end58 end59end60```6162Run it before implementing the fix: `bundle exec rspec spec/requests/orders/create_spec.rb`6364## Boundary Guide6566See [BOUNDARY_GUIDE.md](./BOUNDARY_GUIDE.md) for the full bug-shape → spec-type mapping and layer diagnosis tips.6768Quick reference:6970| Bug shape | Likely first spec |71|-----------|-------------------|72| HTTP symptoms (status, JSON, redirect) | Request spec |73| Data symptoms (wrong value, validation) | Model or service spec |74| Timing symptoms (missing job, email) | Job spec |75| Engine routing/generator regression | Engine spec in dummy app |7677## Pitfalls7879| Pitfall | What to do |80|---------|------------|81| Unit spec when the bug is visible at request level | Start where the failure is actually observed |82| Bundling reproduction, refactor, and new features | Fix the bug in the smallest safe slice only |83| Flaky evidence treated as green light to patch | Stabilize reproduction before touching code |84| The explanation relies on "probably" or "maybe" | Ambiguity means the reproduction step isn't done yet |8586## Integration8788| Skill | When to chain |89|-------|---------------|90| **rails-tdd-slices** | To choose the strongest first failing spec for the bug |91| **rspec-best-practices** | To run the TDD loop correctly after the spec is chosen |92| **refactor-safely** | When the bug sits inside a risky refactor area and behavior must be preserved first |93| **rails-code-review** | To review the final bug fix for regressions and missing coverage |94| **rails-architecture-review** | When the bug points to a deeper boundary or orchestration problem |9596## Assets9798- [assets/examples.md](assets/examples.md)