| name | postmortem |
| description | Capture what happened, what worked, what failed, and what should change after a sprint, milestone, incident, or release. Use after meaningful outcomes. |
Postmortem
When to use
Capture what happened, what worked, what failed, and what should change after a sprint, milestone, incident, or release. Use after meaningful outcomes.
Inputs to gather
- event/milestone
- outcome
- data/feedback
- team observations
Recommended roles
producer
technical_director
community_manager
Primary docs / outputs
studio/docs/templates/postmortem.md
studio/docs/active/decision-log.md
Workflow
- Inspect the current repo/docs state first and cite concrete evidence.
- Choose the smallest useful output that moves the project forward.
- Make the highest-risk issue, blocker, or readiness gap unambiguous.
- Update or create durable docs when the result should persist.
- Recommend the next best role or skill if more work remains.
Category rules
- Prioritize severe player-facing, security, certification, and release risks over cosmetic issues.
- Make evidence, repro, and owner/action clarity explicit.
- Return a clear go/no-go or priority recommendation when the task is evaluative.
Deliverables
- postmortem doc
- root causes
- process changes
- follow-up owners
Validation bar
- severity or readiness clearly stated
- evidence or repro captured
- owner/next action explicit