Quickfix
For small bugs and single-file edits. No design phase, no plan document, no refactor.
The point is not speed for its own sake. It is that a one-line fix reviewed against a written plan costs more attention than the bug did, and the extra ceremony hides the one thing that matters: whether you actually found the cause.
When to use
- Use quickfix: single-file change, obvious symptom, no API or schema change, no new tests beyond regression coverage of this bug.
- Don't use quickfix: multi-file refactor, new feature, contract or schema change, anything where you'd have to guess at intent. Those need design first — the wrong small fix in the wrong place is worse than a slow one.
Protocol
- Reproduce — describe the symptom in your own words and point at the failing path (
file:line, command, screenshot). If you cannot reproduce it, say so and stop; a fix for a bug you never saw is a guess.
- Hypothesize — state the suspected root cause with
file:line, in one sentence: "I think X is the cause because Y." Wait for the user to confirm before editing.
- Fix — the minimal change. No surrounding cleanup, no renaming, no new abstraction. Everything you touch beyond the cause is unreviewed work.
- Test — run the smallest command that covers the change (
npx vitest run path/to.spec.ts, pytest path/to_test.py::test_name). If no test covers the bug, add a regression test next to the fix.
- Report — what changed, file by file, one line of rationale each. Do not commit or push; the user commits.
Stop conditions
If the first fix doesn't work, stop. Do not try a second fix blindly — a guess stacked on a guess makes the next diagnosis harder, because now you cannot tell which change caused what you're seeing. Revert, re-diagnose with the user, and say plainly what you no longer believe.
If the cause turns out to be elsewhere, say so and stop. A bug that reproduces in one file but originates in another is not a quickfix — it needs the wider look you skipped.
If you find yourself writing a fallback — a default value, a swallowed exception, a try/except: pass to make the symptom go away — stop. That is not a fix, that is hiding the failure from the next person.
1---2name: quickfix3description: Small bugs and single-file edits without ceremony — reproduce → hypothesis → minimal fix → test. Use when the user invokes /quickfix, or when a task turns out trivial (one-file CSS tweak, typo, missing import, single-line logic fix). Never commits — the user commits.4---56# Quickfix78For small bugs and single-file edits. No design phase, no plan document, no refactor.910The point is not speed for its own sake. It is that a one-line fix reviewed against a written plan costs more attention than the bug did, and the extra ceremony hides the one thing that matters: whether you actually found the cause.1112## When to use1314- **Use quickfix**: single-file change, obvious symptom, no API or schema change, no new tests beyond regression coverage of this bug.15- **Don't use quickfix**: multi-file refactor, new feature, contract or schema change, anything where you'd have to guess at intent. Those need design first — the wrong small fix in the wrong place is worse than a slow one.1617## Protocol18191. **Reproduce** — describe the symptom in your own words and point at the failing path (`file:line`, command, screenshot). If you cannot reproduce it, say so and stop; a fix for a bug you never saw is a guess.202. **Hypothesize** — state the suspected root cause with `file:line`, in one sentence: "I think X is the cause because Y." Wait for the user to confirm before editing.213. **Fix** — the minimal change. No surrounding cleanup, no renaming, no new abstraction. Everything you touch beyond the cause is unreviewed work.224. **Test** — run the smallest command that covers the change (`npx vitest run path/to.spec.ts`, `pytest path/to_test.py::test_name`). If no test covers the bug, add a regression test next to the fix.235. **Report** — what changed, file by file, one line of rationale each. Do **not** commit or push; the user commits.2425## Stop conditions2627**If the first fix doesn't work, stop.** Do not try a second fix blindly — a guess stacked on a guess makes the next diagnosis harder, because now you cannot tell which change caused what you're seeing. Revert, re-diagnose with the user, and say plainly what you no longer believe.2829**If the cause turns out to be elsewhere,** say so and stop. A bug that reproduces in one file but originates in another is not a quickfix — it needs the wider look you skipped.3031**If you find yourself writing a fallback** — a default value, a swallowed exception, a `try/except: pass` to make the symptom go away — stop. That is not a fix, that is hiding the failure from the next person.
MegaBadCoder