Systematic debugging
Iron law
No fixes without a reproduced failure and a testable hypothesis. After three failed fix attempts, question architecture or assumptions.
When to use
- Intermittent or unclear failures
- Prior "quick fixes" did not hold
- Multiple subsystems involved (API, DB, cache, agent tools)
When not to use
- Typo or one-line obvious fix with clear error message
- User only wants a stack trace explained, not a fix
Four phases
1. Reproduce
- Capture exact steps, inputs, environment, and error output
- Minimize repro (one test, one script, one URL)
- Confirm you can trigger the failure on demand
2. Compare
- What changed recently (code, config, deps, data)?
- Find a known-good comparison (last green commit, sibling module, docs example)
- Diff behavior, not only code
3. Hypothesize
- List 2–3 plausible causes ranked by likelihood
- For each: one experiment that would confirm or rule it out
- Prefer experiments that take minutes, not hours
4. Fix with test
- Add or extend a test that fails for the current bug
- Apply minimal fix; re-run repro and test
- Run
verify-before-done before claiming fixed
Escalation
| Signal |
Action |
| 3+ failed fix attempts |
Stop; write findings; propose design/architecture review |
| Cannot reproduce |
Gather more data; do not patch blindly |
| Fix works locally only |
Check env parity, feature flags, cached state |
Anti-patterns
- Random changes until something "seems" fixed
- Fixing symptoms (broad try/catch, silent rescue) without root cause
- Skipping repro because "it's obvious"
Related
test-first-development, test-failure-triage, verify-before-done, gstack/code-quality/investigate
Workflow inspired by obra/superpowers (MIT).
1---2name: systematic-debugging3description: Four-phase root-cause debugging—reproduce, compare patterns, hypothesize, fix with tests. Use when errors are unclear, fixes failed twice, or symptoms keep returning.4---56# Systematic debugging78## Iron law910No fixes without a **reproduced** failure and a **testable hypothesis**. After three failed fix attempts, question architecture or assumptions.1112## When to use1314- Intermittent or unclear failures15- Prior "quick fixes" did not hold16- Multiple subsystems involved (API, DB, cache, agent tools)1718## When not to use1920- Typo or one-line obvious fix with clear error message21- User only wants a stack trace explained, not a fix2223## Four phases2425### 1. Reproduce2627- Capture exact steps, inputs, environment, and error output28- Minimize repro (one test, one script, one URL)29- Confirm you can trigger the failure on demand3031### 2. Compare3233- What changed recently (code, config, deps, data)?34- Find a **known-good** comparison (last green commit, sibling module, docs example)35- Diff behavior, not only code3637### 3. Hypothesize3839- List 2–3 plausible causes ranked by likelihood40- For each: one experiment that would confirm or rule it out41- Prefer experiments that take minutes, not hours4243### 4. Fix with test4445- Add or extend a test that fails for the current bug46- Apply minimal fix; re-run repro and test47- Run `verify-before-done` before claiming fixed4849## Escalation5051| Signal | Action |52|--------|--------|53| 3+ failed fix attempts | Stop; write findings; propose design/architecture review |54| Cannot reproduce | Gather more data; do not patch blindly |55| Fix works locally only | Check env parity, feature flags, cached state |5657## Anti-patterns5859- Random changes until something "seems" fixed60- Fixing symptoms (broad try/catch, silent rescue) without root cause61- Skipping repro because "it's obvious"6263## Related6465`test-first-development`, `test-failure-triage`, `verify-before-done`, `gstack/code-quality/investigate`6667*Workflow inspired by [obra/superpowers](https://github.com/obra/superpowers) (MIT).*
charlieviettq