Incident triage

Incident Triage

Use this skill when a failure is already happening and the first priority is not deep debugging, but controlled assessment.

Goal

Increase incident response success rate by answering these questions quickly:

1. what is happening
2. who or what is affected
3. how bad it is
4. whether it is growing or contained
5. what evidence is needed now
6. what the next response path should be

Core Rules

1. Stabilize the picture before diving deep

Do not jump straight into broad code changes.

First clarify:

• the visible symptom
• the user/system impact
• whether the issue is ongoing or already stopped
• whether the issue is isolated or widespread
• what changed recently

2. Distinguish severity from annoyance

A noisy bug is not always a severe incident, and a quiet bug can be severe.

Assess:

• user impact
• data impact
• availability impact
• correctness impact
• security/privacy impact
• whether work can continue with a workaround

3. Identify the blast radius

Ask:

• which feature, route, script, or workflow is affected?
• which users or inputs are affected?
• is the problem limited to one environment or all environments?
• did a recent release/config change expand the scope?

4. Gather the minimum useful evidence first

Collect only what is needed to decide the next move.

Prefer:

• exact symptom/error text
• timestamps or sequence of events
• affected path/route/command
• recent related changes
• clear reproduction if available
• whether rollback or disablement is possible

Avoid chaotic information overload before the scope is understood.

5. Choose the next path explicitly

End triage by selecting the most appropriate next action:

• monitor only
• rollback
• hotfix
• deeper root-cause tracing
• release-readiness re-check
• deployment verification
• performance debugging

Do not stop at vague concern.

6. Preserve optionality under uncertainty

When information is incomplete, prefer actions that keep future options open.

Examples:

• narrow scope before broad fixes
• contain impact before optimizing root cause
• prefer reversible actions over risky ones during uncertainty

Minis-Specific Workflow

Shell-first incident checks

Use shell commands to:

• inspect recent diffs or status
• check logs, outputs, or failing commands
• verify whether a route/script still runs
• compare current behavior with the last known good path
• inspect config/env assumptions if the incident may be environment-related

Browser-assisted triage

For web incidents:

• confirm whether the user-visible symptom is still happening
• identify the affected route/page/interaction
• distinguish total failure from partial degradation
• compare expected vs actual visible behavior quickly

Small-evidence bias

On Minis, triage should stay lightweight at first.

Prefer a compact picture of:

• impact
• scope
• recency
• suspected change area
• next action

Do not let triage become a full root-cause investigation unless that is the chosen next step.

Triage Sequence

Use this order:

1. Restate the incident symptom.
2. Identify impact and severity.
3. Identify likely blast radius.
4. Check whether it is ongoing, intermittent, or resolved.
5. Gather minimal evidence.
6. Identify likely recent change or trigger area.
7. Choose the next response path.
8. Summarize what is known, unknown, and next.

Common Triage Mistakes

Watch for:

• treating every bug like a full incident
• going deep into root cause before knowing impact
• collecting too much noise too early
• confusing one user report with system-wide failure
• applying risky fixes before understanding the blast radius
• ignoring rollback or containment options
• not stating what is still unknown

Integration with Other Skills

• Use root-cause-tracing after triage if the next step is deeper debugging.
• Use release-readiness if the incident suggests the change was not actually ready to ship.
• Use deployment-verification if the issue appears environment-specific.
• Use performance-debugging if the incident is slowness, lag, or overload rather than incorrectness.
• Use agent-security-guard if the incident involves secrets, production actions, or risky rollback/hotfix steps.

Completion Checklist

Before calling triage complete, check:

• Is the symptom stated clearly?
• Is severity assessed?
• Is blast radius estimated?
• Is the issue ongoing or bounded?
• Was minimal useful evidence collected?
• Is the next response path explicit?
• Are key unknowns listed clearly?

Response Template

• Incident symptom:
• Impact/severity:
• Blast radius:
• Current status:
• Evidence gathered:
• Likely trigger area:
• Recommended next path:
• Key unknowns:

Example Triggers

• "Something is going wrong in production — triage it first."
• "Quickly assess this incident before we start debugging deeply."
• "Is this severe enough to rollback?"
• "Help me narrow the blast radius of this failure."
• "What should the next response path be for this incident?"