← ClaudeAtlas

diagnoselisted

Root-cause debugging workflow — reproduce, isolate, root-cause, fix, verify. TRIGGER when: the user reports a bug, failure, crash, test failure, or unexpected/incorrect behavior and wants to know WHY it happens and how to fix it. TRIGGER ALSO on a bare failure report with no request attached — a pasted traceback, a failing test name, "X is broken", a screenshot of wrong output: the report IS the request. DO NOT TRIGGER when: the failure is live in production and harming users right now — use /incident first (stabilize, preserve evidence), then return here for root cause; the user wants to build a new feature (use /analyst); or wants a general code-quality / cleanup pass with no specific failure (use /code-review).
mik2win/foureyes · ★ 2 · AI & Automation · score 76
Install: claude install-skill mik2win/foureyes
# Structured Debugging Issue: $ARGUMENTS ## Principle Never guess. Reproduce first, then isolate, then root-cause, then fix the true cause, then verify. Each phase must produce evidence before moving to the next. A premature fix that masks the symptom creates new bugs. ## Phase 0 — Load profile Before debugging, load project facts so this generic workflow becomes concrete: - [ ] Read `.claude/PROJECT.md` — note **Architecture** (modules/layers/boundaries), **Commands** (test / run / logs, if present), and **Plans location** (only if the user wants the Diagnosis Report saved). - [ ] Read applicable `.claude/rules/*` for stack-specific pitfalls and conventions. - [ ] If `PROJECT.md` is missing **or still `TEMPLATE`**, fall back to the root `CLAUDE.md` (always in context) when it carries the architecture/commands above — proceed on it, noting you're running without a kit profile. Only if *neither* has those facts, STOP and tell the user to run `/bootstrap` first. Use the Architecture layers and the Commands from PROJECT.md everywhere below; do not assume hardcoded paths or commands. --- ## Phase 1 — Reproduce Confirm you can trigger the bug before touching code: - [ ] Read the error message / traceback / unexpected output carefully. - [ ] Identify the exact command, request, or code path that triggers it. - [ ] Run it using the **run/test command from PROJECT.md → Commands** to reproduce. - [ ] If intermittent: identify the conditions (sp