diagnosing-bugslisted

<!-- Vendored from mattpocock/skills (MIT), upstream commit 2ab9580 (2026-07-28), plugin v1.2.0, adapted for n8n-project-template. See .claude/skills/_LICENSE-mattpocock.md --> # Diagnosing Bugs A discipline for hard bugs. Skip phases only when explicitly justified. When exploring the codebase, read the affected workflow's WF-X spec (`docs/specs/WF-X.md`, if it exists) to get a clear mental model of the workflow — trigger, data flow, services, error handling — and check `docs/troubleshooting.md`: many n8n failure modes are already documented there. If the bug arrived as a `/qa-workflow` finding (a GitHub issue carrying `repro` / `expected` / `actual` / `execution_id` — see `.claude/skills/qa-workflow/`), that is your diagnosis input: `repro` seeds the feedback loop, `expected` vs `actual` is the red assertion, and `execution_id` is your replay handle. ## 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. **Be aggressive. Be creative. Refuse to give up.** ### Ways to construct one — try them in roughly this order 1. **Failing test** at whatever seam reaches the bug — for CLI or Code-node logic (`scripts/`, extracted Code-node functions), a unit or in