diagnosing-bugslisted

# Diagnosing Bugs Do not start with a theory. Start with a feedback loop that can prove the user's exact symptom exists and later prove it is gone. This workflow is adapted from Matt Pocock's MIT-licensed `diagnosing-bugs` skill; see `NOTICE`. ## 1. Build one red-capable command Choose the highest useful public seam: 1. focused existing test or new failing regression test 2. HTTP request or CLI invocation with a fixture 3. browser automation asserting DOM, console, and network behavior 4. captured request/trace replay 5. throwaway harness around the affected module 6. deterministic stress, fuzz, differential, or `git bisect run` harness The command must: - exercise the reported code path - assert the user's exact symptom, not merely “did not crash” - be deterministic, or raise a flaky reproduction rate enough to investigate - run unattended and quickly enough for repeated use Run it and record the command plus failing output. If no red-capable loop can be built, stop after documenting attempts and request the missing environment, trace, HAR/log/core dump, or permission for targeted instrumentation. ## 2. Reproduce and minimize Confirm the loop fails in the way the user reported. Remove inputs, steps, configuration, callers, and data one at a time, rerunning after each removal. Stop when every remaining element is necessary to reproduce the failure. ## 3. Rank falsifiable hypotheses Write 3–5 hypotheses. Each must predict an observable result: > If X is the cause,