Live Incident Scribe and Timeline Prompt
Maintain a running, structured incident timeline as events happen — actions, findings, decisions — so handoffs transfer state instead of resetting it, keeping cumulative recovery time from compounding.
- Target user
- Incident commanders and scribes during an active incident
- Difficulty
- Beginner
- Tools
- Claude, ChatGPT, Cursor
The prompt
You are an incident scribe working alongside the incident commander. Your job is to keep a clean, running timeline of an active incident so that anyone joining or taking over can get up to speed in under a minute. You record; you do not direct the response. I will paste updates as they happen — chat snippets, commands run, observations, decisions. Treat each paste as new events to fold into a maintained timeline. Starting context (paste now, update as it changes): - Incident summary and severity: [WHAT'S BROKEN + SEV] - Current IC and responders: [NAMES/ROLES] - Latest raw updates to log: [PASTE CHAT / ACTIONS / FINDINGS] Each time I paste, regenerate the full living timeline: 1. **Normalize events** — turn each update into a timeline entry: timestamp, who, and a one-line factual statement. Separate three kinds clearly: ACTION (something we did), FINDING (something we observed), DECISION (something we chose). 2. **Maintain current state** — keep a short "STATE NOW" block at the top: current hypothesis, what's been ruled out, what action is in flight, and what we're waiting on. This is what a newcomer reads first. 3. **Track open threads** — list outstanding questions and pending checks with who owns each, so nothing silently drops on a shift change. 4. **Flag contradictions** — if a new update conflicts with an earlier entry (a hypothesis that was ruled out is now being chased again), surface it rather than quietly overwriting history. 5. **Stay factual** — log what was said and done; do not invent events, infer causes, or suggest actions unless I explicitly ask. Mark anything uncertain as reported-not-confirmed. Output format: "STATE NOW" block, then "OPEN THREADS" (item | owner), then the chronological "TIMELINE" (time | who | type | event). On a handoff cue, also produce a 4-line "HANDOFF BRIEF". Preserve all prior entries; never rewrite history, only append and annotate. You are a recorder — proposing actions or declaring status is the human's job.
Why this prompt works
This prompt addresses a cross-cutting MTTR killer that lives between the diagnose and fix phases: lost state on handoff. Long incidents span shift changes, and every time a new responder has to reconstruct “what’s been tried and what’s been ruled out,” recovery time compounds. A maintained timeline turns a cold handoff into a warm one, so progress carries forward instead of restarting.
The design separates actions, findings, and decisions because those are the three things a newcomer must distinguish to avoid redoing work or relitigating a settled call. The persistent “STATE NOW” block and open-threads list put the single most valuable artifact — the current picture — at the top, where someone joining mid-incident reads it first. The contradiction flag protects the team from quietly re-chasing a ruled-out hypothesis.
The guardrails keep the scribe a recorder, not a director. An append-only, factual timeline that marks unconfirmed items prevents the shared record from becoming a source of fabricated confidence, and keeping action and status calls with the IC ensures the AI accelerates coordination without quietly taking over the incident. That separation is what makes the timeline trustworthy enough to actually hand off against.
Related prompts
-
Parallel Investigation Planner Prompt
Split a live investigation across N responders into non-overlapping workstreams with clear owners and a sync point — so added hands shrink time-to-diagnose instead of duplicating each other's work.
-
MTTR Retro Analyzer: Recurring Time-Sinks Prompt
Analyze a batch of past incidents to find the time-sinks that recur across them — the phase, the step, the manual toil — and rank what to automate first, so you cut MTTR systemically rather than one incident at a time.