Getting it into your agent
This one installs as part of its plugin. Adding the marketplace and installing the plugin brings it with everything else the plugin ships.
/plugin marketplace add int2t05/engineering-skills/plugin install engineering-skillsWrote 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/int2t05/engineering-skills/incident-response)<a href="https://agentmods.dev/skills/int2t05/engineering-skills/incident-response"><img src="https://agentmods.dev/badge/skills/int2t05/engineering-skills/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/int2t05/engineering-skills/incident-response"><img src="https://agentmods.dev/badge/skills/int2t05/engineering-skills/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.00068 | $0.01462 |
| Opus 5 | $0.00034 | $0.00731 |
| Sonnet 5 | $0.00014 | $0.00292 |
| Haiku 4.5 | $0.00007 | $0.00146 |
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 — 118 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Incident Response
When production is failing, the first job is containment, not root cause. This skill structures
the live-incident workflow: classify severity, stop the bleeding, communicate, then diagnose — the
inverse of debugging, which builds a red loop first. A blameless postmortem follows every
incident so the system improves, not just the symptom.
When to use
- A production incident is live (page fired, users affected, error spike)
- An incident just resolved and needs a postmortem
- Reviewing or rehearsing incident response readiness
Not for: diagnosing a dev-time bug (use debugging); adding telemetry after the fact (use
observability); launching a new release (use shipping). This skill is for when something
already running has broken.
Steps
1. Declare and classify severity
Assign a severity within the first 5 minutes — severity drives everything downstream (who wakes up, how fast you respond, what comms are required). Use a fixed scale, not ad-hoc:
- SEV1 — user-facing outage or data loss. Page everyone. Incident commander assigned.
- SEV2 — significant degradation, partial outage. Page on-call. IC assigned.
- SEV3 — minor degradation, workaround exists. Ticket, address in business hours.
Record the declaration: start time, severity, initial symptom, who is IC. Verify: severity is written down with a timestamp, not just in someone's head.
2. Contain (stop the bleeding)
The first decision is containment vs. fix. Containment is faster and safer — rollback, disable the offending feature flag, route around the failing dependency, shed load. A fix under pressure is a second incident waiting to happen.
- Rollback to the last known-good deploy (fastest). Platform commands:
kubectl rollout undo deployment/<name>(Kubernetes),aws deploy create-deployment --revision REVISION<prev>(AWS CodeDeploy),gcloud run services update-traffic --to-revisions(Cloud Run),vercel rollback <url>(Vercel). Theshippingskill documents when to roll back (trigger conditions); these are the how commands for a live SEV1. - Disable the feature flag that triggered the issue
- Fail over to a healthy replica or region
- Rate-limit or circuit-break the failing path
What ships with it
4 files beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
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 · 118 lines · 68 tokens per session scan A d417e5c3e2ca
incident-response is a skill published in the GitHub repository int2t05/engineering-skills (3 stars, last pushed 8d ago), licensed MIT. It adds 68 tokens to every session and 1,462 once invoked, about $0.0003 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
pr-workflow
Crear pull requests completas con descripcion, labels y reviewers.
sonarqube
Levantar SonarQube con Docker, analizar el código y proponer mejoras. También: análisis estático, deuda técnica, code smells, cobertura, calidad automatizada.
brooks-sweep
Full-sweep mode: runs a unified analysis across all quality dimensions — code decay, architecture, tech debt, and test quality — then applies fixes directly to the codebase. Safe changes are auto-applied; risky changes are confirmed before execution. Drawing on twelve classic engineering books. Triggers when: user…
critical-code-reviewer
Rigorously review code or pull requests for correctness, security, accessibility, maintainability, tests, and edge cases. Use when users request a critical code review, want a guided walkthrough of findings, need implementer-facing feedback, or want to prepare, create, or submit a GitHub pull request review.
second-pass-review
Independent audit of sanitized specs in workspace/output/. Three parallel LLM-based reviewer roles check structural leakage, content contamination, and behavioral completeness. Run AFTER Layer 5 sanitization, BEFORE implementation handoff.
check-pr
Read-only inspection of a single GitHub PR lifecycle — checks CI, review threads, description sync, and mergeability, and returns PASS or FAIL with per-gate findings. Never invokes the merge button. Use when verifying a PR is ready to merge, polling lifecycle progress, checking mergeability, or babysitting a GitHub PR…