Retrospective
A retrospective is a structured reflection that helps teams learn from their experiences and continuously improve. By regularly examining what went well, what didn't, and what to change, teams build a culture of learning and adaptation. The value isn't just in the discussion.it's in the documented actions and follow-through.
When to Use
- At the end of every sprint (for agile teams)
- After completing a significant project or milestone
- Following a major incident or outage
- When team dynamics feel off and need addressing
- At regular intervals (monthly, quarterly) even without specific triggers
- When onboarding new team members to establish improvement culture
When NOT to Use
- You want one durable learning banked for the organization -> use
iterate-lessons-log; the retro is the ceremony, the log entry outlives it - You are scoring an OKR cycle at close -> use
measure-okr-grader - The reflection must end in a pivot-or-persevere call -> use
iterate-pivot-decision - You need a recap of a general (non-retro) meeting -> use
foundation-meeting-recap
Instructions
When asked to facilitate or document a retrospective, follow these steps:
-
Set the Context Define what period or project this retrospective covers, who attended, and any significant events that occurred. This frames the discussion and helps future readers understand the context.
-
Choose a Format Select a retrospective format that fits the team's needs. Common options include:
- Start/Stop/Continue: Simple and direct
- 4Ls: Liked, Learned, Lacked, Longed for
- Mad/Sad/Glad: Emotion-focused
- Sailboat: Visual metaphor (wind=helps, anchor=holds back)
-
Gather Input Collect observations from all team members. Ensure everyone contributes.quiet voices often have important insights. Group similar items to identify themes.
-
Discuss and Prioritize Don't try to address everything. Focus the discussion on the most impactful items. Vote or discuss to identify the top 2-3 issues to address.
-
Define Action Items Convert insights into specific, assignable actions. Every action needs an owner and a due date. Avoid vague improvements like "communicate better."
-
Review Previous Actions Check the status of action items from the last retrospective. Celebrate completions and discuss blockers for incomplete items. This builds accountability.
-
Document for Future Reference Capture the key points so they're available for future team members and for tracking patterns over time.
Project Memory Contract
Active only when .claude/pm-skills.local.md exists. With no file, ignore this section entirely
and behave exactly as described above.
- Reads: the recent
artifacts[]entries, so the retrospective can look at what the cycle actually produced instead of relying on recall. - Writes: the lessons as an
interpretationartifact. - Posture: propose the entry and wait for confirmation before writing, unless
memory_auto_append: trueis set, in which case append and echo what was written. - Write discipline: re-read the file immediately before writing, never from the copy that produced the proposal. If it changed in between, merge your entry into the current state and re-propose rather than overwriting; add only your own entry and leave every other field and section byte-identical. Nothing enforces this at runtime and the file is gitignored, so a careless whole-file write loses another session's work with no way to recover it.
A retrospective surfaces raw observations, patterns, and commitments at once. Record the durable half, the lessons, under a single tag; a downstream reader needs to know how firmly to weight the entry, and a mixed tag tells it nothing.
Output Format
Use the template in references/TEMPLATE.md to structure the output. A complete retrospective fills every template section: Overview; Previous Retrospective Review; What Went Well; What to Improve; Discussion Notes; Action Items; Parking Lot; Metrics and Trends; Facilitator Notes; and Next Retrospective.
Quality Checklist
Before finalizing, verify:
- All attendees had opportunity to contribute
- Both positives and improvements are captured
- Action items have owners and due dates
- Previous retrospective actions are reviewed
- A reader who missed the retro can tell what was decided and who owns each action from this document alone
Examples
See references/EXAMPLE.md for a completed example.
