Debug
Trace the failure before changing code. Systematic root-cause analysis:
reproduce, isolate, hypothesize, fix, verify.
Process
- Trace the failure — capture the exact error, stack trace, failing command,
and relevant logs. Done only when the failure can be quoted back verbatim.
- Reproduce reliably — identify the smallest command or action that fails.
Done only when it fails twice the same way, or is labeled intermittent with
evidence.
- Gather evidence before hypothesis — check recent changes, logs around the
failure, expected environment, config, versions, and whether timing/races are
plausible. Done only when each relevant item is recorded or ruled out.
- Isolate — binary search via
git bisect, comment blocks, feature flags,
or a minimal repro. Done only when the failure is narrowed to a component,
commit, input, or condition.
- Hypothesize — state one specific theory and the observation that would
disprove it. Do not change multiple things at once.
- Test hypothesis — add temporary logging, use a debugger, or run a focused
experiment. Done only when the result supports or rejects the theory.
- Apply minimal fix — smallest change that addresses root cause, not symptoms.
- Verify — rerun the original reproduction and relevant regression checks.
Done only when the original failure no longer occurs and regressions are not
detected or are explicitly reported.
Evidence to Gather Before Hypothesis
- Full error message, stack trace, and error code
- Recent changes:
git log --oneline -10 / git diff HEAD~1
- Logs around the time of failure
- Environment: versions, env vars, config, external service state
- Consistency: deterministic failure or intermittent pattern
Reproduction:
# Find the commit that introduced it
git bisect start
git bisect bad HEAD
git bisect good <last-known-good-sha>
Strategic logging:
// Entry/exit with parameters — temporary, remove after fix
console.log('[debug] functionName called', { param1, param2 });
// ...
console.log('[debug] functionName result', { result });
Anti-Patterns
- Don't make random changes hoping something fixes it — form a hypothesis first
- Don't fix symptoms without understanding root cause
- Don't debug in production without safeguards
- Don't leave debug logs or breakpoints in committed code
- Don't trust your mental model — read the actual code
Output
## Root Cause
[What actually caused the issue]
## Evidence
- [Log excerpt / stack trace / variable state]
## Fix
`file:line`
```diff
- broken code
+ fixed code
```
**Why this fixes it:** [reasoning]
## Verification
- [Command/repro rerun and result]
## Prevention
- [Recommendation to avoid recurrence]
1---2name: debug3description: Debugs errors, test failures, and unexpected behavior with systematic root-cause analysis. Use when the user reports a bug, says "this isn't working", a test is failing, an exception is thrown, output is wrong, or asks to investigate "why does X happen". Applies to frontend, backend, database, network, and performance issues.4---56# Debug78Trace the failure before changing code. Systematic root-cause analysis:9reproduce, isolate, hypothesize, fix, verify.1011## Process12131. **Trace the failure** — capture the exact error, stack trace, failing command,14 and relevant logs. Done only when the failure can be quoted back verbatim.152. **Reproduce reliably** — identify the smallest command or action that fails.16 Done only when it fails twice the same way, or is labeled intermittent with17 evidence.183. **Gather evidence before hypothesis** — check recent changes, logs around the19 failure, expected environment, config, versions, and whether timing/races are20 plausible. Done only when each relevant item is recorded or ruled out.214. **Isolate** — binary search via `git bisect`, comment blocks, feature flags,22 or a minimal repro. Done only when the failure is narrowed to a component,23 commit, input, or condition.245. **Hypothesize** — state one specific theory and the observation that would25 disprove it. Do not change multiple things at once.266. **Test hypothesis** — add temporary logging, use a debugger, or run a focused27 experiment. Done only when the result supports or rejects the theory.287. **Apply minimal fix** — smallest change that addresses root cause, not symptoms.298. **Verify** — rerun the original reproduction and relevant regression checks.30 Done only when the original failure no longer occurs and regressions are not31 detected or are explicitly reported.3233## Evidence to Gather Before Hypothesis3435- Full error message, stack trace, and error code36- Recent changes: `git log --oneline -10` / `git diff HEAD~1`37- Logs around the time of failure38- Environment: versions, env vars, config, external service state39- Consistency: deterministic failure or intermittent pattern4041**Reproduction:**4243```bash44# Find the commit that introduced it45git bisect start46git bisect bad HEAD47git bisect good <last-known-good-sha>48```4950**Strategic logging:**5152```typescript53// Entry/exit with parameters — temporary, remove after fix54console.log('[debug] functionName called', { param1, param2 });55// ...56console.log('[debug] functionName result', { result });57```5859## Anti-Patterns6061- Don't make random changes hoping something fixes it — form a hypothesis first62- Don't fix symptoms without understanding root cause63- Don't debug in production without safeguards64- Don't leave debug logs or breakpoints in committed code65- Don't trust your mental model — read the actual code6667## Output6869````markdown70## Root Cause71[What actually caused the issue]7273## Evidence74- [Log excerpt / stack trace / variable state]7576## Fix77`file:line`78```diff79- broken code80+ fixed code81```8283**Why this fixes it:** [reasoning]8485## Verification86- [Command/repro rerun and result]8788## Prevention89- [Recommendation to avoid recurrence]90````