Plans and writes up a team retrospective with a facilitation plan, Start, Stop, Continue or 4Ls prompts, unattributed themes, owned actions and the check for next time. Use for "run mgr-team-retrospective", "team retrospective", "retro agenda", "start stop continue", "4Ls retro", "the same problems keep coming back", "turn retro notes into actions", part of the AI for Managers Pack by Polar Bear.
Installs into .claude/skills of the current project.
Are you the author of Mgr Team Retrospective?
Add the live security badge to your README. It updates with every re-scan.
[](https://www.skillsdirectory.com/skills/polar-bear-org-mgr-team-retrospective)
---
name: mgr-team-retrospective
description: Plans and writes up a team retrospective with a facilitation plan, Start, Stop, Continue or 4Ls prompts, unattributed themes, owned actions and the check for next time. Use for "run mgr-team-retrospective", "team retrospective", "retro agenda", "start stop continue", "4Ls retro", "the same problems keep coming back", "turn retro notes into actions", part of the AI for Managers Pack by Polar Bear.
---
# Team Retrospective (Start, Stop, Continue)
## When To Use
The same problems keep coming back: the same handoff breaks, the same deadline slips, the same complaint surfaces in the private chat. Use this to plan a retrospective and turn what the team says into a few owned changes, answering: what will we do differently, and how will we know next time?
## When Not To Use
If people have stopped speaking up at all, a retro will collect silence; run Team Psychological Safety Check first. If the problem is two people who cannot work together, run Conflict Resolution; a group session is the wrong room for it.
## Inputs
- The period or piece of work to look back on, and what happened in it
- Last retro's actions, if any
- Team size, the time you have, live or written; afterwards, the raw notes stripped of names
If you have none of this, I start from the period alone and mark the plan as a first draft.
## Approach
Start, Stop, Continue is a common retrospective format with no single originator, described here generically; the structure and the 4Ls variant (loved, loathed, learned, longed for) follow the Atlassian Team Playbook retrospective play. A retro only works when people feel safe to name what went wrong, the team learning behaviour that Edmondson (1999) linked to psychological safety. The failure it prevents: the retro that produces the same three sticky notes every month because nobody checked whether last month's actions happened.
## Workflow
1. Ask up to three questions at once: which period or project, whether last time's actions were written down, and whether the team is tired of the usual format.
2. Open by checking last time's actions: done, in progress, or dropped and why. If nothing was done, that is the first theme.
3. Set the tone in one or two sentences you say aloud: what is shared is about the work and how to improve it, not about blame. I draft them in your voice.
4. Gather with Start, Stop, Continue, or the 4Ls if the format has gone stale. Silent writing first, then sharing, so the loudest voice does not set the list. You set the time box for each part, and writing never gets squeezed to make room for talk.
5. Group the notes into themes, with no names attached. The team picks the few themes that matter, by dot vote or discussion; I do not pick for them.
6. Turn each chosen theme into one action with an owner and a date. Fewer beats more: two actions done beat six forgotten. The check for next time is written now.
## Output Format
```markdown
# Team Retrospective
Period: [dates or project] | Format: [Start, Stop, Continue or 4Ls] | Time: [user sets]
## Last Time's Actions
| Action | Owner | Status (done, in progress, dropped) | Why |
|---|---|---|---|
| [action] | [name] | [status] | [reason] |
## Facilitation Plan
| Step | What happens | Time |
|---|---|---|
| [opening, gather, themes and vote, actions] | [what happens] | [minutes] |
## Themes (unattributed)
| Theme | Notes grouped under it | Chosen by the team (yes, no) |
|---|---|---|
| [theme] | [count or short summary] | [yes or no] |
## Owned Actions
| Action | Owner | Date | How we check next time |
|---|---|---|---|
| [verb + finish line] | [name] | [date] | [observable sign] |
## Decision
[name] confirms the actions with each owner by [date] and opens the next retro on [date] with this list.
```
## Done When
- Last time's actions were reviewed before anything new was gathered
- Every theme is about the work, small enough to act on, with nothing traceable to a person
- The team, not Claude, chose which themes to act on
- Each action has one owner, a date and a check for next time
## Quality Bar
- The gathering step is silent writing first, so quieter people are heard
- Swap to the 4Ls when the team gives the same answers every time
- About the work, not people: Claude never turns retro notes into blame or names
## Next
Run mgr-team-charter (Team Charter) when the retro shows the team lacks a shared picture of good.
## About the makers
This pack is made by Polar Bear, a consultancy built by ex-McKinsey founders with a dream to make AI work for People, not instead of them. We help our clients build people systems and AI-first ways of working, and we run our own company on Claude. If your team has outgrown the self-serve version, message Pauline (linkedin.com/in/paulinebertry).