Triage incident
Triage an active or recent software production incident by establishing impact, stabilizing the system, preserving evidence, building a timestamped timeline, coordinating hypotheses, and choosing reversible mitigations. Use when users report an outage, severe degradation, security or data-integrity event, broken deployment, elevated errors, or ask for incident command, status assessment, mitigation, or investigation support. Prioritize user harm reduction over root-cause completeness and require explicit authority for production mutations.From its SKILL.md
npx -y skills add contextosai/skills --skill triage-incidentAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
SKILL.md
3.0 KB, 477 tokens by cl100k_base, as published. Nobody here has run it
Triage an Incident
Reduce harm first, preserve the ability to learn why, and keep facts distinct from hypotheses.
Protocol
- Establish whether the event is active. Record start/detection time, affected users/regions/intents, symptom, severity signals, and current owner. Use absolute timestamps with timezone.
- Define impact in user and business terms. Separate confirmed impact from suspected blast radius and monitoring artifacts.
- Freeze unnecessary changes and preserve volatile evidence: deploy/version identifiers, flags/config, traces, logs, metrics, queue depth, resource state, and recent changes. Redact sensitive data.
- Identify the failing boundary and healthy comparison: region, tenant, version, route, dependency, data partition, or time window.
- Choose the safest reversible mitigation that reduces harm fastest: disable a feature, shed load, fail closed/open according to risk, route traffic, rollback code/config, pause writes, or degrade functionality. State expected signal, abort threshold, and recovery path before acting.
- Do not mutate production without explicit authority. When authorized, make one controlled change at a time and timestamp the observation window.
- Maintain competing hypotheses and discriminating evidence. Do not let the most senior or most recent theory become fact by repetition.
- Reassess impact after mitigation. Watch for silent corruption, backlog, retries, secondary saturation, or delayed consumers after headline metrics recover.
- Declare stabilization only when user-impact and system-health signals remain within stated bounds for an appropriate window. Hand off residual recovery, root-cause investigation, and evidence retention explicitly.
Communication discipline
- Use
references/incident-record.mdas the shared source of truth. - Publish facts, actions, owners, timestamps, and next update time. Avoid raw speculation in stakeholder updates.
- Mark decisions with rationale and the evidence expected to confirm or reverse them.
- Never expose credentials, exploit details, private user data, or sensitive internal identifiers in broad updates.
Exit conditions
End triage with current severity, confirmed impact, mitigation state, residual risk, recovery owner, next checkpoint, and whether root-cause work is separate. Do not declare resolution merely because alert volume dropped.
What ships with it: 2 files
1.4 KB alongside SKILL.md
agents/
- openai.yaml223 B
references/
- incident-record.md1.2 KB
Gives 0 of the 12 instructions most debug triage skills give in 477 tokens
Counted across 1,020 of the 1,639 authors here whose files we hold, read 2026-09-06
- Find root cause before attempting any fixin 134 of 1020, across 118 files
- Create a failing test case before implementing a fixin 109 of 1020, across 95 files
- Read error messages and stack traces completelyin 102 of 1020, across 88 files
- Reproduce the issue consistently before investigatingin 90 of 1020, across 77 files
- Make the smallest possible change to test a hypothesisin 90 of 1020, across 76 files
- Trace data flow backward to find the sourcein 84 of 1020, across 70 files
- Form a single hypothesis before testingin 78 of 1020, across 64 files
- Implement only one fix at a timein 76 of 1020, across 63 files
- Question the architecture if three fixes failin 73 of 1020, across 59 files
- Add diagnostic instrumentation at component boundariesin 68 of 1020, across 56 files
- Compare broken code against working examplesin 68 of 1020, across 57 files
- Write a regression test before applying the fixin 62 of 1020, across 55 files
Said here and by no other author read
- Reduce user harm first
- Record start and detection times
- Define impact in user terms
- Freeze unnecessary changes
- Choose reversible mitigations
- Reassess impact after mitigation
Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.