run-retrospective

name	run-retrospective
description	Produce a structured retrospective document from a sprint or body-of-work description. Follows the Derby-Larsen five-phase framework with blameless framing and SMART action items.
user-invokable	true
context	fork
allowed-tools	Read, Grep, Glob
argument-hint	[description of the sprint, milestone, or body of work to retrospect]

Run Retrospective

Produce a structured retrospective document that helps a team introspect a body of work and identify concrete improvements. The output follows the Derby-Larsen five-phase retrospective framework (Set the Stage, Gather Data, Generate Insights, Decide What to Do, Close the Retrospective) adapted for AI-assisted analysis.

Input

$ARGUMENTS = description of the body of work to retrospect — sprint number and team name, milestone description, date range, or a narrative summary of what was delivered and what happened.

Process

1. Handle Missing Input

If $ARGUMENTS is empty or contains no actionable description, prompt the team lead for the minimum information needed to begin. Present these questions in a single consolidated prompt:

• What work are we retrospecting? — Sprint number, milestone name, or date range.
• Who is the team? — Team name or composition (helps frame observations).
• What was delivered? — Key deliverables, features shipped, or goals targeted.
• What notable events occurred? — Incidents, blockers, surprises, scope changes, staffing changes, or process experiments.

Do not proceed until at least a work scope and one or more notable events or deliverables are provided.

2. Gather Context

• Read the project's CLAUDE.md for architecture, domain language, and team conventions
• Scan for a roadmap or backlog file if one exists (Glob for roadmap*, backlog*, TODO*)
• Check project memory for recent work completions, decisions, and open questions logged by the product-owner agent
• Identify any patterns across prior retrospectives if retrospective artifacts exist in the project

3. Set the Stage

Establish the retrospective's scope and framing:

• Scope statement: What period or body of work is being reviewed (sprint dates, milestone name, or work description)
• Prime Directive: Frame the retrospective under the Retrospective Prime Directive — "Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand." This is not decorative; it is a structural constraint on the language used throughout the document.
• Blamelessness constraint: All observations, insights, and action items throughout the document must be framed in terms of systems and processes. No language may attribute outcomes to individual people.

4. Gather Data

Collect and organize observations about what happened during the retrospected period. Draw from:

• The input description provided by the team lead
• Project memory (work completions, decisions, surprises logged by product-owner)
• Codebase signals (commit patterns, file churn, test coverage changes — if available and relevant)
• Any context the team lead provided about events, blockers, or scope changes

Organize observations into themes. Common theme categories include (use whichever are relevant, not all):

• Delivery and throughput — what shipped, what didn't, velocity patterns
• Quality — bugs, rework, test gaps, incidents
• Process and workflow — ceremonies, handoffs, tooling, communication patterns
• Scope and planning — estimation accuracy, scope creep, dependency surprises
• Team dynamics — collaboration patterns, knowledge silos, onboarding

For each observation, note whether it is something the team should continue doing (a strength), stop doing (a drag), or start doing (an opportunity).

5. Generate Insights

Analyze the observations from Step 4 to identify root causes and systemic patterns. Move beyond surface-level symptoms:

• Why did things go well? What systemic conditions enabled the wins?
• Why did things go poorly? What process, tooling, or structural factors contributed?
• Use the "5 Whys" technique when a surface observation masks a deeper systemic issue
• Look for connections between themes — e.g., scope creep causing quality issues, or communication gaps causing rework

Each insight must name the systemic factor, not an individual. Frame as: "The [process/system/practice] caused [outcome] because [mechanism]."

6. Decide What to Do

Propose 1-3 concrete improvement actions based on the insights from Step 5. Each action item must satisfy all five SMART criteria:

Criterion	Requirement
Specific	Names the exact change — what will be different
Measurable	Defines how success will be observed or measured
Achievable	Is within the team's control to implement (enforced by quality gates below, not a separate output field)
Relevant	Directly addresses a root cause identified in Step 5
Time-bound	States when the action will be completed or reviewed

Quality gates:

• Maximum 3 action items. Teams that commit to more than 3 improvements rarely complete any. If more than 3 candidates emerge, prioritize by impact and achievability.
• No vague formulations. "Improve communication" is not an action item. "Hold a 15-minute daily sync focused on cross-team blockers, starting next sprint, and review effectiveness at the next retrospective" is.
• Each action item must trace back to a specific insight from Step 5.

7. Close the Retrospective

Summarize the retrospective and capture appreciation:

• Wins to celebrate: 2-4 specific accomplishments, strengths, or positive patterns worth acknowledging. Celebrating what went well reinforces the behaviors the team should continue.
• Summary: A 2-3 sentence narrative capturing the retrospective's key finding and the team's improvement commitment.

8. Produce Structured Output

Format the output using the Output section below.

Output

## Scope Reviewed

**Period**: [Sprint N / dates / milestone name]
**Team**: [Team name or composition]
**Prime Directive**: Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.

## Key Observations

### [Theme 1 Name]

- **Continue**: [Observation — what the team did well in this area]
- **Stop**: [Observation — what is dragging the team down]
- **Start**: [Observation — an opportunity the team hasn't tried yet]

### [Theme 2 Name]

- **Continue**: [Observation]
- **Start**: [Observation]

[Additional themes as needed. Not every theme needs all three categories.]

## Insights and Root Causes

1. **[Insight title]** — [Explanation of the systemic factor, its mechanism, and its impact. References specific observations from the Key Observations section.]

2. **[Insight title]** — [Explanation]

[2-5 insights, each tracing back to observations above.]

## SMART Action Items

1. **[Action title]**
   - **What**: [Specific change to implement]
   - **Measure**: [How success will be observed]
   - **Owner**: [Role or function responsible — never an individual name]
   - **Timeline**: [When to complete or review]
   - **Traces to**: [Which insight this addresses]

2. **[Action title]**
   - : [Specific change]
 : [Success indicator]
 : [Role or function]
 : [Deadline or review point]
 : [Insight reference]

[1-3 action items. No more than 3.]



 [Specific accomplishment or strength to celebrate]
 [Specific accomplishment or strength to celebrate]

[2-4 items.]



[2-3 sentence narrative: the key finding, the improvement commitment, and the overall team trajectory.]

Omit theme categories (Continue/Stop/Start) within a theme when they do not apply. Keep each observation to 1-2 sentences. Action items should be concrete enough that someone could execute them without asking follow-up questions.