diagnoselisted

# Diagnose A discipline for hard bugs. Skip phases only when explicitly justified. > **Letter = spirit.** If a rule blocks you from reaching the goal it was > written for, the rule is wrong, not the goal. Don't look for a wording > loophole — ask what the rule is protecting, and protect that. ## Weaknesses and when NOT to use - **Overkill for trivial bugs.** If `grep` finds the bug in 30 seconds, just fix it. The 6-phase discipline pays off only when the bug is genuinely hard. - **Not for feature work.** If the "bug" is "we don't yet implement X", that's a missing feature, not a bug. Use `/clarify` to decompose, not `/diagnose`. - **Cannot debug what you can't reach.** If the bug only manifests in production and you have no signal source (logs, traces, repro environment), the skill stops at Phase 1 — you can't proceed without a feedback loop. - **No replacement for taste.** Phase 3 ranking depends on domain instinct. The skill structures the work; it doesn't supply the gut. ## How to do it wrong vs right ### Building a feedback loop ❌ **Wrong:** Stare at the code, guess what's wrong, edit, hope. - No signal to confirm the edit fixed anything. - "Sometimes works now" = no fix, just lucky. ✅ **Right:** Construct a fast deterministic pass/fail signal first. Failing test, curl script, CLI diff, headless browser, trace replay. Once the loop is reliable, every change is an experiment with a clear result. ### Hypothesis discipline ❌ **Wrong:** Single hypothesis ("must be t