Menu
Use when diagnosing a bug, failing check, unexpected behavior, or production incident before changing code. Do NOT use for known mechanical edits without a failure.
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.
Use when a request leaves material product, architecture, behavior, or scope decisions unresolved. Do NOT use for approved, well-bounded implementation work.
Use when 2 or more substantial tasks are independent, have disjoint state, and parallel execution will save meaningful time. Do NOT use for coupled or sequential work.
Use when implementing an approved written plan with dependent tasks in the current session. Do NOT use when the plan is missing, unapproved, or naturally parallel.
Use when verified implementation is ready and the user must choose whether to keep, merge, or publish the branch. Do NOT use before applicable checks pass.
Use when receiving code review feedback that may be unclear or technically questionable and needs verification. Do NOT use for an unrequested general code review.
Use when a completed change is high-risk, crosses subsystem boundaries, or the user explicitly requests independent review. Do NOT use by default for low- or medium-risk changes.
Based on SOC occupation classification
| name | systematic-debugging |
| version | 6.2.0 |
| category | workflow |
| description | Use when diagnosing a bug, failing check, unexpected behavior, or production incident before changing code. Do NOT use for known mechanical edits without a failure. |
Find the failing boundary and root cause before implementing a fix. Scale the investigation and regression protection to the risk.
Read ../using-superpowers/references/risk-policy.md.
Do not propose a fix from the symptom alone.
State the suspected root cause and the evidence supporting it. Make the smallest reversible experiment that distinguishes this hypothesis from the alternatives. Change one variable at a time.
If the experiment fails, update the hypothesis instead of stacking fixes.
Do not create a test for every helper touched by the fix.
Run the original reproduction and the closest affected checks. Run the full suite only for shared core changes, a release boundary, or an explicit request.
After 3 failed fix hypotheses, stop and reassess the architecture or missing evidence with the user. Do not start a blind fourth attempt.
root-cause-tracing.mddefense-in-depth.mdcondition-based-waiting.md