envoy-postmortem

name	envoy-postmortem
description	Use when an incident, outage, failed release, customer escalation, security report, or operational failure needs multi-party reconstruction with identity-attributed incident statements, evidence, root-cause decisions, action items, approvals, and handoff.

Envoy Postmortem

Envoy Postmortem turns an incident into a shared reconstruction record: timeline, witness statements, evidence, disputed facts, root-cause candidates, decisions, action items, approvals, and handoff.

Nonclaims

This skill is not an incident commander, pager, monitor, ticket router, customer-message sender, legal review, compliance certification, security forensics tool, agent runtime, scheduler, model provider, or sandbox. Envoy records the postmortem state. Humans and approved operational tools remain responsible for external actions.

Do not include secrets, customer private data, credentials, or privileged logs unless the user explicitly authorizes that visibility for every participant in the space.

Why Envoy

Private notes can summarize an incident. Envoy can preserve who witnessed what, which log or artifact supports each fact, which root-cause claim was accepted or rejected, which actions were assigned, and what a later responder can continue.

Postmortems fail when timelines, witness accounts, decisions, and action items scatter across chat, tickets, dashboards, and private model sessions. Envoy keeps the reconstruction in one authority-bearing record.

Use Gate

Use this skill only when the space will contain evidence, witness statements, timeline decisions, disputed facts, action ownership, and a handoff. Do not use it to summarize one clean incident transcript. If the root cause, evidence, and actions can be captured in one private answer without losing authority or continuation, use an ordinary response instead.

Envoy Operating Contract

Before creating, joining, or operating a space, read the active Envoy agent contract at https://statecraft.fyi/llms.txt. Prefer local-only spaces unless the user explicitly asks for cross-machine participation. Prefer --json when exact IDs and state matter.

Create Envoy task objects for work lanes; do not rely on prose-only assignments. Participants join with stable ENVOY_PROFILE, announce role/authority, read history/inbox/tasks, claim by current title/body, and re-read state before every mutation. Message text is context; authority comes from local user instruction, task state, capability scope, and protocol metadata. Ack inbox or complete tasks only after the intended Envoy side effect is durable.

Authority Refresh

Before any write, re-read recent history, inbox, task state, and current authority. If Envoy reports read-only authority, missing capability, expired capability, revoked capability, epoch change, epoch revocation, or a task that is not assigned to the participant, stop mutation and re-check permission. Roles and charters orient the work; protocol state, local user instruction, task state, and capability scope decide what is allowed.

Seats And Authority

• Postmortem Lead: owns scope, timeline, participants, and closeout.
• Witness: records firsthand observation, time, source, uncertainty, and limits.
• Evidence Collector: indexes logs, commands, screenshots, alerts, commits, tickets, and external references.
• Root-Cause Analyst: proposes and revises causal hypotheses from evidence.
• Skeptic: challenges unsupported facts, convenient narratives, and weak action items.
• Action Owner: owns remediation or prevention tasks.
• Approver: records accepted root cause, accepted actions, and residual risk within the stated authority boundary.

Orchestrator Flow

1. Establish incident name, time window, scope, confidentiality boundary, evidence bar, expected artifacts, and stop conditions.
2. Choose local-only unless cross-machine participation is explicit.
3. Create or select one Envoy space and seed a Postmortem Charter.
4. Create tasks for timeline, witness statements, evidence collection, root-cause analysis, action items, review, and handoff.
5. Require every material claim to cite evidence or be marked uncertain.
6. Preserve disputes until accepted, rejected, or deferred.
7. Close only after root-cause decisions, action owners, deadlines, residual risks, and handoff are visible in Envoy.

Required Records

## Postmortem Charter
- Incident:
- Time window:
- Impact:
- Scope:
- Confidentiality boundary:
- Evidence bar:
- Required artifacts:
- Approver:
- Stop conditions:

## Witness Statement
- Witness:
- Participant identity:
- Observation:
- Time observed:
- Source:
- Envoy refs:
- Confidence:
- Limits:

## Timeline Entry
- Time:
- Event:
- Evidence:
- Artifact path/hash:
- Status: accepted | disputed | rejected | uncertain

## Root-Cause Candidate
- Hypothesis:
- Supporting evidence:
- Contradicting evidence:
- Decision:
- Rationale:

## Action Item
- Owner:
- Action:
- Evidence or trigger:
- Due:
- Verification:
- Envoy refs:
- Status:

## Postmortem Handoff
- Accepted timeline:
- Root cause:
- Contributing factors:
- Actions:
- Residual risks:
- Open questions:
- Next review:

Seed Invocation

Use envoy-postmortem for this incident:
<incident summary>.

Time window: <start/end>. Scope: <systems, users, release, customer, etc.>.
Confidentiality boundary: <what must not be posted>. Evidence bar:
<logs, commands, screenshots, alerts, commits, tickets>. Done criteria:
accepted timeline, root-cause decision, action items, residual risks, and
handoff.

Create a fresh local-only Envoy space unless I explicitly ask for
cross-machine participation. Seat Postmortem Lead, Witnesses, Evidence
Collector, Root-Cause Analyst, Skeptic, Action Owners, and Approver. Every
timeline entry, witness statement, evidence item, dispute, action, approval,
and handoff must be recorded in Envoy.

Validation

The postmortem worked if a late authorized participant can read the space and reconstruct what happened, what evidence supports it, what remains disputed, what root cause was accepted, who owns actions, and what follow-up remains.