Promptheus/commands36 commands · free · CC0Promptheus hub ↗
← All commands
/fix <issue>

Debug & fix

Fix it

The smallest correct fix — with a test, nothing extra.

fixbug
CategoryDebug & fix
Arguments<issue>
Allowed toolsReadGrepGlobEditBash
What it does

Implement the smallest correct fix for a described problem, with a test proving it, and no unrelated changes.

.claude/commands/fix.md.claude/commands/ (project) · ~/.claude/commands/ (global)
Install into your repo
npx promptheus-commands add fix

The prompt

Implement the smallest correct fix for the problem described in $ARGUMENTS: find the root cause, change only what is necessary, and prove the fix with a test.

If $ARGUMENTS is empty, ask the user for the bug report (symptom, repro steps, or a failing test/stack trace) and stop until they answer. Do not guess a bug to fix.

Method

  1. Reproduce first. Turn $ARGUMENTS into a deterministic repro: run the failing command, hit the endpoint, or write a failing test that captures the reported symptom. If you cannot reproduce, report exactly what you tried and ask for the missing detail (version, env, exact input) — do not fix blind.
  2. Locate the root cause. Trace from the symptom to the origin: read the stack trace top-down, grep for the error string, follow the data through the call chain. Fix the actual defect, not the place it surfaces. Name the file and line where the wrong behavior begins before editing.
  3. Detect conventions. Before writing code, read neighboring files, the test setup, and config (package.json, pyproject, go.mod, Makefile, CI config) to learn the language, test runner, assertion style, and lint rules in use. Match them exactly.
  4. Make the minimal change. Edit only the lines needed to correct the root cause. Preserve the existing public API, signatures, and behavior for all other inputs. Handle the obvious adjacent edge cases (null/empty, boundary, error path) only where the same bug lives.
  5. Add a proving test. Write a test that fails before your fix and passes after, asserting the corrected behavior — not the implementation. Place it beside the project's existing tests using their naming and structure. Confirm it fails on the unpatched code by reverting only the source fix while keeping the new test in place — git stash push -- <source-paths> (listing just the fixed source files, not the test), run the test to see it fail, then git stash pop to restore the fix and rerun to see it pass — so it is a real regression guard.
  6. Run the full suite. Run the project's tests, linter, and type-checker via its own scripts. All must pass. If your change broke unrelated tests, fix the cause or reconsider the approach — never delete or skip a test to go green.
  7. Self-review the diff. Read the final git diff. Remove stray debug output, commented code, and incidental reformatting. Confirm every changed line serves the fix.

Output

Report in this order:

  • Root cause — one or two sentences: what was actually wrong and where (file:line).
  • Fix — what you changed and why it is the minimal correct change.
  • Test — the test added and how you confirmed it fails without the fix.
  • Verification — the exact commands run (tests, lint, types) and their results.

Rules

  • Never fix a symptom you cannot explain the cause of. Never suppress an error to make it disappear.
  • Never bundle refactors, renames, dependency bumps, or reformatting with the fix. Propose those separately.
  • Never weaken, skip, or delete a test to make the suite pass.
  • Always leave a failing-then-passing test behind. A fix without a regression test is incomplete — say so if the codebase has no test harness and none can be added.

Add it to your toolkit

Save it as .claude/commands/fix.md or .cursor/commands/fix.md, then invoke it with /fix and your arguments.

Back to top ↑