Incident Commander Brief

Build the takeover package for a live major incident changing hands: state, not story.
Build it from the master incident ticket's timeline and linked workstreams, and be honest
about what's unknown.

1. Load the master incident ticket and every linked workstream/child ticket:
   full notes in time order, status transitions, role assignments from
   the declaration.

2. Build the brief in this FIXED order — an incoming IC should be able to stop reading
   after any section and still be net better off:
   - Situation, 3 lines: what's broken, who's affected (clients/users/sites), current
     severity trend (improving / stable / degrading) with the evidence for that trend.
   - Next decision point — up top, not buried: the decision the IC faces soonest, when
     it's due, and the options as currently understood (e.g. "vendor ETA expires 14:00 —
     extend the workaround or start failover; failover takes 2h and is one-way until
     tonight").
   - Timeline — compressed to inflection points: detection, declaration, each mitigation
     attempted and its result, cause hypotheses raised and eliminated. Timestamps from
     ticket records; anything reconstructed is marked "approx." Not every note — the
     turns.
   - Workstreams — per stream: owner, current action, last update time, blocked/unblocked.
     A stream with no update in over an hour is flagged "stale — verify before relying on
     this."
   - Comms state — last internal update sent (when, gist), last client update sent (when,
     gist), next update due per the cadence, and any commitment already made to a client
     (a promised ETA is a decision constraint the new IC inherits).
   - Resources — who's engaged and for how long (fatigue is operational data), which
     vendor cases are open with case numbers from the ticket, who's on deck.
   - Known unknowns — what has NOT been established yet, stated plainly. The brief's
     credibility rests on this section.

3. Deliver in chat to the incoming IC; post the brief as a plain-text note on the master
   ticket marked "IC handover brief — <from> to <to>, <time>" so the
   handover itself is on the timeline.

4. If the ticket record is too thin to build a trustworthy brief (gaps over an hour during
   active response), say so explicitly and list the gaps — the outgoing IC fills them
   verbally and the brief records that they were filled verbally.

Guardrails: state only what the ticket evidence supports; label hypothesis as hypothesis
— a wrong "confirmed" in an IC brief steers the whole response wrong. The brief never
makes the pending decision — it frames it; the IC decides. Include commitments made to
clients verbatim where possible; paraphrasing a promised ETA is how ETAs get accidentally
re-promised. No blame framing in-flight ("the change that caused this") — causal language
stays neutral until the post-mortem settles it. If information is stale or capped, the
brief says so rather than presenting a partial picture as complete.