A bug that resists.
Run /diagnosing-bugs. Not /investigate.
Three debuggers installed. Two lose here. This is the order.
- 01/diagnosing-bugs Matt Pocock engineering suitea red test
Refuses to theorise until a command goes red on this exact bug. That refusal is the whole point once the first look has already failed.
- 02/freeze gstacka scoped blast radius
Locks edits to one directory for the session, so a targeted fix cannot quietly widen into a refactor while your attention is on the bug.
- 03/tdd Matt Pocock engineering suitea regression test
The red test comes before the ticket, never after. A guard rail disabled in silence only stays fixed if a test fails on today's code.
- 04/code-review Matt Pocock engineering suite
Standards and spec, checked as two separate questions. Runs per ticket, not per branch, so the answer stays small enough to act on.
- 05/ship gstacka pull request
Stops at the pull request, which is the right place to stop when the fix touches something you had to fight to understand.
- 06/learn standalone
A bug that resisted once will resist again in a neighbouring file. Write down what the first look missed, while you still remember it.
Swap in
/land-and-deploy instead of /ship — When the fix has to reach production in one move, this does merge, deploy and verify without a second session.
What you do not run
/investigate — The default debugger, and the right one nine times out of ten. Not here — it is built to move fast on a fresh lead, and this bug already survived that. the full argument
/superpowers:systematic-debugging — Same job, different dialect. Only worth it if the session is already running the superpowers method; mixing two disciplines on one diff buys nothing. the full argument
/qa — Finds bugs, does not diagnose them. You already have the bug.
If a report already gives you the file, the line and the mechanism, the diagnosis is done. Skip straight to the red test.