Run a structured retrospective or post-incident review with optional knowledge base capture. Use for running retrospectives, postmortems, or incident reviews.
Structured retrospective for projects, sprints, or incidents. Captures learnings and optionally persists them to the knowledge base.
$ARGUMENTS - Optional: --incident for post-incident template, or a topic/project namegit log --oneline -20 2>/dev/null | head -20gh pr list --state merged --limit 10 2>/dev/null | head -10cat context/knowledge/index.md 2>/dev/null | head -30git branch --show-currentIF --incident is in $ARGUMENTS, use the Incident template.
OTHERWISE, use the .
Review the recent commits and merged PRs from the context above. Summarize the scope of work that this retro covers. If the user provided a topic, focus on that.
## Retrospective: <topic or date>
### What Went Well
- <positive outcomes, wins, good patterns>
### What Did Not Go Well
- <pain points, friction, mistakes>
### Action Items
- [ ] <concrete next step with owner if applicable>
### Key Learnings
- <insights to carry forward>
## Post-Incident Review: <incident name>
### Timeline
| Time | Event |
|------|-------|
| | <what happened> |
### Impact
- **Users affected:**
- **Duration:**
- **Severity:**
### Root Cause
<what actually caused the issue>
### What Went Well
- <effective response actions>
### What Did Not Go Well
- <gaps in detection, response, or prevention>
### Action Items
- [ ] <concrete remediation with owner and deadline>
### Follow-ups
- [ ] <longer-term improvements>
Present the template pre-filled with whatever you can infer from the git context. Ask the user to fill in, correct, or expand each section. Iterate until the user is satisfied.
IF a knowledge base exists (check context above for context/knowledge/index.md):
/knowledge (bold entity names, standalone facts, date-stamp volatile info)IF no knowledge base exists, skip this step entirely. Do not suggest creating one.
Offer to:
.context/retros/<date>-<slug>.md