agentleFS
dawn840705dawn840705/claude-code-studios/skills/retrospective/SKILL.md

retrospective

Skill1 starsChanged 3 months agoMITView on GitHub

Generates a sprint or milestone retrospective by analyzing completed work, velocity, blockers, and patterns. Produces actionable insights for the next iteration.

69 other projects use a version of this, 9 of them edited.

Adopted by

Most recently taken up by

The file

Show its rules and text

We split this skill into the rules it gives an agent

16 rules. 0 are common, 12 are distinctive, and 4 are very specific to this project.

  • 0

    Common

    Most of the 57 edited versions we read keep these.

  • 12

    Distinctive

    This author's own choices. Worth a look.

  • 4

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Before loading any data, glob for an existing retrospective file:

    line 19
  2. Distinctive:

    If a matching file is found, present the user with:

    line 25
  3. Distinctive:

    Wait for user selection before continuing.

    line 34
  4. Distinctive:

    Read the sprint or milestone plan from the appropriate location:

    line 41
  5. Distinctive:

    If the user chooses [A], collect the data and continue to Phase 3 using what they provide.

    line 57
  6. Distinctive:

    If the user chooses [B], stop here.

    line 58
  7. Distinctive:

    Read the git log for the period covered by the sprint or milestone to understand what was actually committed and when.

    line 62
  8. Very specific:

    Read previous retrospectives (if any) from production/sprints/ or production/milestones/ to check:

    line 82
  9. Very specific:

    Ask: "May I write this to production/sprints/sprint-[N]-retrospective.md?" (or the milestone path if applicable)

    line 190
  10. Distinctive:

    If yes, write the file, creating the directory if needed.

    line 192
  11. Distinctive:

    If no, stop here. Verdict: BLOCKED — user declined write.

    line 194
  12. Very specific:

    Run /sprint-plan to incorporate the action items and velocity data into the next sprint.

    line 200
  13. Very specific:

    If this was a milestone retrospective, run /gate-check to formally assess readiness for the next phase.

    line 201
  14. Distinctive:

    Every action item must have an owner and a deadline.

    line 208
  15. Distinctive:

    Check whether previous action items were completed.

    line 209
  16. Distinctive:

    If this is a milestone retrospective, also evaluate whether the milestone goals were achieved and what that means for the overall project …

    line 210

“Common” is measured: kept by at least 6 in 10 of the 57 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Phase 1: Parse Arguments

Determine whether this is a sprint retrospective (sprint-N) or a milestone retrospective (milestone-name).


Phase 1b: Check for Existing Retrospective

Before loading any data, glob for an existing retrospective file:

  • For sprint retrospectives: production/retrospectives/retro-[sprint-slug]-*.md (also check production/sprints/sprint-[N]-retrospective.md as an alternate location)
  • For milestone retrospectives: production/retrospectives/retro-[milestone-name]-*.md

If a matching file is found, present the user with:

An existing retrospective was found: [filename]

[A] Update existing retrospective — load it and add/revise sections
[B] Start fresh — generate a new retrospective, archiving the old one

Wait for user selection before continuing. If updating, read the existing file and carry its content forward into the generation phase, revising sections with new data.


Phase 2: Load Sprint or Milestone Data

Read the sprint or milestone plan from the appropriate location:

  • Sprint plans: production/sprints/
  • Milestone definitions: production/milestones/

If the file does not exist or is empty, output:

"No sprint data found for [sprint/milestone]. Run /sprint-status to generate sprint data first, or provide the sprint details manually."

Then use AskUserQuestion to present two options:

  • [A] Provide data manually — ask the user to paste or describe the sprint tasks, dates, and outcomes; use that as the source of truth for the retrospective.
  • [B] Stop — abort the skill. Verdict: BLOCKED — no sprint data available.

If the user chooses [A], collect the data and continue to Phase 3 using what they provide. If the user chooses [B], stop here.

Extract: planned tasks, estimated effort, owners, and goals.

Read the git log for the period covered by the sprint or milestone to understand what was actually committed and when.


Phase 3: Analyze Completion and Trends

Scan for completed and incomplete tasks by comparing the plan against actual deliverables. Check for:

  • Tasks completed as planned
  • Tasks completed but modified from the plan
  • Tasks carried over (not completed)
  • Tasks added mid-sprint (unplanned work)
  • Tasks removed or descoped

Scan the codebase for TODO/FIXME trends:

  • Count current TODO/FIXME/HACK comments
  • Compare to previous sprint counts if available (check previous retrospectives)
  • Note whether technical debt is growing or shrinking

