Diagnose Bug

Use this skill to diagnose backend and algorithmic failures from evidence inward: reproduce with concrete inputs, establish the intended invariant or contract, correlate runtime signals, then inspect code. Keep it globally usable; discover the project’s actual runtimes, test harnesses, and observability instead of assuming a stack.

This skill is for non-UI surfaces: APIs, services, CLIs, libraries, workers/queues, ETL/pipelines, compilers/analyzers, and algorithms (correctness, complexity, numeric stability). This is quality regime A (deterministic compute).

• Live browser/product UI failures → troubleshoot-app (regime B)
• Agent loops / stochastic LLM quality → agents analyze (+ Langfuse traces/evals), not this skill as the primary cut (regime C)

Use existing specs, types, contracts, property tests, unit/integration tests, DocSlime/TESTING, and docs as the definition of correct behavior (handbook/concepts/13-quality-trace.md). Prefer refining an existing definition over inventing a parallel one. If none fits, propose a concise contract or Given/When/Then scenario and say where it should live. Wrong answers, broken invariants, and silent data lies are bugs — including data/test/observability debt labels when those name the interest (handbook/concepts/12-bugs-and-debt.md).

Core Rule

Do not jump straight from stack trace to a speculative rewrite. Establish the failing input, the expected contract, and what runtime evidence shows. Treat logs and metrics as evidence, not authority.

Before making code, config, or data changes, end the diagnosis with:

Do you want me to implement this fix?