| name | retro |
| description | Run a sprint/session retrospective to capture what worked, what didn't, and what to improve. |
Retrospective Skill
Run a sprint/session retrospective to capture what worked, what didn't, and what to improve.
When to Use
- After completing a major feature or task
- After a debugging session
- At the end of a development sprint
- After a production incident
Process
-
Gather Data: Review what happened in this session/sprint
- Read recent git log:
git log --oneline -20
- Check files changed:
git diff --stat HEAD~N — clamp N to the available history first so this doesn't fail on repos with fewer than N commits: N=$(( $(git rev-list --count HEAD) - 1 )); [ $N -gt 5 ] && N=5; if N is 0 (single commit), fall back to git log --oneline / git show --stat.
- Review any error logs or failed attempts
-
Classify Events: Sort into categories
What Went Well (Keep)
- Approaches that worked efficiently
- Good architectural decisions
- Tools/commands that saved time
What Didn't Go Well (Stop)
- Wasted time on wrong approaches
- Bugs introduced by oversight
- Communication gaps or unclear requirements
What To Try Next Time (Start)
- New tools or approaches to try
- Process improvements
- Better testing strategies
-
Extract Action Items: Concrete, actionable improvements
-
Identify Patterns: Look for recurring themes across retros
Output Format
## Retrospective: [date or sprint name]
### Summary
- Duration: [time spent]
- Commits: [count]
- Files changed: [count]
- Lines: +[added] / -[removed]
### 🟢 Keep (What Went Well)
- [item 1]
- [item 2]
### 🔴 Stop (What Didn't Go Well)
- [item 1] → Root cause: [why]
- [item 2] → Root cause: [why]
### 🔵 Start (Try Next Time)
- [item 1] — Expected benefit: [what it improves]
- [item 2] — Expected benefit: [what it improves]
### Action Items
- [ ] [concrete action 1]
- [ ] [concrete action 2]
### Metrics
| Metric | This Sprint | Trend |
|--------|-------------|-------|
| Bugs found in review | N | ↑↓→ |
| Build failures | N | ↑↓→ |
| Test coverage | N% | ↑↓→ |
Rules
- Be honest — the point is improvement, not blame
- Focus on process, not people
- Every "Stop" item needs a root cause
- Every "Start" item needs an expected benefit
- Action items must be specific and achievable (not "be better at X")
- If this is a recurring retro, compare with previous ones to track progress