Read previous retrospectives (if any) from production/sprints/ or production/milestones/ to check:

  • Were previous action items addressed?
  • Are the same problems recurring?
  • How has velocity trended?

Phase 4: Generate the Retrospective

## Retrospective: [Sprint N / Milestone Name]
Period: [Start Date] -- [End Date]
Generated: [Date]

### Metrics

| Metric | Planned | Actual | Delta |
|--------|---------|--------|-------|
| Tasks | [X] | [Y] | [+/- Z] |
| Completion Rate | -- | [Z%] | -- |
| Story Points / Effort Days | [X] | [Y] | [+/- Z] |
| Bugs Found | -- | [N] | -- |
| Bugs Fixed | -- | [N] | -- |
| Unplanned Tasks Added | -- | [N] | -- |
| Commits | -- | [N] | -- |

### Velocity Trend

| Sprint | Planned | Completed | Rate |
|--------|---------|-----------|------|
| [N-2] | [X] | [Y] | [Z%] |
| [N-1] | [X] | [Y] | [Z%] |
| [N] (current) | [X] | [Y] | [Z%] |

**Trend**: [Increasing / Stable / Decreasing]
[One sentence explaining the trend]

### What Went Well
- [Observation backed by specific data or examples]
- [Another positive observation]
- [Recognize specific contributions or decisions that paid off]

### What Went Poorly
- [Specific issue with measurable impact -- e.g., "Feature X took 5 days
  instead of estimated 2, blocking tasks Y and Z"]
- [Another issue with impact]
- [Do not assign blame -- focus on systemic causes]

### Blockers Encountered

| Blocker | Duration | Resolution | Prevention |
|---------|----------|------------|------------|
| [What blocked progress] | [How long] | [How it was resolved] | [How to prevent recurrence] |

### Estimation Accuracy

| Task | Estimated | Actual | Variance | Likely Cause |
|------|-----------|--------|----------|--------------|
| [Most overestimated task] | [X] | [Y] | [+Z] | [Why] |
| [Most underestimated task] | [X] | [Y] | [-Z] | [Why] |

**Overall estimation accuracy**: [X%] of tasks within +/- 20% of estimate

[Analysis: Are we consistently over- or under-estimating? For which types of
tasks? What adjustment should we apply?]

### Carryover Analysis

| Task | Original Sprint | Times Carried | Reason | Action |
|------|----------------|---------------|--------|--------|
| [Task that was not completed] | [Sprint N-X] | [N] | [Why] | [Complete / Descope / Redesign] |

### Technical Debt Status
- Current TODO count: [N] (previous: [N])
- Current FIXME count: [N] (previous: [N])
- Current HACK count: [N] (previous: [N])
- Trend: [Growing / Stable / Shrinking]
- [Note any areas of concern]

### Previous Action Items Follow-Up

| Action Item (from Sprint N-1) | Status | Notes |
|-------------------------------|--------|-------|
| [Previous action] | [Done / In Progress / Not Started] | [Context] |

### Action Items for Next Iteration

| # | Action | Owner | Priority | Deadline |
|---|--------|-------|----------|----------|
| 1 | [Specific, measurable action] | [Who] | [High/Med/Low] | [When] |
| 2 | [Another action] | [Who] | [Priority] | [When] |

### Process Improvements
- [Specific change to how we work, with expected benefit]
- [Another improvement -- keep it to 2-3 actionable items, not a wish list]

### Summary
[2-3 sentence overall assessment: Was this a good sprint/milestone? What is
the single most important thing to change going forward?]

Phase 5: Save Retrospective

Present the retrospective and top findings to the user (completion rate, velocity trend, top blocker, most important action item).

Ask: "May I write this to production/sprints/sprint-[N]-retrospective.md?" (or the milestone path if applicable)

If yes, write the file, creating the directory if needed. Verdict: COMPLETE — retrospective saved.

If no, stop here. Verdict: BLOCKED — user declined write.


Phase 6: Next Steps

  • Run /sprint-plan to incorporate the action items and velocity data into the next sprint.
  • If this was a milestone retrospective, run /gate-check to formally assess readiness for the next phase.

Guidelines

  • Be honest and specific. Vague retrospectives ("communication could be better") produce vague improvements. Use data and examples.
  • Focus on systemic issues, not individual blame.
  • Limit action items to 3-5. More than that dilutes focus.
  • Every action item must have an owner and a deadline.
  • Check whether previous action items were completed. Recurring unaddressed items are a process smell.
  • If this is a milestone retrospective, also evaluate whether the milestone goals were achieved and what that means for the overall project timeline.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.