debug-workflowlisted

# debug-workflow Triage first, then the smallest process that fits the bug. Every path ends with a regression test — a bug fix that leaves no test behind is not done (repos scaffolded by `bigin-harness-setup` enforce this at commit time via `bugfix-test-guard.mjs`). ## When this applies vs task-workflow `task-workflow` owns any bug fix tracked through `PLAN.md`; its Implement step points here for the actual debugging work. Use `debug-workflow` directly, standalone, when the failure isn't yet tied to a ticket/PLAN.md: a flaky test, a stack trace, "works in staging not prod," a live incident. Not this skill: new feature implementation or a tracked bug fix already going through `PLAN.md` (→ `task-workflow`), and authoring new tests (→ `write-tests`). ## Triage Take the **full workflow** if at least one of these holds: - flaky / timing / race symptom — intermittent, order-dependent, "passes locally, fails in CI" - works in one environment but not another (staging vs prod, CI vs local) - live production incident - a fix attempt for this bug has already failed - root cause still unclear after reading the files the stack trace / symptom implicates Otherwise take the **fast path**. Don't run the full workflow "to be safe" — uniform ceremony on obvious bugs adds nothing; the full workflow's value is concentrated in the cases above. ## Fast path 1. Reproduce the failure (failing test, request, script). 2. Fix it. 3. Show the previously-failing repro now passing, plus a check