Retrospective
Use this skill to conduct a retrospective that transforms reflection into concrete improvement actions.
Initial context received via slash: $ARGUMENTS
If
is filled, use as reference (e.g., period, sprint, initiative, delivery).
If empty, ask which period or delivery will be analyzed.
Language
Write the artifact in the user's language. Apply correct grammar and any required diacritics or script-specific characters. If the user's language is unclear, ask before generating output. Templates are in English — translate headers and content to match.
Project root
This skill writes artifacts at paths relative to the project root (the repo where the work happens), not the agent's current working directory.
- If invoked from inside the project, use the relative paths shown in this skill.
- If invoked from another directory (e.g., a sibling repo, or when the project lives elsewhere), prepend to every artifact path.
- When the project root is ambiguous, confirm with the user via the harness question tool before writing.
Prompting
Follow the project-wide convention in
/
("Skill Prompting Conventions"). Use the harness's structured-question tool —
(Claude Code),
(Codex), or
(OpenCode) — for the decision points below. Use free-form text only where a path/name/value cannot be enumerated.
| Decision point | Why structured | Suggested options |
|---|
| Retro scope | Affects depth and template | Per-story · Per-sprint · Per-epic |
| Facilitation style | Shapes the prompts | Start-Stop-Continue · Mad-Sad-Glad · 4Ls · Free-form |
Free-form prompts (no structured tool):
- Participant notes
- Improvement actions
No-pause mode: if the user has explicitly disabled mid-skill clarification, convert every structured prompt into an entry under Open questions (or equivalent) and proceed without blocking.
Objective
- Separate facts from opinions
- Identify what worked and what didn't (and why)
- Generate few clear actions with owner and deadline
- Feed process improvement, not just historical memory
- Reflect on delivery outcomes (what was planned vs what happened)
When to use
- A sprint or delivery cycle has ended
- The team needs to reflect on what worked and what needs to change
- Before starting the next sprint — retro feeds sprint planning
- After closing a significant delivery (via closure mode)
- Per-delivery reflection (what the old reflection covered)
- Per-sprint reflection (standard retrospective)
When NOT to use
- Mid-sprint status — use (checkpoint mode) instead
- Planning the next sprint — use instead (but retro should feed into it)
- Closing a delivery with verification — use (closure mode) first, then retro
- You need metrics/data — use first, then retro
Process
1. Collect inputs
Consult:
- Status closure reports from the period
- Status checkpoints and consolidation reports
- Sprint review (if it exists)
- Sprint metrics (if it exists)
- User or stakeholder feedback
2. Separate facts from opinions
- Facts: what happened (deliveries, blockers, deviations, metrics)
- Perceptions: how the team/individual felt about the process
3. Analyze
- What worked well: practices, tools, decisions that yielded results
- What didn't work: what caused friction, delay, or rework
- Why: root cause, not just symptom
4. Reflect on delivery outcomes
When running after a delivery closure:
- What was planned vs what was delivered
- Which decisions were right and which should change
- What would you do differently next time
- Technical debt or risks introduced
5. Define actions
- Limit to 2-3 actions per retro (focus > quantity)
- Each action must have:
- Specific description
- Responsible owner
- Deadline
- How to verify the improvement happened
6. Connect to next cycle
- How will these actions be observed in the next sprint/delivery?
- Does any action become a backlog item?
Where to save
planning/<initiative>/retro.md
planning/retros/retro-YYYY-MM-DD.md
Chaining
- If actions generate new tasks: suggest or
- If actions change process or expose skill/template gaps: suggest
- If the cycle restarts: suggest
Reference template
Use
from this skill as base.
Rules
- Retro is not venting or meeting minutes. It's an improvement tool.
- Actions must be specific and executable, not vague ("improve communication" is not an action).
- Each action must have an owner. Action without owner won't happen.
- Limit actions to 2-3 per retro. Many actions = none executed.
- If the same action appears in consecutive retros, the problem is deeper — discuss root cause.
Relationship with the flow
mermaid
flowchart LR
A["/agile-status<br>(closure)"] --> B["/agile-retro"]
B --> C[improvement actions]
C --> D["/agile-sprint"]
This skill closes the feedback loop. For closing deliveries, use
(closure mode) first. For metrics data, use
first. The next cycle starts with
.