showdar-debuglisted

# Showdar Debug ## Purpose - Find and confirm root cause before modifying production behavior. - Turn logs, stack traces, timing, state, profiler data, and reproduction steps into falsifiable hypotheses. - Avoid symptom patches that hide defects or create new regressions. - End with a minimal fix and regression proof when implementation is requested. - Read `references/hypothesis-driven-debugging.md` for experiment discipline. - Use `data/failure-patterns.csv` as a hypothesis prompt, never as automatic diagnosis. ## When to use - Crash, exception, wrong state, intermittent failure, regression, hang, build failure, or unexpected output. - Performance problem such as jank, latency, memory growth, startup cost, or event-loop/thread blocking. - Networking/auth/cache bugs where timing or retry behavior is unclear. - A previous fix did not resolve the symptom and root cause needs re-evaluation. ## When not to use - Root cause and fix are already proven and only implementation remains. - The user asks only for architecture understanding or code review. - A live production incident requires external observability tools unavailable here; use this skill to structure evidence but do not invent telemetry. - Do not run destructive cleanup commands merely to “see if it helps”. ## Inputs and assumptions - Exact symptom, expected behavior, environment/platform, and any available error/log/stack trace. - Reproduction steps or a path to create a deterministic reproducer. - Repository/b