Root-cause a bugfix from a tracked issue

Find where a reported behavior lives, reach root cause, write a failing test, then prove the fix adversarially.

Also usessuperpowers

The spine of this task is Superpowers: root cause before fix, failing test before code. The werkstoff contribution is the search and the proof at either end.

Start here

One prompt to start

I don't know where this reported bug actually lives -- go find it first rather than working from a guessed file list, work it to root cause with no fix proposed until the cause is proven, write the failing regression test before touching the fix, and then run a blind tribunal on the result rather than trusting your own review of it.

Needszirkel, superpowers, andon

Beats

Run these in order. Each prompt is copy-pasteable straight into Claude Code.

1. zirkel:zirkel-investigate-dynamicallyalso in 1 other recipe

   • Run a read-only design study with an evidence legend

   The location is unknown; a pre-planned file list cannot adapt to what each observation reveals.

   Run this beat on its own

   I don't know where this behavior is implemented — go find it before we talk about fixing it

2. superpowers:systematic-debuggingalso in 2 other recipes

   • Diagnose a pipeline red across several jobs
   • Triage an incident under time pressure

   Mandatory before proposing fixes; a fix without a cause is a guess with a diff.

   Run this beat on its own

   work this to root cause. No fix, no patch, no workaround until the cause is proven.

3. superpowers:test-driven-developmentalso in 3 other recipes

   • Build a new feature in an existing codebase
   • Collapse duplication hand-synced across N sites
   • Refactor for maintainability

   A regression test written after the fix passes for the wrong reason.

   Run this beat on its own

   write the failing regression test for this bug first, then fix it

4. andon:andon-verifyalso in 15 other recipes

   • Audit supply-chain pinning and dependencies
   • Finish and integrate a development branch
   • Investigate a job that reports success but changed nothing
   • Investigate a fix that did not stick
   • Investigate tests that pass while the code is broken
   • Build a new feature in an existing codebase
   • Collapse duplication hand-synced across N sites
   • Execute a written plan across parallel workstreams
   • Fix an existing dashboard without breaking it
   • Migrate a return shape or type representation
   • Propagate a vendored artifact to N copies
   • Audit your own agent and skill definitions for loop-reliability defects
   • Rework a plugin to the official Anthropic standard
   • Do oracle engineering and numerical V&V
   • Whole-branch review without re-trusting the branch's own self-assessment

   Self-review is generous; the tribunal strategy dispatches defender and challenger blind to each other.

   Run this beat on its own

   run the tribunal on this fix — I want a defender, a challenger, and someone who actually runs the checks

Worked example

Grounded in — why this beat order is trustworthy

the failure mode recorded in `.github/workflows/plugin-checks.yml`: a `.gitignore` regression that silently drops a vendored file, leaving the artifact lock expecting a file that no longer exists — a bug whose symptom appears months later, at a hook denial, rather than where the cause lives.

Do / Don't

• ✓Go find where the behavior actually lives before proposing anything -- a pre-planned file list can't adapt to what each observation reveals.
• ✓Work to root cause before proposing any fix, patch, or workaround -- a fix without a cause is a guess with a diff.
• ✓Write the failing regression test before the fix -- written after, it passes for the wrong reason.
• ✓Run a tribunal with a defender and challenger blind to each other, rather than trusting self-review -- self-review is generous.

• ×Don't start from a guessed file list when the bug's location is unknown -- let each observation decide what to check next.
• ×Don't propose a fix before the root cause is proven -- a fix without a cause is a guess wearing a diff.
• ×Don't write the regression test after the fix -- it will pass for the wrong reason.
• ×Don't trust your own review of your own fix -- the tribunal exists because self-review is generous.