retro
Run a retrospective — review last time's actions, gather what went well/badly from data and the team, and leave 1–3 owned, dated improvement actions.
Works with
---
name: retro
description: Run a retrospective — review last time's actions, gather what went well/badly from data and the team, and leave 1–3 owned, dated improvement actions.
license: MIT
---
# Retrospective
Leave the team better than the iteration found it. A retro that produces no owned action, or whose previous actions silently evaporated, is theatre — the previous-actions check is why this ritual starts in the past.
## 1. Previous actions first
Find the last retro's actions (issues labelled `retro-action`). Report each: done, in progress, or dropped. A dropped action gets discussed — was it wrong, or was it abandoned? — before any new actions are taken on. Recurring drops mean the team is over-committing on improvements: take fewer.
## 2. Gather
Two sources, in order:
- **Data** — from the board: planned-vs-delivered, carry-over, cycle-time outliers, impediments opened/closed, review pile-ups. Present as observations ("4 of 9 items carried over"), never verdicts.
- **The team** — ask the user for the human side. Default format: Start / Stop / Continue; switch format when the last one went stale (options in the Delivery Lead's [facilitation-techniques.md](../delivery-lead/references/facilitation-techniques.md)).
## 3. Converge on 1–3 actions
Pick the vital few, not the exhaustive list. Each action: specific, owned by a named person, dated (usually "by next retro"), and small enough to actually happen alongside normal work. File each as an issue labelled `retro-action`. A systemic pattern the team can't fix alone gets framed as an escalation instead — name who needs to hear it.
Done when: every previous action has a reported status, and 1–3 new `retro-action` issues exist with owner + date. Close with a three-line summary: kept, dropped, decided.More Project Management skills
firecrawl-build-onboarding
firecrawl/skills
Get Firecrawl credentials and SDK setup into a project. Use when an application needs `FIRECRAWL_API_KEY`, when an agent should add Firecrawl to `.env`, when the user wants to authenticate Firecrawl for app code, or when choosing the first SDK and docs for a new Firecrawl integration. This skill includes its own browser auth flow, so it does not depend on the website onboarding skill.
email-sequence
coreyhaines31/marketingskills
When the user wants to create or optimize an email sequence, drip campaign, automated email flow, or lifecycle email program. Also use when the user mentions "email sequence," "drip campaign," "nurture sequence," "onboarding emails," "welcome sequence," "re-engagement emails," "email automation," "lifecycle emails," "trigger-based emails," "email funnel," "email workflow," "what emails should I send," "welcome series," or "email cadence." Use this for any multi-email automated flow. For cold outreach emails, see cold-email. For in-app onboarding, see onboarding-cro.
onboard
pbakaus/impeccable
Designs and improves onboarding flows, empty states, and first-run experiences to help users reach value quickly. Use when the user mentions onboarding, first-time users, empty states, activation, getting started, or new user flows.
