# Agile Retro

> Conducts retrospective with learnings and improvement actions. Use when a cycle, sprint, or delivery has ended and the team needs to reflect on what worked and what needs to change. Also absorbs post-implementation reflection aspects.

- Skill: `djalmajr/agile-retro` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add djalmajr/agile-retro`
- Raw SKILL.md: https://api.skillmd.com/api/skills/djalmajr/agile-retro/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: djalmajr (https://skillmd.com/u/djalmajr)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/djalmajr/agile-retro

---


# Retrospective

Use this skill to conduct a retrospective that transforms reflection into concrete improvement actions.

Initial context received via slash: $ARGUMENTS

If `$ARGUMENTS` 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 `<project-root>/` 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 `CLAUDE.md` / `AGENTS.md` ("Skill Prompting Conventions"). Use the harness's structured-question tool — `AskUserQuestion` (Claude Code), `ask_user_question` (Codex), or `question` (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 `/agile-status` closure mode)
- Per-delivery reflection (what the old `/post-impl` reflection covered)
- Per-sprint reflection (standard retrospective)

## When NOT to use

- Mid-sprint status — use `/agile-status` (checkpoint mode) instead
- Planning the next sprint — use `/agile-sprint` instead (but retro should feed into it)
- Closing a delivery with verification — use `/agile-status` (closure mode) first, then retro
- You need metrics/data — run `/agile-review` first (its metrics section), 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` if it's a retro for an initiative
- `planning/retros/retro-YYYY-MM-DD.md` if it's a sprint/period retro

## Chaining

- If actions generate new tasks: suggest `/agile-story` or `/agile-epic`
- If actions change process or expose skill/template gaps: record them in the retro for human review
- If the cycle restarts: suggest `/agile-sprint`

## Reference template

Use `templates/retro.md` 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 `/agile-status` (closure mode) first. For the demo and sprint numbers, use `/agile-review` first. The next cycle starts with `/agile-sprint`.