---
name: davekilleen/incident-review
source: https://app.decimal.ai/s/davekilleen-incident-review@2/SKILL.md
source_sha256: 49d5aee591d8
---

# Incident review

## When to use

Use this skill after or during a contained incident when people need a trustworthy
timeline, impact record, contributing-conditions analysis, and prevention follow-up.

Do not use it as a substitute for live containment, paging, emergency escalation, or
security/legal reporting. Not for attributing personal blame, filling gaps with a
plausible root cause, or reviewing an event without cited evidence.

## Inputs and source discipline

Collect an incident identifier, review scope, start and end bounds, affected systems,
and the review as-of date/time. Use a named IANA timezone when available and preserve
each source's original timestamp and timezone or offset.

Create an evidence ledger for logs, alerts, deploy records, traces, tickets, support
reports, communications, and interviews. For every event or impact claim record the
source, source date, as-of date/time, locator, timestamp precision, and freshness.
Record missing sources and access limits as unknown rather than compensating with
memory. Keep raw evidence separate from analysis.

## Method

1. Define the incident boundary and affected service or users from cited evidence.
   Do not invent severity, duration, counts, percentages, or business impact.
2. Build a timezone-aware timeline. Preserve the reported timestamp and timezone,
   add a normalized timestamp only when conversion is valid, and cite the source for
   every row. If two credible sources disagree, retain both rows and mark the point
   contradictory instead of forcing an order.
3. Separate **facts** (directly observed or cited), **hypotheses** (inferred
   explanations), **unknowns**, **stale evidence**, and **contradictions**. Test a
   hypothesis against available evidence; do not call it a cause or root cause until
   the evidence supports that wording.
4. Use a blameless method: describe system conditions, incentives, interfaces,
   safeguards, detection, response, and recovery. Name actions and controls, not
   people as the cause. Explain what was reasonable to know at the time.
5. Define prevention and detection actions with the failure mode they address, a
   proof or acceptance measure, a follow-up date only when evidenced, and an owner.
   Use `TBD` for an unassigned owner or date; never guess an owner or make a status
   claim from an unchecked task list.
6. Present recommendations and follow-up choices to the human authority. A
   recommendation is not a human decision, and prevention work is not complete until
   its proof is read back.

## Truth and uncertainty rules

Use the labels observed, inferred, unknown, stale, and contradictory on the timeline
and analysis. A fact is not a hypothesis; a hypothesis is not a confirmed cause.
When evidence is missing or timestamps cannot be reconciled, say so, preserve the
conflict, and state what would resolve it.

Never invent dates, metrics, owners, intent, money, percentages, causes, status, or
evidence. Do not turn a plausible narrative into a fact, and do not use silence in a
log as proof that an event did not happen. Make confidence proportional to cited
evidence.

## Output contract

Return a review containing:

- incident scope, as-of time, timezone, systems, and impact claims with citations;
- a timezone-aware fact timeline with original timestamps, source/date provenance,
  confidence, and contradictory rows retained;
- separate Facts, Hypotheses, Unknowns, Stale evidence, and Contradictions sections;
- a blameless account of contributing system conditions and detection/response gaps;
- prevention and detection actions with owner or `TBD`, proof measure, follow-up, and
  current status only when observed; and
- source links, confidence, unknowns, contradictions, and a recommendation clearly
  labelled as non-decision guidance.

## Safety and write boundaries

The default is read-only. Preview the exact report or task changes, obtain explicit
confirmation from the human authority, and only then write or initiate an action.
Do not page people, change production systems, close incident records, assign owners,
or send external communications from an unconfirmed recommendation. Preserve raw
incident evidence and avoid exposing sensitive details beyond the review need.

## Verification and recovery

Read back the completed review and reconcile every timeline row's timezone, ordering,
source citation, impact statement, action owner, proof measure, and status with the
source ledger. Re-check that hypotheses remain labelled and that no unsupported cause
or date entered the document.

If a read or write fails, stop, report the failure and any partial output, and retain
the raw evidence. Re-read the destination before retrying; do not overwrite a partial
review or silently drop contradictions. Recovery consists of an append-only correction
or follow-up update after human confirmation, with the failed check and new evidence
recorded.