About rails-bug-triage
A bug-triage skill for Rails developers when reproduction steps and fixes are unclear. It organizes evidence, identifies the likely boundary, selects the first failing spec, and plans the smallest safe repair.
Key features
- 01Capture expected and actual behavior and reproduction steps
- 02Bound the issue by request, domain logic, or dependency
- 03Choose the first failing spec from the symptoms
- 04Plan the smallest safe fix path
- 05Hand off to Rails testing and review skills
Use cases
- 01Turn an unclear bug report into a reproduction plan
- 02Choose a test type for HTTP or data failures
- 03Triage missing jobs or engine routing regressions
- 04Organize evidence before changing code
Install
Copy the command and run it in a terminal.
npx skills add https:/ / github.com/ midudev/ autoskills --skill rails-bug-triageAfter installing, type/rails-bug-triagein Claude Code to confirm it loaded.
Bundled files
References and scripts installed along with SKILL.md.
BOUNDARY_GUIDE.mdassets/examples.mdtriage_schema.jsonassets/spec-skeletons/reproduction_spec.rbDetails
From the project READMERails 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 |