Diagnosing Bugs

A discipline for hard bugs. Skip phases only when explicitly justified.

When exploring the codebase, read GLOSSARY.md (if it exists) to get a clear mental model of the relevant modules, and check ADRs in the area you're touching.

Redact

This skill has you show commands, outputs and captured artifacts. Redact every secret first: write <REDACTED> in its place. Build loops against env vars, so the credential stays in the environment rather than in what you show. Captured artifacts carry auth headers: quote only the lines that carry the signal.

Redact the whole tree, and treat listings as secret-bearing by default. A filter that scrubs one level of a config misses a secret nested deeper, and process listings show argv, which carries tokens passed as flags or headers. Redact values at every depth, and show process or config listings only through a filter that rewrites secret values wherever they appear.

If the redacted output is not enough to diagnose the bug, say so and ask the user.

Phase 1: Build a feedback loop

This is the skill. Everything else is mechanical. If you have a tight pass/fail signal for the bug (one that goes red on this bug), you will find the cause; bisection, hypothesis-testing, and instrumentation all just consume it. If you don't have one, no amount of staring at code will save you.

Spend disproportionate effort here.