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.