diagnoselisted

# Diagnose ## When to use - `/diagnose` - User says "diagnose this" or "debug this". - User reports a bug, error, or unexpected behavior. - Tests are failing and the root cause is not obvious. - Something is broken, throwing, or producing wrong output. - User describes a performance regression. - User shares a Grafana/Loki dashboard or explore link, or asks to "search Loki"/"check Grafana"/"search the logs", as part of root-causing a bug they've already described. - Not for a standalone log search or a bare Grafana/Loki link with no bug-report framing, see the `search-grafana-logs` skill for that. A discipline for hard bugs. Skip phases only when explicitly justified. ## Phase 1: Build a feedback loop This is the skill. Everything else is mechanical. If you have a fast, deterministic, agent-runnable pass/fail signal for the bug, you will find the cause. Without one, no amount of staring at code will save you. Spend disproportionate effort here. Be aggressive. Be creative. Refuse to give up. Before building a loop, check Sentry, if the project uses it, see the `read-sentry-issue` skill. Sentry issues provide stack traces, request params, and breadcrumbs that shortcut the reproduction process. Use them to narrow the scope before constructing a loop. If the user shares a Grafana dashboard/explore link, or the project logs to Grafana, see the `search-grafana-logs` skill, query the relevant time range and search terms directly instead of guessing at reproduction steps. ##