Retrospectives skill for Claude Code
Three owned actions, checked at the next retro. Claude plans retros that open by reviewing the last retro's actions, show sprint data before anyone shares opinions, and use silent writing and dot voting so the loudest voice does not set the agenda. Discussion digs to causes the team controls, and the meeting ends with no more than three actions, each with an owner, a date and a measurable signal of success.
- name
retrospectives - size166 lines · ≈1,800 tokens
- files1
- licenseMIT
- updated
What Claude sees before loading it
This description is the only part of the skill that sits in context all the time. Claude reads it to decide when to load the full playbook below.
description: Designs and runs team retrospectives that change something — the five-stage structure, a format chosen for the team's current situation, data gathered before opinions, psychological safety practices, dot voting and root-cause techniques, and at most one to three owned, dated, observable action items reviewed at the start of the next retro. Use when planning or facilitating a sprint, project, or release retrospective, when retros feel repetitive or nothing changes, when choosing a retro format, running a remote retro, or writing up retro outcomes.Try asking
- Plan a 60-minute retro for a sprint where we missed the goal and carried over half the work
- Our retros keep producing the same complaints; redesign how we run them
- Turn these retro sticky notes into themes and three concrete action items
Use it when
- Planning or facilitating a sprint or project retrospective
- Retros feel repetitive and nothing changes afterwards
- Choosing a format for a team under tension or after a hard sprint
- Writing up retro outcomes and actions
Skip it when
- You are reviewing a production incident, use postmortems instead
- You need a general meeting agenda or decision process, use meeting-facilitation instead
How to check the result
The write-up shows last retro's actions reviewed, sprint data presented, and no more than three actions each with an owner, due date and baseline-to-target signal.
The common mistake it prevents
Ending with a long list of vague improvements nobody owns, then never checking them, which teaches the team that retros change nothing.
A retrospective is done well when the team leaves with one to three small changes it believes in, each with an owner and a date, and the next retro opens by checking whether those changes happened and helped. A retro that produces a long list of complaints and no follow-through teaches the team that retros are pointless.
Ground rules
- Review last retro’s actions first, every time. Unfinished actions are discussed before new topics.
- Gather data before opinions: what happened (timeline, metrics) before how people felt about it.
- Max 3 actions. One done action beats ten written ones.
- Actions are within the team’s control, specific, and observable. “Communicate better” is not an action.
- Safety first: no managers evaluating individuals, no blame, what is said stays in the room unless the team agrees to share it.
- Rotate the facilitator, and change the format when energy drops; the same three columns for 20 sprints produce the same answers.
Timebox
| Scope | Duration |
|---|---|
| 1-week sprint | 45 min |
| 2-week sprint | 60–90 min |
| Project or release (1–3 months) | 2 h |
| Large program or incident-heavy period | Half day, with pre-work |
The five stages
- [ ] 1. Set the stage (5–10%): purpose, timebox, working agreement, quick check-in
- [ ] 2. Gather data (25–30%): facts and feelings, silently first
- [ ] 3. Generate insights (25–30%): cluster, vote, dig into causes
- [ ] 4. Decide what to do (20%): 1–3 actions with owner, date, success signal
- [ ] 5. Close (5–10%): recap actions, quick retro-of-the-retro1. Set the stage
- Read the prime directive or the team’s own working agreement: everyone did the best job they could with what they knew at the time.
- Check-in: one word for the sprint, or a 1–5 safety vote (anonymous). If the median safety vote is ≤ 3, switch to anonymous input for the whole retro and keep topics about process, not people.
- Review last retro’s actions: done / not done / helped? Keep, drop, or redo each.
2. Gather data
Bring data in before the meeting:
| Data | Source |
|---|---|
| Sprint goal met? Committed vs. done, carry-over | Board, sprint report |
| Cycle time, PRs waiting for review, blocked days | Tracker, git host |
| Incidents, pages, escaped bugs | On-call tool, bug tracker |
| Key events timeline | Team builds it together in 5 minutes |
Then 5–7 minutes of silent writing on sticky notes (one idea per note), before anyone talks. Silent writing prevents the loudest person from setting the agenda.
3. Generate insights
- Each person reads their notes briefly; group duplicates into clusters.
- Dot vote: each person gets 3 votes (fewer if the team is small) to pick topics.
- Take the top 1–3 clusters only. Timebox ~10–15 minutes each.
- Dig for cause with 5 whys or a quick fishbone (people, process, tools, environment). Stop when the cause is something the team can change.
Example 5 whys:
Problem: three stories carried over
Why? They were blocked waiting for review for 2+ days.
Why? Reviews queue behind feature work; nobody owns review time.
Why? We have no agreement on review turnaround.
Why? It was never discussed; we assumed people would pick them up.
Cause in our control: no team norm for review latency.4. Decide what to do
Action format: what + owner + by when + how we’ll know it worked.
| Weak action | Strong action |
|---|---|
| “Improve code review” | “Reviews picked up within 4 working hours; Ana adds a daily 2 pm review slot to the calendar by Monday; check median review wait in next retro (now 1.6 days)” |
| “Better communication with design” | “Designer joins refinement on Tuesdays for the next 2 sprints; Raj sends the invite today; count stories reopened for design questions (now 4)” |
| “Fix flaky tests” | “Quarantine the 5 flakiest tests by Friday (Mei); target: CI reruns < 1 per day” |
| “Management should hire more people” | Out of team control: escalate as a written ask with data, owned by the lead |
Put actions on the team board as real work items, sized and visible in the next sprint.
5. Close
Recap actions aloud, and ask for a 1–5 “was this retro worth the time?” vote. If the average is below 3 two retros in a row, change the format or the facilitator.
Choosing a format
| Team situation | Format | Prompts |
|---|---|---|
| Default, healthy team | Start / Stop / Continue | What should we start, stop, keep doing? |
| Want balance of positives | Went well / Didn’t / Puzzles | Include what confused us |
| Long sprint or project | Timeline + emotions | Plot events and energy over time, then discuss highs and lows |
| Goal-focused | Sailboat | Wind (helped), anchors (slowed), rocks (risks ahead), island (goal) |
| Same issues keep coming back | Circles and soup | What we control / influence / must accept; act only on the first two |
| Tension or low safety | Anonymous input + 4Ls | Liked, learned, lacked, longed for; collected anonymously beforehand |
| After a big launch or incident | Structured review | Use a blameless review format (see postmortems) |
| Experiment-minded | Hypothesis check | Last retro’s action as hypothesis: did the data move? |
Remote retros
- Use a shared board with anonymous note mode; cameras optional.
- Do silent writing in the tool with a visible timer.
- Round-robin speaking order so quieter people get the floor without asking.
- Asynchronous pre-work (notes added the day before) works well across time zones; keep the live session for clustering, discussion, and actions.
Gotchas
- No follow-up on actions. The fastest way to kill retros. Open with the review.
- Too many actions. Ten actions = zero actions. Vote down to three.
- Complaints about other teams only. Redirect to what this team can change, and turn the external issue into one escalation with an owner.
- Manager dominates or evaluates. If safety votes are low, the manager joins only for the actions stage, or the team shares a summary instead.
- Blaming individuals. Steer to systems: “what made this easy to get wrong?”
- Same format forever. Rotate every 3–4 retros.
- Skipping the retro when busy. Busy sprints are exactly when the retro pays off; run a 30-minute version rather than skipping.
Verification
- Last retro’s actions were reviewed with done / not done / helped.
- Data (goal met, carry-over, cycle time, incidents) was shown before opinions.
- ≤ 3 actions, each with owner, date, and a measurable signal, and each added to the backlog or board.
- Each action is in the team’s control, or is an explicit escalation with an owner.
- Retro-of-the-retro score recorded.
Output contract
# Retro: <team> — <sprint/project> — <date>
Facilitator: <name> Format: <format> Safety check median: <x>/5
## Last retro's actions
| Action | Owner | Status | Did it help? | Keep/drop |
## Data
Goal met: <yes/no> Committed/done: <x/y> Carry-over: <z%> Median cycle time: <d> Incidents: <n>
## Themes discussed (top voted)
- <theme> — cause found: <...>
## Actions (max 3)
| Action | Owner | Due | Success signal (baseline → target) |
## Escalations outside team control
## Retro-of-the-retro: <avg>/5About this skill
Written and maintained by the Claude Skills editors to the same editorial standard as every skill in the directory: a selective trigger, a real workflow, known pitfalls and a verification step. First published , last updated . MIT licensed.