Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx skills add orlando-japan/claude-code-setting --skill incident-responsegit clone --depth 1 https://github.com/orlando-japan/claude-code-settingWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/orlando-japan/claude-code-setting/incident-response)<a href="https://agentmods.dev/skills/orlando-japan/claude-code-setting/incident-response"><img src="https://agentmods.dev/badge/skills/orlando-japan/claude-code-setting/incident-response/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/orlando-japan/claude-code-setting/incident-response"><img src="https://agentmods.dev/badge/skills/orlando-japan/claude-code-setting/incident-response.svg" alt="Reviewed on agentmods" width="80" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00036 | $0.00853 |
| Opus 5 | $0.00018 | $0.00426 |
| Sonnet 5 | $0.00007 | $0.00171 |
| Haiku 4.5 | $0.00004 | $0.00085 |
Grade A, and why
incident-response scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 9d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 63 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Incident response
Order matters: stop the bleeding first, diagnose second, fix third, learn fourth. Skipping steps costs minutes you don't have.
Phase 1 — Stabilize (minutes 0–15)
Goal: stop the damage growing. You do not need to understand why yet.
- Roll back if the incident began after a deploy. Rollback beats diagnosis in the first 15 minutes. Always.
- Disable the broken path. Feature flag off. Route traffic away. Kill the bad worker.
- Rate-limit upstream if the system is drowning.
- Announce. Post to the incident channel: what you see, what you're doing, ETA to next update.
- Appoint a single driver if more than one person joins. Confusion multiplies.
Phase 2 — Diagnose (minutes 15–60)
Once stable (even if degraded), find the cause.
- Check dashboards first. Which metric turned red, when, and how? That's your start-time and scope.
- Check logs at the transition. Not now-logs, transition-logs. What's different at the moment things broke?
- Correlate with deploys, feature flag changes, config pushes, infra events. Incidents correlate with change.
- Test the hypothesis before claiming you know. "It's the DB" means nothing without evidence.
Phase 3 — Fix (minutes 60+)
- Patch, don't rewrite. Smallest possible fix. "Add a null check" beats "refactor the auth module."
- Verify the fix locally or in staging before deploying, if you can without escalating the incident.
- Deploy carefully. Partial rollout, watch dashboards. Don't fix on deploy auto-pilot.
- Confirm recovery. The metric you measured in phase 2 should return to baseline.
Phase 4 — Learn
After the system is stable. Not the same day necessarily, but within a week.
- Timeline. When did each event happen? Use actual timestamps, not "around noon."
- What went well. Rollback worked. Alerts fired on time. Someone caught the mistake early.
- What went badly. Blind spots. Slow response. Misleading dashboards.
- Root causes. 5 Whys. Don't stop at the technical cause ("a null pointer") — go to the process cause ("our tests didn't cover this path because it's only triggered by data we never see in staging").
- Action items. Concrete, owned, with a deadline. "Improve monitoring" is not an action item. "Alert on p99 > 500ms for /api/auth by Friday, owner: @Alice" is.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 9d ago First seen · 63 lines · 36 tokens per session scan A 433c606ee95d
incident-response is a skill published in the GitHub repository orlando-japan/claude-code-setting (2 stars, last pushed 3mo ago), licensed MIT. It adds 36 tokens to every session and 853 once invoked, about $0.0002 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other skills, from other repositories
incident-response
Use to run an incident response workflow — initial triage, status updates during, blameless postmortem after. Do NOT use for ordinary debugging — use debugging-strategies for single-engineer bug-hunting.
Sev1 First 15 Minutes
Execute the initial incident workflow to stabilize, communicate, and delegate.
pager-triage
AI-powered incident triage for PagerDuty. List active incidents, deep-dive with timeline and alert correlation, check on-call schedules, acknowledge, resolve, and annotate — all from your agent. Read-only by default; write operations require explicit --confirm.
eng-runbook
A template for an engineering runbook, which is a practical guide engineers use during service operation and on-call incidents.
k8s-incident-triage
Read-only Kubernetes incident triage using kubectl. Accepts natural language or structured input. Produces root-cause hypotheses, evidence, and next-step commands.
incident-response-skill
A skill that uses object-style tool references with purpose descriptions and required flags, plus strict validation.