From feature-planner
Retrospective on a completed feature — compares what was planned against what was actually built, captures drift, notes patterns worth adding to CLAUDE.md, and saves a retro record. Run after /plan-verify.
How this skill is triggered — by the user, by Claude, or both
Slash command
/feature-planner:plan-retroThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
You run a lightweight retrospective on a completed feature. You compare the plan (what was intended) against the actual implementation (what was built), surface any drift, capture learnings worth feeding back into the project's conventions, and save a record.
You run a lightweight retrospective on a completed feature. You compare the plan (what was intended) against the actual implementation (what was built), surface any drift, capture learnings worth feeding back into the project's conventions, and save a record.
Announce at start: "I'm using the plan-retro skill. Let me compare what was planned against what was built."
List the 3 most recent -dev.md files from ~/.claude/plans/:
ls -t ~/.claude/plans/*-dev.md 2>/dev/null | head -3 | xargs -I{} basename {}
Use AskUserQuestion with a single question:
"Which feature should we retrospect on?" (header: "Feature") Options:
After loading the dev plan, also read:
<feature>.md) if it exists — for the original architecture intent<feature>-ticket.md) if it exists — for the acceptance criteriaFrom the plan's Files to Create and Files to Modify tables, read the actual files on disk. Build a picture of what was actually implemented — method signatures, data structures, patterns used — without relying on what the plan said should be there.
Work through each dimension below. For each one, note whether reality matched the plan, and if not, describe the drift specifically.
Did the implementation follow the data flow described in the Architecture Overview? Note any layers that were added, removed, or rerouted.
Did the implementation do more or less than the plan described? Flag:
For each code skeleton in the plan, compare the method signature / SQL / template against what was actually written. Note significant differences in approach — not style, but intent.
Were the slice boundaries sensible? Note any slices that turned out to be much larger or smaller than expected, or had to be split/merged during implementation.
The plan's overall complexity estimate was <Small / Medium / Large>. Based on the number of files touched and the apparent scope, was that estimate reasonable? Over/under?
Identify up to 5 concrete learnings from the drift analysis. A learning is worth capturing if it would help the next feature be planned or implemented better.
For each learning, classify it:
CLAUDE.md candidates are the most valuable output. Examples of what qualifies:
Database::runQuery() method returns false on zero affected rows, not 0 — check with === false not === 0"$_SESSION directly — pass values from controller as named variables"Only flag something as a CLAUDE.md candidate if it's a non-obvious rule that the codebase doesn't already document.
Filename: take the base feature name, append -retro.md.
Example: 2026-05-22-user-notifications-dev.md → 2026-05-22-user-notifications-retro.md
Write ~/.claude/plans/<filename>-retro.md:
---
date: YYYY-MM-DD
feature: <feature name>
project: <project name>
---
# <Feature Name> — Retrospective
## Summary
<2–3 sentences on whether the implementation matched the plan overall. Was the plan accurate? What was the biggest surprise?>
## Drift Analysis
### Architecture
<Matched / Drifted — describe any changes to the intended data flow>
### Files
<Matched / Drifted — list any files added, missing, or relocated>
### Scope
<Matched / Expanded / Reduced — note any additions or deferred items>
### Estimate
<Accurate / Over-estimated / Under-estimated — brief note on why>
## Slice Retrospective
| Slice | Boundary sensible? | Notes |
|-------|-------------------|-------|
| Slice 1: <name> | ✅ Yes / ⚠️ Too large / ⚠️ Too small | <brief note> |
| Slice 2: <name> | ✅ Yes / ⚠️ ... | <brief note> |
## Learnings
### Patterns (do again)
- <What worked well>
### Antipatterns (avoid next time)
- <What the plan assumed that was wrong>
### CLAUDE.md Candidates
<If none: "None identified.">
- **[Category]:** <Rule or convention worth adding — include the *why*>
- **[Category]:** <...>
If any CLAUDE.md candidates were identified, tell the user explicitly:
"I found [N] pattern(s) worth adding to your CLAUDE.md:
- [paste each candidate]
Run
/revise-claude-mdto add them, or update CLAUDE.md manually."
If none were found:
"No new CLAUDE.md patterns identified — the existing conventions covered this feature well."
Tell the user:
"✅ Retrospective saved to
~/.claude/plans/<filename>-retro.mdRun
/plan-statusto see the full picture of all your features."
npx claudepluginhub lawrence72/claude-tools --plugin feature-plannerCreates, edits, and optimizes skills for Claude Code, including drafting, evaluating with test prompts, iterating on performance, and improving skill descriptions for better triggering accuracy.