Get the FREE Ultimate OpenClaw Setup Guide →

reflect-and-improve

Scanned
npx machina-cli add skill aroyburman-codes/compound-product-management/reflect-and-improve --openclaw
Files (1)
SKILL.md
5.8 KB

Reflect 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:

CategoryExample
Wrong assumptionAssumed Python 3.10 but project uses 3.8
Missing contextDidn't read package.json before running npm commands
Tool misuseUsed cat instead of Read tool
Wrong fileEdited the test file instead of the source file
Stale knowledgeUsed deprecated API method
Ordering errorRan 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:

  1. Check if a relevant topic file exists (permissions.md, errors.md, preferences.md)
  2. If yes: update existing entries, add new ones, remove outdated ones
  3. If no: create the topic file
  4. 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

  1. Less is more. A few high-quality entries beat a bloated log.
  2. Edit, don't append. Keep files clean by updating existing entries.
  3. Confirm before persisting. Save observed facts, not assumptions.
  4. Privacy first. Never persist secrets, tokens, or personal data.
  5. 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

  1. Step 1: Trigger reflect-and-improve at a natural breakpoint or after a significant task
  2. Step 2: Run through Review Checkpoint, Permission Patterns, Error Catalog, User Preference Signals, and Memory Synthesis; record findings
  3. 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

Frequently Asked Questions

Add this skill to your agents
Sponsor this space

Reach thousands of developers