When something is broken and you don’t yet know what, start with /incident. It triages, diagnoses in parallel, and routes to the right resolution skill with all the evidence attached. When you already know what kind of problem you have, go to the resolution skill directly and skip the triage.
/incident "500 errors on the checkout page"
What happens:
.claude/qa-knowledge/incidents/, and the knowledge base is updated.Other entry forms: /incident #234 loads a GitHub issue; bare /incident auto-detects by checking health, CI, and recent deploys.
| Evidence points at | Routes to | Go direct when |
|---|---|---|
| Infrastructure, performance, data | /sre debug |
You already suspect infra — bad deploy, resource exhaustion, a service down |
| CI pipeline | /ci-fix | You know CI is red — see Automate CI recovery |
| A code bug | /fix | You have a diagnosed bug or reproduction — the formal pipeline takes it from there |
| Local dev environment | /restart | Your local servers are the problem, not production |
Two things worth knowing about the routes:
/sre debug never patches code. Infra-only fixes (restart, config, scale) are applied directly and health-verified; code bugs are escalated to /fix with the evidence — that’s by design, because /fix has the verification pipeline (root cause, scope lock, regression proof)./sre finds a code bug or /ci-fix hits an architectural problem, the handoff carries the diagnosis with it.If a routed skill doesn’t resolve in ~15 minutes, the orchestrator alerts and presents options; for CRITICAL incidents unresolved in 30 minutes it suggests a revert. If triage reports missing data sources (no monitoring, no DB access), run /calibrate — it installs the recommended MCP servers so future triage gets richer evidence.
For a known issue you want recorded without running triage, use /qa-incident.