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 niels-emmer/myace --skill incident-managementgit clone --depth 1 https://github.com/niels-emmer/myaceWrote 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/niels-emmer/myace/incident-management)<a href="https://agentmods.dev/skills/niels-emmer/myace/incident-management"><img src="https://agentmods.dev/badge/skills/niels-emmer/myace/incident-management/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/niels-emmer/myace/incident-management"><img src="https://agentmods.dev/badge/skills/niels-emmer/myace/incident-management.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.00031 | $0.00514 |
| Opus 5.5 | $0.00012 | $0.00206 |
| Sonnet 5.5 | $0.00006 | $0.00103 |
| Haiku 4.5 | $0.00003 | $0.00051 |
Grade A, and why
Incident Management 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 1mo 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.
What it actually says
Purpose
Incidents are inevitable; chaos is optional. This skill is the structure that turns a scary production event into a sequence of calm, practiced steps — and turns the aftermath into a learning opportunity instead of a blame session.
When to use it
When an incident happens (or is suspected), when writing or updating runbooks, and when conducting a postmortem.
Steps / checklist
- Severity classification. Every incident gets a severity (SEV1 = service down / data loss, SEV2 = degraded, SEV3 = minor) so the response matches the impact. Classify early and re-classify as facts change.
- Fix forward, then fix backward. Restore service first (rollback, failover, scale-out), investigate root cause after. The goal during an incident is to stop the bleeding, not to understand it.
- Runbooks. Every known failure mode has a runbook: symptoms, quick diagnosis, immediate mitigation, and escalation path. A runbook that requires the author to be present isn't a runbook.
- Communication. Designate a coordinator. Status updates go to a single channel with a consistent format (what's happening, what's being done, when's the next update). No silent heroes.
- Blameless postmortem. After the incident, write a postmortem covering: timeline, impact, root cause, what worked, what didn't, and action items. Blameless means the goal is to fix the system, not the person.
- Action items are tracked. Every postmortem produces follow-up action items with owners and due dates. A postmortem without tracked follow-ups is a ceremony, not a process.
Expected output
An incident that a fresh on-call engineer can handle using runbooks and severity definitions alone, and a postmortem that produces tracked, owned action items. If the response depends on who happens to be on call, the incident management work isn't done.
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.
- 1mo ago First seen · 28 lines · 31 tokens per session scan A 5024ba1aa419
Incident Management is a skill published in the GitHub repository niels-emmer/myace (1 stars, last pushed 2d ago), licensed MIT. It adds 31 tokens to every session and 514 once invoked, about $0.0001 per session on Opus 5.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-09-03.
Other skills, from other repositories
corp-new
A workflow for creating a new department folder inside a local agent headquarters, with its own rules, skills, tasks, and links back to the headquarters.
manager
A session-to-GitHub tracker that creates, updates, and reads issues across repositories, including their labels, parent epics, and project-board placement.
corp-doctor
A guided maintenance and setup tool for a Personal Corp system, meaning a business workflow built from AI agents, department repositories, and shared rules. It checks what exists before making changes.
gh-issues
Use when creating, searching, updating, or managing GitHub issues via CLI. Triggers: "issue", "create issue", "gh issue", "task tracking", "context", "handoff", "resume task", "session context", "save progress", "active tasks", "in-progress", "my tasks", "open issues". Covers: gh commands, bulk operations, JSON/jq…
retro
A structured weekly retrospective for a department. It reviews tasks and evidence from an ISO calendar week, then records findings and the next planning goal.
loom-usage
Meta-orchestration skill for Claude driving loom itself.