s-retro

name	s-retro
description	Run a retrospective - what went well, what didn't, action items, and trend tracking

/s:retro - Retrospective

Run a structured retrospective over a phase, sprint, or time period. Identifies patterns across sessions, tracks recurring issues, and produces actionable improvements.

When to Use

• At the end of a phase (after all tasks in a phase are complete)
• At the end of a sprint or milestone
• When something went significantly wrong and you want to learn from it
• Periodically (weekly or bi-weekly) on active projects

Instructions

Step 1: Gather Retrospective Data

Read the following sources to build a complete picture:

1. Project state: Read .planning/STATE.md for the full history of decisions, blockers, and status changes
2. Roadmap progress: Read .planning/ROADMAP.md to see what was planned vs what was delivered
3. Phase plans: Read .planning/phases/N/PLAN.md and .planning/phases/N/SUMMARY.md for the relevant phase(s)
4. Learnings: Read all files in docs/solutions/ that were created during this period
5. Brainstorms and plans: Read recent files in docs/brainstorms/ and docs/plans/
6. Git history: Run git log --oneline --since="2 weeks ago" (adjust timeframe as appropriate)
7. Previous retros: Check docs/retros/ for past retrospectives to identify recurring themes

Step 2: Structure the Retrospective

Organize findings into these sections:

What Went Well (3-5 items)

Identify things that worked effectively:

• Processes that saved time
• Technical decisions that paid off
• Tools or patterns that improved quality
• Collaboration approaches that worked
• Things that were easier than expected

What Did Not Go Well (3-5 items)

Identify friction points and problems:

• Tasks that took longer than estimated
• Technical decisions that caused problems
• Processes that slowed things down
• Communication gaps or misunderstandings
• Things that were harder than expected

What to Try Next (Action Items)

For each item in "what didn't go well," propose a concrete action:

• Each action item must be specific and measurable
• Assign an owner if applicable (person or role)
• Set a timeframe (this sprint, next phase, etc.)
• Format: [ ] {action} - {owner} - {timeframe}

Surprises

Document unexpected findings:

• Things that worked differently than expected
• Hidden dependencies that were discovered
• Performance characteristics that were surprising
• External factors that affected the work

Step 3: Trend Analysis

If previous retrospectives exist in docs/retros/:

1. Read the last 3-5 retro files
2. Look for recurring themes in "what didn't go well":
   • If the same issue appears in 2+ retros, flag it as a systemic issue
   • Highlight it prominently with: RECURRING: {issue} (appeared in {N} retros)
3. Check if previous action items were completed:
   • Mark completed items
   • Carry forward incomplete items with a note
4. Track improvement trends:
   • Are certain categories getting better or worse over time?

Step 4: Write the Retrospective Document

Create docs/retros/ directory if it does not exist.

Write to docs/retros/YYYY-MM-DD-retro.md:

# Retrospective - {DATE}

**Period:** {phase name, sprint number, or date range}
**Participants:** {who was involved}

## What Went Well
1. {item with brief explanation}
2. {item with brief explanation}
3. {item with brief explanation}

## What Did Not Go Well
1. {item with brief explanation}
2. {item with brief explanation}
3. {item with brief explanation}

## Action Items
- [ ] {specific action} - {owner} - {timeframe}
- [ ] {specific action} - {owner} - {timeframe}
- [ ] {specific action} - {owner} - {timeframe}

## Surprises
- {unexpected finding}
- {unexpected finding}

## Trends
{Summary of recurring themes from past retros, or "First retro - no trend data yet"}

## Metrics
- Planned tasks: {N}
- Completed tasks: {N}
- Carry-over tasks: {N}
- Commits: {N}
- Solutions documented: {N}

Step 5: Update State

1. Update .planning/STATE.md:
   • Add a decision entry: | {DATE} | Retro completed | See docs/retros/{filename} |
   • If action items affect the roadmap, note them in blockers or current focus

Step 6: Present and Suggest

Output the full retrospective to the user in a readable format.

Then suggest next steps:

Retrospective saved: docs/retros/{filename}.md

Recommended next steps:
- Review the action items and assign owners
- If starting a new phase: Run `/s:plan` to incorporate learnings
- If continuing work: Run `/s:status` for current state
- Run `/s:docs` to ensure documentation reflects current state

Output Format

The retrospective should be clear, honest, and actionable. Avoid:

• Vague statements ("things could be better")
• Blame without constructive suggestions
• Action items without owners or timeframes
• Ignoring recurring issues from past retros

Integration

• /s:compound captures per-session learnings; /s:retro synthesizes across sessions
• /s:plan should reference the latest retro when planning the next phase
• /s:resume reads the most recent retro for context
• Previous retro action items should be checked at the start of each new phase