Retro facilitation

A retro is worth the hour only if something changes afterward. Most retros produce a long list of feelings and no owners. This one ends with two or three changes someone has agreed to make.

Before you start

If .agents/product-ops-context.md exists (or .claude/product-ops-context.md), read it first. Use the team, owners, tools, meetings, and metric definitions it already has, and only ask for what's missing or specific to this task. If it doesn't exist, go ahead with what you're given, and suggest running product-ops-context once so the next skill doesn't have to ask.

Step 1: Set it up

Confirm:

• What we're looking back on: the project, launch, sprint, or incident, with dates
• Who's in the room: everyone who did the work; leaders only if they won't stifle honesty
• The goal: usually "decide what to keep doing and what to change next time"

Send a pre-read with the timeline of what happened (key dates, decisions, and outcomes), so the session doesn't spend 20 minutes reconstructing it.

Step 2: Run the session (60 minutes)

0:00  Set the tone (2 min)
      "We're here to improve how we work, not to find who's at fault."
0:02  Timeline check (8 min)
      Walk the pre-read. Fill in what's missing.
0:10  Silent writing (10 min)
      Everyone writes on their own:
      - What went well that we should keep
      - What got in the way
      - What surprised us
0:20  Share and group (15 min)
      Read out, cluster similar notes, name each cluster.
0:35  Pick what matters (10 min)
      Everyone votes for the 2 or 3 clusters most worth fixing.
0:45  Decide changes (13 min)
      For each top cluster: what will we do differently, who owns it, by when.
0:58  Close (2 min)
      Read back the changes and owners.

For incidents, replace "What surprised us" with "Where did we first see a sign, and what stopped us from acting on it?"

Step 3: Write it up

If notes come in raw, group them into clusters before writing. Keep people's exact words for the notes; don't soften them.

# Retro: [What] — [Date]
**Attendees:** [names]

## Keep doing
- [Cluster] — [one line]

## Changes we're making
| Change | Owner | By when | How we'll know it worked |

## Also came up (not acting on now)
- [Cluster] — [why parked]

## Timeline
[Short version from the pre-read]

Rules:

• Two or three changes, maximum. Ten changes means none happen.
• Every change is a specific behavior or process, not a value ("communicate better" is not a change; "post launch status in the launch channel every Monday" is).
• No names attached to problems. Name owners only on changes.
• At the next retro, start by checking whether last time's changes happened.

Related skills

• meeting-to-action-converter — turn retro notes into owned changes
• process-documentation — write the change into the process
• decision-log — look back at what was decided