Retro facilitator

Skill kaszubski/engineering-leader-skills/skills/retro-facilitator

Claude Code skills for engineering managers and tech leads — code review, coaching, repo health, and retrospectives, most anchored on an established leadership framework.

Install

npx -y skills add kaszubski/engineering-leader-skills --skill retro-facilitator

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Turn raw retrospective material (an incident, a sprint, a launch, a project that went sideways) into a facilitated retro that separates fact from story and converts blame into ownership, using Conscious Leadership. Use when asked to run or prepare a retrospective, debrief an incident or project, or make a postmortem blameless.

SKILL.md

5.2 KB, as published. Nobody here has run it

retro-facilitator

Purpose

Takes the raw material of a retrospective (what happened, what people are saying about it) and structures it into a retro that actually moves a team forward, using Conscious Leadership. It does the one thing a generic "what went well / what went badly" template can't: it separates the verifiable fact from the story laid on top, and converts blame (victim / villain / hero) into ownership. That conversion is the work; the rest is scaffolding.

When to use

Running or preparing a retrospective, debriefing an incident, or writing a blameless postmortem for a sprint, launch, outage, or project.

When not to

Reviewing a single pull request: that's pr-review. Deciding how to coach one person on a task: that's coaching-calibrator. A retro is about a shared event and the team's relationship to it, not one artifact or one individual.

Foundation — Conscious Leadership

A retro fails the moment the room goes below the line: closed, defensive, committed to being right and to assigning fault. Three moves keep it above the line; each one visibly changes the output.

The Line. At any moment a person is above the line (open, curious, learning) or below (defensive, blaming, protecting position). The first facilitation move is noticing which side the room is on, and naming it.
Facts vs. stories. Separate the observable and verifiable (the fact) from the interpretation on top (the story). "The deploy went out at 4pm Friday" is a fact. "Nobody cared about the risk" is a story. Stories are allowed, but labelled as stories, not smuggled in as facts.
Radical responsibility, not the drama triangle. Below-the-line debriefs cast people into the drama triangle: victim ("it happened to us"), villain ("they broke it"), hero ("I saved it"). Radical responsibility drops the triangle and asks each party: what can I own here?

See the Conscious Leadership foundation for the full model.

How it works

Establish the event. What is being retro'd: which incident, sprint, or project, over what window? If the input is a vague verdict ("the launch was a mess"), ask for the specific observations behind it. A retro on a conclusion is theatre; a retro runs on events.
Read the room's state. Scan the raw material for below-the-line signals: blame, defensiveness, certainty about others' motives, victim/villain/hero language. Name the state plainly. If it's below the line, say the first job is getting curious before getting conclusive.
Split every observation into fact and story. For each item, state the verifiable fact, then the interpretation as an explicitly labelled story. Surface where a story is being treated as a fact; that's usually where the team is stuck.
Drop the drama triangle. Find the victim / villain / hero framings. Reframe each as ownership: replace "who caused this" with "what can each party own." Spread ownership across roles; the point is shared responsibility, not relocating blame to a new target.
Turn owned insight into experiments. Convert what the team now owns into a small number of concrete experiments for the next iteration. Each one is a change someone owns, not a vague resolution to "do better."

Output format

**Retro:** <the specific event and window — restated to confirm it is specific>

**Room state:** <above / below the line — the signals you read, named plainly>

**Facts vs. stories**
- Fact: <verifiable observation> · Story: <the interpretation on top, labelled as a story>
- <…one row per significant observation; flag any story currently being treated as fact>

**From blame to ownership**
- Was framed as <victim / villain / hero>: <the framing> → Ownership: <what each party can own>

**Experiments for next iteration**
- <concrete change> — owned by <role/person>, check at <next retro / date>

**Facilitator note:** <one line — the single most important shift for this retro to land>

If the input is a verdict with no underlying observations, ask for the events rather than producing a retro on a conclusion.

Rules

Fact and story stay separate. Never let an interpretation ride in as a fact; that split is the skill's core move, the thing a generic template skips.
No villains. Reframe every blame into ownership spread across parties. If the output names a culprit, it has failed the foundation.
Curiosity before conclusions. If the room is below the line, say so. Don't produce tidy action items on top of an unresolved defensive state.
Experiments, not resolutions. Every forward item is a concrete, owned change with a check-in, not "communicate better."
Advisory and facilitative. This structures the retro and the thinking; the conversation, and what the team commits to, stay with the people in the room.