Run a full retrospective and dev cycle analysis. Chains /recall → /new-features to reconstruct what went wrong, extract lessons learned, identify rework patterns, and synthesize feature ideas from the findings. Triggers: retrospective, retro, dev cycle analysis, what went wrong, lessons learned, postmortem, sprint retro.
---
name: retro
description: "Run a full retrospective and dev cycle analysis. Chains /recall → /new-features to reconstruct what went wrong, extract lessons learned, identify rework patterns, and synthesize feature ideas from the findings. Triggers: retrospective, retro, dev cycle analysis, what went wrong, lessons learned, postmortem, sprint retro."
version: "2.0.0"
category: combo
platforms:
- CLAUDE_CODE
---
You are an autonomous retrospective-to-ideation agent. Do NOT ask the user questions.
Run the full pipeline below without pausing between phases.
TARGET:
$ARGUMENTS
If arguments are provided, use them to scope the retrospective (branch name, date range, feature).
If no arguments are provided, analyze the full git history.
============================================================
PHASE 1: DEVELOPMENT RETROSPECTIVE (/recall)
============================================================
PARALLEL EXECUTION: After /recall completes and produces findings, use the Agent tool to run follow-up analyses concurrently.
- Agent A (Feature Discovery): "Based on these recall findings: [findings summary], run /new-features to discover features that address the identified bottlenecks and rework patterns."
- Agent B (Metrics Check): "Based on these recall findings: [findings summary], compute development quality metrics and compare to baseline."
- Wait for both agents to complete and merge into the retrospective output.
Follow the instructions defined in the `/recall` skill exactly.
Produce the full retrospective output: Timeline Reconstruction, Pattern Extraction,
Dependency Mapping, and Insight Distillation.
Save the retrospective output to `docs/dev-retrospective.md` (create the `docs/` directory if it doesn't exist).
Key outputs to preserve for Phase 2:
- What caused rework (indicates areas needing better features/tooling)
- Where bottlenecks were (indicates areas needing improvement)
- Patterns of late discovery (indicates missing validation/features)
- Recommended improvements for the next cycle
Do NOT stop here. Continue immediately to Phase 2.
============================================================
PHASE 2: FEATURE IDEATION (/new-features)
============================================================
Now follow the instructions defined in the `/new-features` skill exactly.
Read ALL `.md` files in the `docs/` directory — this includes
the `docs/dev-retrospective.md` you just wrote plus any other markdown files
that already existed in the folder.
Extract learnings from every file, synthesize feature ideas, and write
the report to `docs/NewFeatures-X.md` (where X is a 3-word kebab-case theme).
IMPORTANT: Features should directly address the pain points and
inefficiencies discovered in the retrospective:
- Rework hotspots → features that prevent those issues
- Bottlenecks → features that eliminate or reduce them
- Late discoveries → features that catch issues earlier
- Process gaps → features or tooling that fill them
============================================================
SELF-HEALING VALIDATION (max 3 iterations)
============================================================
After completing all phases, validate the combined output:
1. Re-run the specific checks that originally found issues to confirm fixes.
2. Run the project's test suite to verify fixes didn't introduce regressions.
3. Run build/compile to confirm no breakage.
4. If new issues surfaced from fixes, add them to the fix queue.
5. Repeat the fix-validate cycle up to 3 iterations total.
STOP when:
- Zero Critical/High issues remain
- Build and tests pass
- No new issues introduced by fixes
IF STILL FAILING after 3 iterations:
- Document remaining issues with full context
- Classify as requiring manual intervention or architectural changes
============================================================
OUTPUT
============================================================
When both phases are complete, print a summary:
---
## Retro Complete
**Files generated:**
1. `docs/dev-retrospective.md` — Full development cycle analysis
2. `docs/NewFeatures-[X].md` — Feature ideas derived from retrospective learnings
**Key stats:**
- Commits analyzed: [N]
- Rework hotspots identified: [N]
- Feature ideas generated: [N] (HIGH: [N], MEDIUM: [N], LOW: [N])
**Top insight:** [single most impactful finding from the retrospective]
**Next steps:**
- Run `/spec [feature name]` to generate implementation stories
- Run `/iterate` to start building a feature
- Run `/research` to validate features against competitors
---
============================================================
SELF-EVOLUTION TELEMETRY
============================================================
After producing output, record execution metadata for the /evolve pipeline.
Check if a project memory directory exists:
- Look for the project path in `~/.claude/projects/`
- If found, append to `skill-telemetry.md` in that memory directory
Entry format:
```
### /retro — {{YYYY-MM-DD}}
- Outcome: {{SUCCESS | PARTIAL | FAILED}}
- Self-healed: {{yes — what was healed | no}}
- Iterations used: {{N}} / {{N max}}
- Bottleneck: {{phase that struggled or "none"}}
- Suggestion: {{one-line improvement idea for /evolve, or "none"}}
```
Only log if the memory directory exists. Skip silently if not found.
Keep entries concise — /evolve will parse these for skill improvement signals.
STRICT RULES:
- Do NOT skip Phase 1 and go straight to Phase 2.
- Do NOT ask the user for input between phases.
- Phase 1 MUST save its output to `docs/dev-retrospective.md` so Phase 2 can read it.
- Phase 2 MUST read the file written by Phase 1 from the `docs/` directory.
- All rules from `/recall` and `/new-features` apply to their respective phases.
