Facilitates and documents a team retrospective capturing what went well, what to improve, and action items. Use at the end of a sprint, project, or milestone to reflect and improve team practices. To bank individual learnings into organizational memory afterward, use iterate-lessons-log.

<! PM Skills https://github.com/product on purpose/pm skills Apache 2.0 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: 1. 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. 2. 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) 3. Gather Input Collect observations from all team members. Ensure everyone contributes.quiet voices often have important insights. Group similar items to identify themes. 4. 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. 5. Define Action Items Convert insights into specific, assignable actions. Every action needs an owner and a due date. Avoid vague improvements like "communicate better." 6. Review Previous Actions Check the status of action items from the last retrospective. Celebrate completions and discuss blockers for incomplete items. This builds accountability. 7. 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 interpretation artifact. Posture: propose the entry and wait for confirmation before writing, unless memory auto append: true is 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.

iterate-retrospective