Retro facilitator
@opsdesk/retro-facilitator
Run a retro that ends in change: pick the format, collect input ahead of time, cluster it into themes, run the vote, and leave with at most three actions that each have an owner and a date. Checks last retro's actions first.
SkillOtherv1.0.0 (latest)
- Activity
- New: be the first to try it
- Installs
- 0 installs
- Likes
- 0 likes
- Clones
- 0 clones
- 1---
- 2name: retro-facilitator
- 3description: Plan and run a team retrospective or blameless post-mortem, from picking the format to clustering input into themes and leaving with at most three owned actions. Use when someone says "run a retro", "we need a post-mortem on the launch", "help me facilitate our quarterly retro", "cluster these retro notes", or "what came out of our last retro".
- 4license: MIT
- 5---
- 7# Retro facilitator
- 9Most retros produce a long list and no change. This one checks what happened to last time's actions, gets everyone's input before the meeting, groups it into themes, and ends with three or fewer actions, each with one owner and a date.
- 11## Inputs
- 13Ask for what is missing:
- 151. **What is being reviewed:** a sprint, a quarter, a launch, an incident, an event.
- 162. **Who is in the room** (roles, rough count) and how long the meeting is. Default: 45 minutes, up to 8 people.
- 173. **Last retro's actions**, if any. Look in `retros/` first.
- 184. **Input**, if already collected: sticky notes, a doc, a form export. Otherwise you will write the pre-read.
- 20## Steps
- 221. **Pick the format** and say why in one line:
- 23 - **Start, Stop, Continue:** default for sprints and teams that are new to retros.
- 24 - **4Ls (Liked, Learned, Lacked, Longed for):** quarters and long projects.
- 25 - **Sailboat (wind, anchors, rocks, island):** when the team is stuck or morale is low.
- 26 - **Blameless post-mortem (timeline, impact, contributing factors, what helped, actions):** incidents, missed launches, anything with customer impact.
- 272. **Write the pre-read** to `retros/<yyyy-mm-dd>-<topic>/pre-read.md`: the goal, the format's prompts, a 10-minute ask to add three items per prompt before the meeting, and last retro's actions with their status. The user shares it.
- 283. **Score last retro's actions first.** Done, not done, or dropped. If most were not done, the top theme today is probably "we do not follow through", and the meeting should say so.
- 294. **Cluster the input** into 3 to 6 themes. Merge duplicates and count them (duplicates are signal). Name each theme as a problem or strength, not a category: "Sales hears about date changes last", not "Communication". Quote one or two items per theme.
- 305. **Write the agenda** for the meeting length. For 45 minutes: 5 check-in and last actions, 10 read and react to themes, 5 vote (3 dots each), 20 discuss the top two or three, 5 agree actions.
- 316. **After the vote**, turn the top themes into at most three actions, each with one owner, a date, and how you will know it worked. Prefer small, testable changes ("freeze launch date 10 days out") over values ("communicate better").
- 327. **Write the summary** to `retros/<yyyy-mm-dd>-<topic>/summary.md` (format below) and show it.
- 34## Output format
- 36```markdown
- 37# Retro: Q3 product launch, 2026-11-04
- 39**Last time's actions:** 1 of 2 done. Launch date agreement with Sales did not happen, and it showed up again today.
- 41## Themes (votes)
- 421. **Sales hears about date changes last** (7): "Sales found out about the date change from a customer."
- 432. **Launch-day sequencing gaps** (4): pricing page went live 3 hours after the email.
- 443. **Too many approvers** (2)
- 454. **What worked:** launch checklist, support macros, daily standup. Keep these.
- 47## Actions (max 3)
- 48| Action | Owner | Due | We will know it worked when |
- 49| ------ | ----- | --- | --------------------------- |
- 50| Name one launch date owner; freeze 10 days out | Head of Product | 2026-11-15 | Next launch date moves zero times after freeze |
- 52**Next retro:** <date>. First item: review these actions.
- 53```
- 55## Guardrails
- 57- Blameless by default. Rewrite items that name or blame a person into what happened and what made it likely ("the review step had no deadline", not "the reviewer was slow"). Tell the user you rewrote them.
- 58- Never more than three actions. Park the rest under "Parked" so nothing is lost.
- 59- Keep individual input anonymous in the summary unless the team asked otherwise.
- 60- If input points to a people issue (conflict, performance), leave it out of the summary and suggest the user handle it 1:1.
