Skip to content
SlashClone
Made by@opsdesk

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

How this works

  1. It is a skill: written instructions Claude reads when your request matches what the skill is for. You do not call it by name; just ask for the task.
  2. While it works, it reads and changes files in the places it lists, nowhere else.
  3. Nothing runs until you choose to use it, and you can remove it any time.

SKILL.md

Retro facilitator

Most 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.

Inputs

Ask for what is missing:

  1. What is being reviewed: a sprint, a quarter, a launch, an incident, an event.
  2. Who is in the room (roles, rough count) and how long the meeting is. Default: 45 minutes, up to 8 people.
  3. Last retro's actions, if any. Look in retros/ first.
  4. Input, if already collected: sticky notes, a doc, a form export. Otherwise you will write the pre-read.

Steps

  1. Pick the format and say why in one line:

    • Start, Stop, Continue: default for sprints and teams that are new to retros.
    • 4Ls (Liked, Learned, Lacked, Longed for): quarters and long projects.
    • Sailboat (wind, anchors, rocks, island): when the team is stuck or morale is low.
    • Blameless post-mortem (timeline, impact, contributing factors, what helped, actions): incidents, missed launches, anything with customer impact.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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").
  7. Write the summary to retros/<yyyy-mm-dd>-<topic>/summary.md (format below) and show it.

Output format

# Retro: Q3 product launch, 2026-11-04

**Last time's actions:** 1 of 2 done. Launch date agreement with Sales did not happen, and it showed up again today.

## Themes (votes)
1. **Sales hears about date changes last** (7): "Sales found out about the date change from a customer."
2. **Launch-day sequencing gaps** (4): pricing page went live 3 hours after the email.
3. **Too many approvers** (2)
4. **What worked:** launch checklist, support macros, daily standup. Keep these.

## Actions (max 3)
| Action | Owner | Due | We will know it worked when |
| ------ | ----- | --- | --------------------------- |
| Name one launch date owner; freeze 10 days out | Head of Product | 2026-11-15 | Next launch date moves zero times after freeze |

**Next retro:** <date>. First item: review these actions.

Guardrails

  • 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.
  • Never more than three actions. Park the rest under "Parked" so nothing is lost.
  • Keep individual input anonymous in the summary unless the team asked otherwise.
  • If input points to a people issue (conflict, performance), leave it out of the summary and suggest the user handle it 1:1.

README.md

Retro facilitator

Helps you run a retro or blameless post-mortem that actually changes something. It picks the format, writes the pre-read, clusters everyone's input into themes, and ends with at most three actions, each with an owner and a date.

Who it is for

COOs, founders, and team leads who run sprint, quarter, launch, or incident retros and are tired of long lists that nobody acts on.

Example

Input: examples/q3-launch-input.md, sticky notes from a launch retro in Start, Stop, Continue format, plus last retro's two actions.

Ask: "Cluster these and give me the summary."

Output (shortened):

**Last time's actions:** 1 of 2 done. Launch date agreement with Sales did not happen, and it showed up again today.

## Themes
1. **Sales hears about date changes last** (2 duplicate notes)
2. **Launch-day sequencing gaps:** pricing page went live 3 hours after the email.
3. **Too many approvers:** 5 reviewers, 4 days.

## Actions (max 3)
| Action | Owner | Due |
| ------ | ----- | --- |
| Name one launch date owner; freeze 10 days out | Head of Product | 2026-11-15 |

What it can access

  • Reads and writes retro files in retros/ (and reads the sample in examples/).
  • No scripts, no network, no API keys. Works in Claude Code, Codex, and Cursor.

Setup

None.

Files

  • README.md
  • SKILL.md
  • examples/q3-launch-input.md
  • kit.json

Did it work?

0worked for them0did not work

Sign in to say whether it worked for you.

Nobody has said yet. Tried it? Tell the next person.