Menu
Diagnose and fix a Rails bug with root-cause discipline. No patches before root cause is identified. Use when given a failing test, stacktrace, log error, or behavioral bug report.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Switch the current session into Rails background-jobs specialist mode. Use for focused ActiveJob / async / queue / retry / idempotency work.
Switch the current session into Rails Tailwind CSS specialist mode. Use for focused utility-class / responsive / component-styling work in ERB.
Build a Rails feature with the specialist team. Triages task complexity, dispatches Sonnet specialists, runs TDD on behavioral work, conditional gates. Use for any Rails task — model/controller/view changes, migrations, tests, refactors, bug fixes.
Switch the current session into Rails controllers specialist mode. Use for focused controller / routes / request-handling work.
Switch the current session into Rails models specialist mode. Use for focused ActiveRecord / migration / association work without team coordination overhead.
Switch the current session into Rails services specialist mode. Use for service object extraction, business logic, design patterns.
| name | rails-bugfix |
| description | Diagnose and fix a Rails bug with root-cause discipline. No patches before root cause is identified. Use when given a failing test, stacktrace, log error, or behavioral bug report. |
Iron rule: no patches before root cause. If a fix isn't obvious from the error message in 30 seconds, investigate before editing.
Run the user's bug description through /prompt-refiner. Use the refined version for all subsequent steps. Do not refine again.
Locate the failing test, log, or stacktrace. If the user didn't provide one, ask for:
Do not start editing without a reproduction. A bug you can't reproduce is a bug you can't verify fixed.
Read the failure point. Then read the upstream callers. Then read the relevant test (if any). Look at recent commits in the affected area (git log -p -- <file>).
State the suspected root cause in ONE sentence. Be specific: "Y is nil because X#initialize doesn't set it when called from controller#create" — not "there's a nil somewhere."
Confirm the hypothesis with a targeted read or quick test before editing. Print the value, run the failing case in a console, add a temporary puts if necessary. Confirm the cause matches the symptom.
Smallest patch that addresses the root cause. NO surrounding cleanup, NO refactoring, NO renaming. The bugfix commit should diff-stat to ~5 lines unless the root cause genuinely requires more.
rails-tests with phase: red for this if helpful.One paragraph: what was broken, why, what changed, what test now covers it. If you discovered a related issue but didn't fix it, name it explicitly as a follow-up.
For most bugs: don't. The orchestrator can read and fix directly. Specialists add overhead unless the fix spans layers.
Spawn rails-security only if the bug had security implications (data leakage, auth bypass, injection).
Spawn rails-database only if the root cause was a query/index/migration issue.