skills/retrospectives/SKILL.md
Sprint and quarterly retrospective facilitation. Use when: running a sprint retro, facilitating a quarterly retrospective, choosing retro formats, tracking action items from retros, identifying patterns across retros, or improving team retrospective culture. Covers facilitation techniques, formats, action tracking, and anti-patterns.
npx skillsauth add michaelsvanbeek/personal-agent-skills retrospectivesInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
| Time | Activity | |------|----------| | 0:00–0:05 | Check-in: Review previous action items — completed? In progress? Dropped? | | 0:05–0:10 | Set the stage: State the retro format, remind of ground rules | | 0:10–0:30 | Gather data: Team writes and shares observations (format-dependent) | | 0:30–0:45 | Generate insights: Group, discuss, and prioritize themes | | 0:45–0:55 | Decide actions: Pick 1–3 action items with owners and due dates | | 0:55–1:00 | Close: Quick round — one word for how you feel about the sprint |
Rotate formats every 2–4 sprints to keep things fresh.
Best for: General-purpose, new teams, quick retros
| Column | Prompt | |--------|--------| | Start | What should we start doing that we're not doing? | | Stop | What should we stop doing because it's not helping? | | Continue | What's working well that we should keep doing? |
Best for: After a major release or project milestone
| Column | Prompt | |--------|--------| | Liked | What did you enjoy or appreciate? | | Learned | What did you learn this sprint? | | Lacked | What was missing or insufficient? | | Longed For | What do you wish you had? |
Best for: Emotional check-in after a tough sprint, or when morale seems low
| Column | Prompt | |--------|--------| | Mad | What frustrated you? | | Sad | What disappointed you? | | Glad | What made you happy? |
Best for: Visual thinkers, identifying forces helping and hindering the team
Draw a sailboat:
Best for: Quarterly retros or after a long project
Create a timeline of the sprint/quarter. Team adds sticky notes for:
Discuss patterns in the timeline.
Best for: Large teams (8+), deep-dive on a specific topic
A quarterly retro looks at patterns across sprints, not individual sprint issues. It's about systemic improvements.
| Time | Activity | |------|----------| | 0:00–0:10 | Review quarterly OKR scores and delivery metrics | | 0:10–0:20 | Review action items from previous quarterly retro | | 0:20–0:50 | Timeline exercise across the quarter — highs, lows, key events | | 0:50–1:10 | Theme discussion — What patterns do we see? What systemic issues? | | 1:10–1:25 | Action items — 2–4 systemic improvements with owners | | 1:25–1:30 | Close — Appreciation round (each person appreciates one teammate) |
## Retro Action Items — Sprint [N] / Q[N]
| # | Action | Owner | Due Date | Status |
|---|--------|-------|----------|--------|
| 1 | [Action] | @name | YYYY-MM-DD | Open |
| 2 | [Action] | @name | YYYY-MM-DD | Open |
| 3 | [Action] | @name | YYYY-MM-DD | Open |
| Anti-Pattern | Problem | Better Approach | |-------------|---------|----------------| | Same format every time | Team tunes out, engagement drops | Rotate formats every 2–4 sprints | | No action items | Retro becomes a venting session | Always end with 1–3 actions with owners | | Actions never reviewed | Trust in the retro process erodes | Start every retro reviewing last retro's actions | | Manager dominates | Team stops sharing honestly | Manager speaks last, facilitator rotates | | Blame individuals | Kills psychological safety | Focus on process and systems, not people | | Skipping retros | Problems compound, morale drops | Retros are non-negotiable; reschedule, don't cancel | | Too many action items | Nothing gets done | Cap at 3; do fewer things well |
development
TypeScript coding standards and type safety conventions. Use when: creating TypeScript files, defining interfaces and types, writing type-safe code, reviewing TypeScript for type correctness, auditing a codebase for type safety gaps, eliminating any or ts-ignore usage, or improving strict-mode compliance. Covers strict typing, avoiding any and ts-ignore, discriminated unions, Zod runtime validation, immutability patterns, and proper type definitions.
testing
Writing clear, actionable tickets in any issue tracker (Jira, Linear, GitHub Issues, ServiceNow, etc.). Use when: creating epics, stories, tasks, bugs, or spikes; writing acceptance criteria; decomposing work for a sprint; linking dependencies between tickets; auditing backlog items for clarity; or coaching a team on ticket quality. Covers title conventions, description templates, acceptance criteria, decomposition rules, dependency linking, and org-specific pluggable configuration.
development
Testing strategy, patterns, and evaluation for software and LLM/AI systems. Use when: writing tests, choosing test boundaries, designing test data, structuring test suites, evaluating LLM outputs, building evaluation pipelines, setting coverage thresholds, auditing test coverage gaps in existing projects, or improving test quality and structure.
development
Writing effective status updates for different audiences and cadences. Use when: writing a weekly status update, preparing a monthly summary, drafting a quarterly review, sending updates to leadership, sharing progress with stakeholders, or improving the clarity and impact of team communications. Covers weekly, monthly, and quarterly formats tailored for upward, lateral, and downward communication.