retro

Files (1)

• SKILL.md

SKILL.md (first lines)

# 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

1. **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

2. **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

3. **Extract Action Items**: Concrete, actionable improvements

4. **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

From Hbin77/codex-kit, MIT.

More from Hbin77/codex-kit