Session retrospection using After Action Review methodology. Analyzes corrections, observations, and session activity to produce improvement recommendations. Use at end of sessions or after /memory-sync.
Session retrospection using After Action Review methodology. Analyzes corrections, observations, and session activity to produce improvement recommendations. Use at end of sessions or after /memory-sync.
triggers
["/memory-reflect"]
Memory Reflect — Session Retrospection
6-phase After Action Review (AAR) workflow for extracting actionable improvements from the current session.
Phase 1: Gather Evidence
Read the following data sources (skip any that don't exist):
primary_success — what went right
If the facets directory doesn't exist or no matching session is found, skip gracefully.
Facets data is Claude Code-specific and may not exist on all installations.
If facets data exists, also consider: friction count, satisfaction signals
If < 5 observations AND 0 corrections AND no facets friction → mark as LIGHTWEIGHT
Otherwise → use STANDARD depth
Privacy: Skip any content within ... blocks.
Skip files with private: true in YAML front matter.
Facets data does not contain file contents — no privacy filtering needed for facets.
Phase 2: Classify Scope
Recommend scope classification:
PROCESS: Improvements to how the agent works (efficiency, tool usage, workflow)
PROJECT: Improvements to the codebase, architecture, documentation, or tests
BOTH: Improvements spanning both areas
Present recommendation to user:
"Scope recommendation: [PROCESS/PROJECT/BOTH] — [brief reason]"
User can adjust. Proceed with confirmed scope.
For LIGHTWEIGHT sessions: Auto-select PROCESS scope, skip user confirmation, and produce minimal output.
Phase 3: Analyze Patterns
Group corrections by type — repeated corrections get priority
Long sequences of read operations without progress
Facets-enhanced analysis (if facets data was gathered in Phase 1):
Use friction_counts as pre-classified friction signals (more accurate than
manual observation log scanning — these are LLM-classified, not regex-matched)
Use friction_detail for narrative context on what went wrong
Map facets friction types to ConKeeper categories:
wrong_approach → efficiency, buggy_code → quality,
misunderstood_request → ux, excessive_changes → quality,
got_stuck → efficiency, premature_stop → efficiency
For any friction type not listed above, map to the closest ConKeeper category
based on the friction_detail narrative, defaulting to efficiency if unclear.
Cross-reference with existing knowledge:
Read .claude/memory/patterns.md — don't re-discover known patterns
Use /memory-search to check if similar issues were flagged in past session retros
Identify net-new insights vs. reinforcements of existing knowledge
Friction Pattern Check:
If .claude/memory/friction.md exists:
Read friction.md conventions
Check if this session triggered any known friction patterns
If yes: note "Known friction pattern triggered: [convention]. Was the convention followed? If not, consider stronger wording or more prominent placement."
If a convention was followed and friction was avoided: note as positive signal
If a recommendation would benefit from external validation, briefly verify with external sources before recommending. Skip external research for LIGHTWEIGHT sessions.
Phase 4: Generate Recommendations
For each recommendation, include:
What: Specific, actionable change (one sentence)
Why: Evidence from session — quote the correction text or observation pattern
Where: Target file or skill to update (exact path)
Present each recommendation with a number. User can approve all, selectively approve or deny in natural language. Denied items are noted as "considered but declined" in the retro file.
Route approved items to the most appropriate memory file (patterns.md, decisions/, glossary.md, product-context.md, or the retro's Improvement Backlog).