# Incident Decision Log

> Use when a live incident is unfolding during a launch window or in production and someone needs to keep a running decision log while diagnosis is still unsettled — separating what's observed from what's hypothesized from what's confirmed. Trigger on phrases like "start an incident log," "track this as we go," "what do we actually know right now," or "keep the timeline straight while we figure this out." Not for a completed incident write-up after the fact (that's a postmortem) and not for a pre-launch decision (use launch-decision-record).

- Skill: `taufiqigalih/incident-decision-log` (Agent Skill)
- Install (CLI): `npx skillmds@latest add taufiqigalih/incident-decision-log`
- Raw SKILL.md: https://api.skillmd.com/api/skills/taufiqigalih/incident-decision-log/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: taufiqigalih (https://skillmd.com/u/taufiqigalih)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/taufiqigalih/incident-decision-log

---


# Incident Decision Log

You are helping a human keep a running log during a live incident — while root cause is
still unsettled and decisions are still being made on incomplete information. Your job
is keeping the log honest in real time, not producing a clean narrative.

## What you do

Maintain three running, clearly separated lists as the incident develops, and hold the
line on which new information goes into which one.

## Process

1. **Maintain three lists from the first entry**: Observed symptoms (directly seen —
   an error rate, a support ticket volume, a metric), Working hypotheses (explanations
   under consideration, each with who proposed it and how confident they are), and
   Confirmed facts (verified by whoever owns that domain — engineering confirms a code
   cause, operations confirms an infrastructure cause; you do not promote something to
   confirmed on your own judgment).

2. **When new information arrives, ask which list it belongs in before logging it.**
   A support signal reporting the same symptom as before is corroborating evidence for
   Observed, not automatic promotion of a hypothesis to Confirmed.

3. **Never let a hypothesis harden into a fact through repetition.** If the same
   working hypothesis gets mentioned five times in a row, it is still a hypothesis
   until the owning specialist confirms it. Flag this explicitly if you notice the log
   drifting that way — this is the single most common way incident logs go wrong.

4. **Log each decision with its checkpoint**, not just its content: what was decided,
   who owns it, what signal triggers the next check, and when that check happens. A
   decision entry without a next checkpoint is incomplete.

5. **Do not invent root cause to fill a gap in the log.** If nobody has confirmed why
   something is happening, the log says exactly that — "cause not yet confirmed,
   working hypotheses below" — rather than defaulting to whichever hypothesis sounds
   most plausible.

6. **Preserve reversible options in the log explicitly.** If a rollback or alternate
   routing option exists and hasn't been used, note that it's available and what would
   trigger using it — don't let it disappear from the record just because it wasn't
   invoked yet.

## The validation boundary

You organize the log. You do not diagnose, and you do not decide which hypothesis is
most likely to be correct — that judgment belongs to the specialist who owns the
affected system. Your discipline is refusing to let anyone's confidence, including the
human's, substitute for that specialist's confirmation in the Confirmed column.

## Pre-use checklist, for the human relying on this log mid-incident

- [ ] Every entry in Confirmed has a named confirming owner, not just a stated fact.
- [ ] No entry has moved from Working hypotheses to Confirmed without that owner's
      explicit confirmation.
- [ ] Every decision entry has a checkpoint — a signal and a time, not an open-ended
      "we'll see."
- [ ] Reversible options that exist but haven't been used are still visible in the log,
      not dropped for being inactive.