Incident Command

Technical incidents usually result in two things: a frantic fix and a fragmented record. This skill ensures the record survives the chaos so that future teams can reconstruct exactly what happened, what customers were told, and what changed without asking anyone. It enforces a rigorous documentation standard that turns Slack threads and fuzzy memories into a structured repository of timelines, comms, and postmortems.

What it does

• Standardizes incident structure by initializing a dedicated folder for every event containing timelines, postmortems, and action items.
• Captures live evidence using source-tagged logging (alert, human, deploy, chat) to prevent retrospective bias.
• Generates status communications based on severity ladders, providing ready-to-send templates for first notice, updates, and resolution.
• Drives blameless postmortems through a structured root-cause ladder and quantified impact analysis.
• Tracks action items by enforcing single-owner accountability and hard due dates for every follow-up task.
• Surfaces recurring failures by searching past incident signatures to identify if a fix from months ago has failed.

How it works

1. Initialize the incident folder using incident-kit.sh new <slug> the moment an alert fires or degradation is noticed.
2. Log events in real-time with incident-kit.sh log "..." --source <type> to build a timestamped, source-tagged timeline.
3. Draft comms using the severity-based templates in references/comms-templates.md to update stakeholders on a fixed cadence.
4. Conduct postmortem within three days by filling out the template, focusing on system properties rather than human error.
5. Manage follow-ups by auditing actions --open until every item is marked as done or explicitly dropped.

Frameworks & tools

The skill uses a Bash-based CLI (incident-kit.sh) to manage a flat-file Markdown architecture. It is designed for developers working in environments where Git-based documentation is the source of truth for engineering operations.

Why this beats prompting it yourself

Standard prompting often produces generic "lessons learned" summaries that lack technical teeth. This skill enforces specific constraints: it prevents you from guessing causes in comms, rejects ownerless action items, and forces source-tagging to identify gaps in your observability.

Use cases

• Managing production outages to keep a live, timestamped log of mitigations and decisions.
• Writing technical postmortems that actually identify root causes instead of blaming the on-call engineer.
• Audit-ready record keeping for security events or data loss incidents where a paper trail is mandatory.
• Closing engineering loops by tracking long-term prevent-type action items that usually get forgotten in Jira.

Known limitations

This is a documentation and process framework, not an automated monitoring or observability tool. It requires manual input or CLI triggers to capture human decisions and chat context.