Standardmäßig ist der Prompt ausgewählt, der zuerst die Quelle prüft. Sie können zu einem direkten Befehl wechseln oder eine lokale Kopie herunterladen.
Quelldateien prüfen
Lesen Sie SKILL.md und alle von SkillsMP angezeigten Begleitdateien, bevor Sie sich für eine Installation entscheiden.
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Ein direkter Befehl überspringt den Prüf-Prompt. Prüfen Sie die Quelle, bevor Sie ihn ausführen.
Analyze evaluation patterns across completed plans, identify recurring failures, and auto-apply checklist evolution — the downstream consumer of executing-plans Phase 4 "Checklist Evolution Candidates". The user reviews post-commit via git show docs/retros/checklists/.
Recommended: run wrapped in /goal
Launch it under Claude Code's built-in /goal (v2.1.139+) — a retrospective can span multiple turns:
/goal "Claude has narrated a successful checklist-evolution commit (with commit hash) and stated the retrospective is complete" /superpowers:retrospective <plan-paths>
/goal is a user-typed outer wrapper (a skill cannot enable it for itself mid-run), and its evaluator judges only what Claude narrates in the transcript — phrase the condition against narrated output (the commit-hash line, an explicit completion statement), never filesystem state. Full semantics and condition phrasing: ../../skills/references/goal-wrapper.md.
Pre-Check (run first, in order)
A. INSUFFICIENT-POST-PLAN advisory (informational)
Read the most recent plan_completed event from docs/retros/plans-completed.jsonl. If hours_since_completion < 24h AND bash "${CLAUDE_PLUGIN_ROOT}/lib/post-plan-diff.sh" summary <completion_commit> <files...> returns total == 0, output the INSUFFICIENT-POST-PLAN reminder verbatim (see ./references/post-plan-diff.md §Pre-Check A) and proceed to Phase 0 — do NOT pause. Skip silently when completion_commit is missing.
B. Recall persistent memory (calibration priors)
CRITICAL — do this before Phase 0, do NOT skip it as setup. Persistent memory holds the human judgments the evolution-log cannot capture. Recall is a SECONDARY calibration signal — docs/retros/evolution-log.jsonl (Phase 1 step 5) stays authoritative; when they disagree, the log wins.
The MEMORY.md index hooks are ALREADY in your context (injected at session start) — read nothing from disk. Scan them now and select the ones bearing on this run: prior evolution/rejection decisions and debt trackers, harness-design principles, and working-style feedback. Carry them forward as priors into Phase 1 step 5 (calibration history), Phase 3 (suppression of weakly-justified ADDs), and Phase 4 (self-reject a proposal that contradicts a recalled prior, citing the memory entry). If no calibration-relevant hook exists, log Pre-Check B: no calibration-relevant memory and proceed. Never resolve a memory path, read a topic file, block, or ask — the index hooks carry the signal on their own.
When a recalled hook cited as evidence for an approved Phase 3 proposal proves project-specific and durable, the Phase 4 step 3.5 draft records Promoted from private assistant memory hook: <hook-name>, <date> in its ## Why section — cross-project harness-design stances are NOT promoted, and the private hook is never deleted or modified.
Phase 0: Bootstrap (run only when no checklists exist)
Before Phase 1, check whether docs/retros/checklists/ contains {mode}-v1.md for each mode (design / plan / code). Phase 0 runs per-mode independently — seed only the modes missing a v{N} file; if all three are present, log Phase 0: all checklists present, skipping seed and proceed. Full procedure (Path A vs. Path B Full History Bootstrap, exit codes, --force reset): ./references/bootstrap.md.
Phase 1: Data Collection
Resolve inputs: Parse $ARGUMENTS for plan paths. If --across-all, scan docs/plans/ for all *-plan/ directories with evaluation reports. If no argument is given, read docs/retros/plans-completed.jsonl and auto-scope to plans completed after the most recent retrospective_run event in docs/retros/evolution-log.jsonl. Complement the log via the docs index: bash "${CLAUDE_PLUGIN_ROOT}/lib/docs-index.sh" list --kind plan --status implemented scopes shipped plans; bash "${CLAUDE_PLUGIN_ROOT}/lib/docs-index.sh" list --status expired surfaces prior expirations as calibration input (read an expired plan's retro report before re-proposing anything that touches it). Also consult memory: bash "${CLAUDE_PLUGIN_ROOT}/lib/docs-index.sh" list --kind memory --status active; fold matches into Phase 2 analysis as calibration input.
Resolve evals: For each plan path, read evaluation reports (evaluation-round-*.md, evaluation-design-round-*.md, evaluation-plan-round-*.md) from the plan directory, or from a sibling *-evals/ directory when one exists.
Read checklists: Scan docs/retros/checklists/ for each mode's latest {mode}-v{N}.md (highest N).
Read reports: Read each plan's evaluation reports; extract per-item results (Item ID, Result, Evidence) and rework items.
Read evolution history (calibration input): Read docs/retros/evolution-log.jsonl if present; build a history table keyed by item_id (most recent event, timestamp, rationale). This feeds Phase 3 — do NOT re-propose an ADD for an item REMOVEd in the most recent retrospective unless the new evidence is materially different; cite the historical entry in any such proposal.
Read post-plan diff: For each plan with a completion_commit field, run bash "${CLAUDE_PLUGIN_ROOT}/lib/post-plan-diff.sh" list <completion_commit> <completion_modified_files...> and pass the classified commit list to Phase 5a (classification rules and skip conditions: ./references/post-plan-diff.md).
Minimum data check: With only 1 plan, warn that ADD proposals require 2+ plans (except the Phase 5a post-plan-diff 1-plan override); REMOVE needs 3+ reports with zero failures.
Phase 2: Pattern Analysis
Aggregate data across all plans (detailed logic: ./references/analysis-patterns.md).
Failure frequency: Count distinct plans where each checklist item FAILed. Rank by frequency descending.
Plateau tasks: Identify tasks that were REWORK across 2+ consecutive evaluation rounds in any plan; extract the root cause from rework items.
Never-failing items: Items with 0 FAILs across 10+ evaluation reports are REMOVE candidates.
Variety gaps: From executing-plans completion summaries, find batches where all items PASS but 2+ rework rounds occurred -- the checklist missed the failure mode.
Output a structured analysis report with tables for each category.
Phase 3: Evolution Proposals
Generate proposals from analysis results (format details: ./references/evolution-protocol.md).
Type
Trigger and threshold
ADD
Failure pattern in 2+ distinct plans with no covering item
REMOVE
0 failures across 3+ reports per item
MODIFY
2+ false positives (FAIL overturned in rework)
PROMOTE
Capability item pass rate >80% across 3+ successive plans
Rate limit (EVO-6): Max 3 proposals per mode per run; defer excess with evidence.
Counter monotonic growth (REMOVE is load-bearing): each run, actively scan for never-firing items and propose REMOVE — a checklist that only grows is a calibration failure, not success. The 3+ reports/item threshold is deliberately reachable (rationale and history: ./references/evolution-protocol.md §History).
Memory-file consolidation (reuses the MODIFY threshold, 2+ instances): when Phase 2 surfaces 2+ active kind=memory files covering the same concept, propose a MODIFY merging them into one surviving file. When applied in Phase 4, fold the absorbed file's content into the survivor, then run bash "${CLAUDE_PLUGIN_ROOT}/lib/docs-index.sh" set-status <absorbed-path> "expired:superseded-by-consolidation:<survivor-path>" — the collapse rule then drops the row.
Each proposal includes: type, target checklist, item ID, description, rationale with plan evidence.
Phase 4: Auto-Apply Proposals
Apply every Phase 3 proposal (regression breaks first, then by frequency). No per-proposal approval gate — EVO-6 + thresholds + post-commit git show docs/retros/checklists/ are the quality surface. proposals_rejected is reserved for self-rejection at apply time: a proposal duplicating a recent removal (Phase 1 step 5) or contradicting a recalled memory prior (Pre-Check B) without materially new evidence is logged under "Self-Rejected Proposals" with the cited entry, increments proposals_rejected, and skips the checklist row. All others advance.
Apply steps:
Pre-edit snapshot: Write current checklist content to the retrospective report under "Pre-Edit Snapshot" with rollback instructions
Create new version: Write {mode}-v{N+1}.md with all applied changes. Version increments once per run (not per proposal). Original version preserved unchanged.
Log evolution — CRITICAL: a proposal is NOT "applied" until its evolution-log row exists. Immediately after writing the new version file, append one row per applied proposal to docs/retros/evolution-log.jsonl via lib/jsonl-emit.sh with <channel>=evolution-log and event item_added | item_removed | item_modified | item_promoted — emit per-proposal, do NOT defer to the end of the run (canonical invocation: ./references/evolution-protocol.md §"Canonical Emit Invocations"). These rows feed Phase 1 step 5's re-proposal guard — a dropped item_removed row silently re-adds the just-removed item next run. The Stop hook backfill is all-or-nothing and carries no rationale; the in-skill emit is authoritative and must run.
3.5. Draft memory files for applied ADD/MODIFY proposals: for each ADD or MODIFY applied this run (post-self-rejection), draft one docs/memory/<category>_<slug>.md (convention for a structural rule, pitfall for a recurring failure mode, decision for a rejected-vs-chosen call), using the proposal's description and rationale as Fact/Why content and source: citing this run's retro report path. REMOVE and PROMOTE proposals, even if applied, do NOT trigger this step.
Verify the log — CRITICAL self-check, do NOT skip: before leaving Phase 4, count evolution-log rows whose checklist_version equals this run's version(s) and confirm the count equals proposals_approved; emit any missing rows now. This guards against a partial drop the hook's all-or-nothing backfill cannot catch.
Phase 5: Harness Health (advisory)
Surface components that may no longer earn their cost and turn post-plan corrections into checklist proposals. Everything here is advisory — it feeds Phase 3 proposals and the Phase 6 report, reviewed via the post-commit diff. Phase 5 never disables a component or mutates the harness (the automated disable-test loop was removed in v2.9.0; history: ./references/evolution-protocol.md §History).
This is the load-bearing input (provenance: ./references/evolution-protocol.md §History). For each plan's post-plan-diff (Phase 1 step 6): when feedback-classified commits (refactor/fix/style/perf on plan-modified files) cluster around a pattern no batch evaluator flagged, that is a real evaluator coverage gap. Render the corrections table (./references/post-plan-diff.md §Phase 5a) and graduate each missed pattern to a Phase 3 ADD proposal at 1-plan evidence. This catches what grep-based checks cannot: consistency, API-contract, and coverage gaps.
All tasks passing first round (no REWORK) across 3+ plans → note that per-batch evaluation may be reducible (a future Phase 3 MODIFY/REMOVE candidate, not an automatic change).
A mode's checklist all-regression and all-passing across 3+ plans → recommend a spot-check cadence.
Report notes only — never disable a component here; never-failing items belong to Phase 3 REMOVE proposals (do not duplicate).
Phase 6: Output
Write the retrospective report to docs/retros/retro-{date}-{topic}.md:
Harness Health notes (5a corrections mined into ADD proposals; 5b recommendations)
Summary: N proposals approved, M rejected, checklists updated to version X
Upsert retro report into the docs index: bash "${CLAUDE_PLUGIN_ROOT}/lib/docs-index.sh" upsert retro <retro-report-path> --status active --summary "<one-line>" (same string as the report's summary line).
CRITICAL — invalidate-after (do-not-defer, retrospective-only). For each invalidates: <path> line in the just-written retro report, run bash "${CLAUDE_PLUGIN_ROOT}/lib/docs-index.sh" set-status <path> "expired:retro-<date>:<reason>". If set-status returns exit 3 (path not tracked), log a warning and skip — do NOT upsert speculative entries just to mark them expired. CRITICAL boundary — a checklist-item REMOVE does NOT invalidate a design: a Phase 3 REMOVE evolves the checklist, not the design folder; only an explicit invalidates: <path> line triggers set-status expired: — separate channels. Expiry is retrospective-only — the other writer skills may NOT set expired:; only this step does.
Upsert drafted memory files: for each memory file drafted in Phase 4 step 3.5, run bash "${CLAUDE_PLUGIN_ROOT}/lib/docs-index.sh" upsert memory docs/memory/<path> --status active --summary "<one-line>" --category <category>.
Close the calibration loop — CRITICAL: do this before you stop, even when zero proposals were approved. Append one retrospective_run row to docs/retros/evolution-log.jsonl via the canonical emit pattern (./references/evolution-protocol.md §"Canonical Emit Invocations"), recording proposals_approved and proposals_rejected. This row is the closure marker the next run's auto-scope reads — skip it and the next retrospective silently re-analyzes these plans. The Stop hook backfills a minimal watermark if you drop this, but only your emit carries proposals_approved / proposals_rejected / plans_analyzed — write the rich row here.
