reflect-and-improve
Scannednpx machina-cli add skill aroyburman-codes/compound-product-management/reflect-and-improve --openclawReflect and Improve
A self-improvement loop for Claude Code. After significant work, this skill reviews what happened — errors made, corrections received, implicit preferences — and writes confirmed learnings to persistent memory files. Future sessions start smarter.
When to Invoke
- After completing multi-file edits, project setup, or debugging sessions
- After making an error and recovering from it
- At natural session breakpoints (switching tasks, wrapping up)
- After a tool call is denied and you adjusted approach
- When explicitly requested
The Reflection Framework
Run these 6 steps in order. Skip any step with no findings.
1. Review Checkpoint
Scan recent actions for signals worth learning from.
Look for:
- Tool calls that failed or were retried
- User corrections ("no, I meant...", "not that file", "use X instead")
- Permission denials
- Approaches abandoned mid-way
- Tasks that required multiple attempts
Output format:
## Review Checkpoint — [date]
- [RETRY] Ran tests 3 times before realizing venv wasn't activated
- [CORRECTION] User said "use pnpm, not npm" — package manager preference
- [DENIED] User denied `git push` — wants to review before pushing
- [ABANDONED] Started editing wrong file, had to switch
If 0 signals found, skip to step 6.
2. Permission Patterns
Track which operations the user approved or denied.
Write to: permissions.md in the project memory directory
Format:
# Permission Patterns
Last updated: YYYY-MM-DD
## Approved
- git commit — always approved
- npm install — approved for this project
## Denied
- git push — user wants to review first
- modifying .env — never touch without asking
## Implicit
- if user asks to "set up tests", creating test files is implicitly approved
Rules:
- Only record permissions observed 2+ times OR explicitly stated
- Never persist tokens, passwords, or secrets
- Update existing entries, don't append duplicates
3. Error Catalog
Classify errors and record the fix.
Error categories:
| Category | Example |
|---|---|
| Wrong assumption | Assumed Python 3.10 but project uses 3.8 |
| Missing context | Didn't read package.json before running npm commands |
| Tool misuse | Used cat instead of Read tool |
| Wrong file | Edited the test file instead of the source file |
| Stale knowledge | Used deprecated API method |
| Ordering error | Ran tests before installing dependencies |
Write to: errors.md in the project memory directory
Format:
# Error Catalog
Last updated: YYYY-MM-DD
## [date] Wrong assumption — Python version
- What happened: Used match/case syntax, but project requires Python 3.8
- Root cause: Didn't check pyproject.toml before writing code
- Prevention: Before writing Python code, check version requirements
Rules:
- Only log errors likely to recur
- Include the prevention step — that's the value
- After 30 days with no recurrence, consider archiving
4. User Preference Signals
Capture implicit preferences revealed through behavior and corrections.
Signal types:
- Coding style: tabs vs spaces, quotes, naming conventions
- Communication style: prefers short answers, likes/dislikes emojis
- Tool choices: package manager, test framework, linter
- Workflow patterns: commits frequently vs batches, reviews diffs vs trusts agent
Write to: preferences.md in the project memory directory
Rules:
- Only record preferences confirmed by 2+ instances or explicit statement
- Don't duplicate what's already in CLAUDE.md or project config
- Project config wins over inferred preferences
5. Memory Synthesis
Write confirmed learnings to persistent memory files.
What qualifies:
- Pattern observed 2+ times this session
- Explicit user instruction ("always do X", "never do Y")
- Error with a clear prevention rule
- Stable permission pattern
What doesn't qualify:
- Speculation or single observations
- Anything already in project docs
- Session-specific context
- Sensitive data
Process:
- Check if a relevant topic file exists (permissions.md, errors.md, preferences.md)
- If yes: update existing entries, add new ones, remove outdated ones
- If no: create the topic file
- Update MEMORY.md if it needs a link to a new topic file (keep under 200 lines)
6. Friction Audit
Identify moments where the experience could be smoother.
Look for:
- User had to repeat themselves
- User had to correct a misunderstanding
- User provided context that should have been known
- A task took multiple rounds when one would suffice
Output format:
## Friction Audit — [date]
- User corrected package manager twice -> saved to preferences.md
- Had to re-read config file I should have cached -> read it first next time
For each friction point, identify if there's a systemic fix and apply it.
Memory File Hygiene
- Every entry gets a "last updated" date
- During reflection, flag entries older than 90 days for review
- If a preference contradicts recent behavior, update or remove it
- Each topic file: aim for under 100 lines
- MEMORY.md: must stay under 200 lines
- Archive old entries when files grow too large
Key Principles
- Less is more. A few high-quality entries beat a bloated log.
- Edit, don't append. Keep files clean by updating existing entries.
- Confirm before persisting. Save observed facts, not assumptions.
- Privacy first. Never persist secrets, tokens, or personal data.
- Respect existing docs. Don't duplicate CLAUDE.md or project config.
Source
git clone https://github.com/aroyburman-codes/compound-product-management/blob/main/skills/reflect-and-improve/SKILL.mdView on GitHub Overview
Reflect-and-improve is a self-improvement loop that reviews significant work, errors, and implicit preferences. It synthesizes learnings and writes them to persistent memory files so future sessions start smarter and repeated mistakes are reduced. By capturing corrections and patterns, it reduces user friction over time.
How This Skill Works
It follows a six-step reflection framework: Review Checkpoint, Permission Patterns, Error Catalog, User Preference Signals, Memory Synthesis, and a final recap. Each step surfaces findings from the current session, writes them to dedicated memory files (permissions.md, errors.md, preferences.md), and ends with a memory synthesis that informs future behavior.
When to Use It
- After completing multi-file edits, project setup, or debugging sessions
- After making an error and recovering from it
- At natural session breakpoints (switching tasks, wrapping up)
- After a tool call is denied and you adjusted approach
- When explicitly requested
Quick Start
- Step 1: Trigger reflect-and-improve at a natural breakpoint or after a significant task
- Step 2: Run through Review Checkpoint, Permission Patterns, Error Catalog, User Preference Signals, and Memory Synthesis; record findings
- Step 3: Save learnings to memory files and review the synthesized summary for next session
Best Practices
- Log only signals that have been observed 2+ times or explicitly stated by the user
- Write to project memory files (permissions.md, errors.md, preferences.md) to persist learnings
- Skip steps with no findings to keep reports concise and actionable
- Format outputs consistently with timestamps and clear categories
- Review and update memory templates regularly to keep learnings fresh
Example Use Cases
- Completed a multi-file refactor and recorded retry signals and clarifications to permissions
- Recovered from a failing test by logging the exact correction and root cause in errors.md
- Wrapped up a session after finishing a major feature and stored key preferences for future tasks
- Encountered a denied tool call, recorded the alternative approach, and updated patterns
- Incorporated user feedback to prefer a specific package manager (pnpm) over npm