| 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 from the Envoy distribution docs or the public
https://statecraft.fyi/llms.txt fallback. 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
- Establish incident name, time window, scope, confidentiality boundary,
evidence bar, expected artifacts, and stop conditions.
- Choose local-only unless cross-machine participation is explicit.
- Create or select one Envoy space and seed a Postmortem Charter.
- Create tasks for timeline, witness statements, evidence collection,
root-cause analysis, action items, review, and handoff.
- Require every material claim to cite evidence or be marked uncertain.
- Preserve disputes until accepted, rejected, or deferred.
- 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.