Skip to content

Triage an incident under time pressure

Work root cause fast but not skipped, fan out hypotheses in parallel, and refuse to close on a proxy signal.

Also usessuperpowers

No werkstoff fit — this is pure Superpowers. Every werkstoff skill in the defect space is evidence-accumulating and gate-heavy by design — exactly right for a fix that must hold and exactly wrong for a page at 02:00. Force-fitting them here would be the catalog's worst advice.

Start here

One prompt to start
Production is down -- work the root cause fast but don't skip it, send several investigators at once on the likeliest independent causes in the same dispatch rather than serially, and don't let me close this out until you can show the actual cause is gone, not just that the alert stopped.

Needssuperpowers

Beats

Run these in order. Each prompt is copy-pasteable straight into Claude Code.

  1. superpowers:systematic-debuggingalso in 2 other recipes

    The pressure to skip this step is what turns one incident into three.

    Run this beat on its own
    prompt
    production is down. Work the root cause fast, but work it — no speculative reverts.
  2. superpowers:dispatching-parallel-agentsalso in 2 other recipes

    Multiple dispatch calls in one response run in parallel; under time pressure that difference is the whole game.

    Run this beat on its own
    prompt
    send three investigators at once — one on the deploy, one on the config change, one on the upstream dependency. Same message, don't serialize them.
  3. superpowers:verification-before-completionalso in 3 other recipes

    "The alert cleared" and "the cause is gone" are different claims.

    Run this beat on its own
    prompt
    before we close this out, show me the cause is actually gone — not just that the alert stopped

Worked example

Grounded in — why this beat order is trustworthy

a red `plugin-checks.yml` blocking every open pull request in this repo at once: the triage move is parallel investigators across the twelve `continue-on-error` steps, not a tribunal on any one of them.

Do / Don't

  • Work the root cause fast, but work it -- the pressure to skip this step is exactly what turns one incident into three.
  • Send multiple investigators in the same dispatch message -- that's what makes them parallel under time pressure, not sequential.
  • Show that the actual cause is gone before closing out, not just that the alert cleared.
  • Don't reach for a speculative revert instead of root-causing under pressure -- that's how one incident becomes three.
  • Don't serialize the investigation across separate dispatches when time is the constraint -- send them in one message.
  • Don't reach for werkstoff's evidence-accumulating, gate-heavy skills here -- they're right for a fix that must hold and wrong for a page at 02:00.
  • Don't close the incident on the alert clearing alone -- verify the cause is actually gone.