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 camilooscargbaptista/cto-toolkit --skill incident-postmortemgit clone --depth 1 https://github.com/camilooscargbaptista/cto-toolkitWrote 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/camilooscargbaptista/cto-toolkit/incident-postmortem)<a href="https://agentmods.dev/skills/camilooscargbaptista/cto-toolkit/incident-postmortem"><img src="https://agentmods.dev/badge/skills/camilooscargbaptista/cto-toolkit/incident-postmortem.svg" alt="Measured on agentmods" 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.00134 | $0.01558 |
| Opus 5 | $0.00067 | $0.00779 |
| Sonnet 5 | $0.00027 | $0.00312 |
| Haiku 4.5 | $0.00013 | $0.00156 |
Grade A, and why
incident-postmortem 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 8d 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 — 159 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Incident Response & Postmortem
This skill helps create two key artifacts: postmortem documents (after an incident) and incident runbooks (before incidents happen). Both are critical for building a mature engineering org that learns from failures.
Postmortem Document
The goal of a postmortem is to learn, not to blame. Every production incident is an opportunity to make the system more resilient.
Template
# Incident Postmortem: [Short Title]
**Date of Incident**: [YYYY-MM-DD]
**Duration**: [Start time → End time, with timezone]
**Severity**: [P0/P1/P2/P3]
**Author**: [Name]
**Status**: Draft | Reviewed | Action Items Complete
## Executive Summary
[3-4 sentences max. What happened, who was affected, how long it lasted,
and how it was resolved. A VP should be able to read only this and understand
the incident.]
## Impact
- **Users affected**: [Number or percentage]
- **Revenue impact**: [If measurable]
- **SLA impact**: [Did we breach any SLAs?]
- **Data impact**: [Any data loss or corruption?]
## Timeline
[Chronological sequence of events. Use UTC timestamps.]
| Time (UTC) | Event |
|------------|-------|
| 14:00 | Deploy of v2.3.1 begins |
| 14:05 | Error rate spikes to 15% in monitoring |
| 14:12 | On-call engineer paged |
| 14:15 | War room opened |
| ... | ... |
| 15:30 | Rollback deployed, error rate returns to normal |
## Root Cause
[Technical explanation of what went wrong at the deepest level.
Not "the deploy broke things" but "the migration script assumed
all users had a `preferences` column, but 12% of legacy accounts
created before 2023 didn't have this column, causing NULL reference
exceptions in the UserService.getPreferences() path."]
## Contributing Factors
[What made the incident worse or longer than it needed to be?
Examples: missing monitoring, slow detection, unclear runbooks,
missing feature flags, no canary deployment.]
## Resolution
[What was done to fix the immediate issue. Be specific about
the exact change, not just "we rolled back."]
## Detection
- **How was it detected?** [Alert? Customer report? Someone noticed?]
- **Time to detect**: [Minutes from incident start to first alert/awareness]
- **Could we have detected it sooner?** [What monitoring would have caught it faster?]
## Action Items
| Priority | Action | Owner | Due Date | Status |
|----------|--------|-------|----------|--------|
| P0 | Add NULL check in UserService.getPreferences() | @alice | 2024-01-20 | Done |
| P1 | Add monitoring for migration script failures | @bob | 2024-01-25 | In Progress |
| P2 | Create runbook for database migration rollback | @carol | 2024-02-01 | Not Started |
## Lessons Learned
- **What went well**: [Things that helped during the incident]
- **What went poorly**: [Things that made the incident worse]
- **Where we got lucky**: [Things that could have made it much worse]
## Appendix
[Relevant logs, graphs, metrics screenshots, Slack threads]
What ships with it
3 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.
- 8d ago First seen · 159 lines · 134 tokens per session scan A 9aed66babb94
incident-postmortem is a skill published in the GitHub repository camilooscargbaptista/cto-toolkit (7 stars, last pushed 5mo ago), licensed MIT. It adds 134 tokens to every session and 1,558 once invoked, about $0.0007 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.
incident-response
Incident triage, cascade prevention, and postmortem methodology. Use when handling production incidents, designing resilience patterns, or conducting chaos engineering exercises.
Incident Management
Severity classification, runbook structure, and blameless postmortems — so incidents are handled calmly, restored fast, and learned from.
incident-postmortem
Write a blameless, actionable incident postmortem from the raw facts. Use after an outage/incident, or when asked to write up "what happened" for the team.
incident-response
Stabilize, diagnose, fix, and learn from a production incident. Invoke when something is on fire, when paged, or when users report a regression.
deck-safety-alert
A slide-deck template for security warnings, risk reviews, incident retrospectives, red-team work, and policy-as-code. It uses warning stripes, alert colours, risk tiers, checklists, charts, and highlighted policy examples.