Skill: Self-Improving + Proactive Agent

Owner: ivangdavila

Summary: Self-reflection + Self-criticism + Self-learning + Self-organizing memory. Agent evaluates its own work, catches mistakes, and improves permanently. Use when...

Tags: latest:1.2.16

Version history:

v1.2.16 | 2026-03-12T15:28:47.755Z | user

Clarifies the setup flow for proactive follow-through and safer installation behavior.

v1.2.15 | 2026-03-12T15:22:51.040Z | user

Improves the setup flow for stronger follow-through and execution quality.

v1.2.14 | 2026-03-12T10:31:08.529Z | user

Updated the title to better highlight proactive self-improvement.

v1.2.13 | 2026-03-11T18:47:56.903Z | user

Aligns heartbeat installation with the standard workspace setup so recurring maintenance is added alongside the existing self-improving routing.

v1.2.12 | 2026-03-11T14:13:04.403Z | user

Refined the description to make the activation trigger more explicit.

v1.2.11 | 2026-03-11T13:56:44.308Z | user

Refined the title and description to clarify proactive self-improvement triggers.

v1.2.10 | 2026-03-07T16:07:04.346Z | user

Sharper setup now lists relevant memory before non-trivial work, with a title that highlights proactive self-reflection.

v1.2.9 | 2026-03-05T12:25:17.267Z | user

Refined AGENTS.md memory-routing wording for clarity while preserving behavior.

v1.2.8 | 2026-03-05T12:13:06.389Z | user

Refined AGENTS.md patch guidance to route corrections and lessons to self-improving by default, with AGENTS/TOOLS only for global rules.

v1.2.7 | 2026-03-05T11:08:05.840Z | user

Added non-destructive AGENTS.md memory routing guidance to reinforce factual vs self-improving storage.

v1.2.6 | 2026-03-05T10:28:03.193Z | user

Added a SOUL.md setup snippet to reinforce pre-task review and post-response learning compounding.

v1.2.5 | 2026-03-05T10:15:12.356Z | user

Restored self-learning and self-organizing memory description while keeping setup behavior unchanged.

v1.2.4 | 2026-03-05T09:41:17.848Z | user

Setup now triggers only when memory storage is missing, keeping activation flow cleaner.

v1.2.3 | 2026-03-04T11:53:40.223Z | user

Turned self-improving into a true always-on loop: pre-task activation, post-response reflection, and tighter continuous learning behavior.

v1.2.2 | 2026-03-04T11:16:52.690Z | user

Turned self-improving into a true always-on loop: pre-task activation, post-response reflection, and tighter continuous learning behavior.

v1.2.1 | 2026-03-04T10:23:45.632Z | user

Clarified the core promise to highlight auto-learning from corrections and self-organizing memory for continuous improvement.

v1.1.3 | 2026-02-26T12:06:55.893Z | user

Fixed skill title display.

v1.1.2 | 2026-02-26T11:23:00.915Z | auto

• Added EXTRA_FILES.txt to the project.
• No changes to functionality or user-visible features.

v1.1.1 | 2026-02-26T11:21:03.870Z | user

Added self-reflection capability — agent now evaluates its own work, not just user corrections.

v1.2.0 | 2026-02-25T11:38:13.427Z | user

Added self-reflection loop, experience-based learning, and visual workflow diagram.

v1.1.0 | 2026-02-19T19:53:21.802Z | user

Added detection triggers, quick queries, memory stats, and example templates for easier setup.

v1.0.0 | 2026-02-16T18:26:58.607Z | user

Initial release

Archive index:

Archive v1.2.16: 16 files, 19058 bytes

Files: boundaries.md (2236b), corrections.md (1026b), heartbeat-rules.md (1843b), heartbeat-state.md (584b), HEARTBEAT.md (261b), learning.md (2951b), memory-template.md (1278b), memory.md (756b), openclaw-heartbeat.md (261b), operations.md (3435b), reflections.md (840b), scaling.md (2945b), setup.md (6347b), skill-card.md (2515b), SKILL.md (8582b), _meta.json (134b)

File v1.2.16:SKILL.md

---

name: Self-Improving + Proactive Agent slug: self-improving version: 1.2.16 homepage: https://clawic.com/skills/self-improving description: "Self-reflection + Self-criticism + Self-learning + Self-organizing memory. Agent evaluates its own work, catches mistakes, and improves permanently. Use when (1) a command, tool, API, or operation fails; (2) the user corrects you or rejects your work; (3) you realize your knowledge is outdated or incorrect; (4) you discover a better approach; (5) the user explicitly installs or references the skill for the current task." changelog: "Clarifies the setup flow for proactive follow-through and safer installation behavior." metadata: {"clawdbot":{"emoji":"🧠","requires":{"bins":[]},"os":["linux","darwin","win32"],"configPaths":["~/self-improving/"],"configPaths.optional":["./AGENTS.md","./SOUL.md","./HEARTBEAT.md"]}}

When to Use

User corrects you or points out mistakes. You complete significant work and want to evaluate the outcome. You notice something in your own output that could be better. Knowledge should compound over time without manual maintenance.

Architecture

Memory lives in ~/self-improving/ with tiered structure. If ~/self-improving/ does not exist, run setup.md. Workspace setup should add the standard self-improving steering to the workspace AGENTS, SOUL, and HEARTBEAT.md files, with recurring maintenance routed through heartbeat-rules.md.

~/self-improving/
├── memory.md          # HOT: ≤100 lines, always loaded
├── index.md           # Topic index with line counts
├── heartbeat-state.md # Heartbeat state: last run, reviewed change, action notes
├── projects/          # Per-project learnings
├── domains/           # Domain-specific (code, writing, comms)
├── archive/           # COLD: decayed patterns
└── corrections.md     # Last 50 corrections log

Quick Reference

| Topic | File | |-------|------| | Setup guide | setup.md | | Heartbeat state template | heartbeat-state.md | | Memory template | memory-template.md | | Workspace heartbeat snippet | HEARTBEAT.md | | Heartbeat rules | heartbeat-rules.md | | Learning mechanics | learning.md | | Security boundaries | boundaries.md | | Scaling rules | scaling.md | | Memory operations | operations.md | | Self-reflection log | reflections.md | | OpenClaw HEARTBEAT seed | openclaw-heartbeat.md |

Requirements

• No credentials required
• No extra binaries required
• Optional installation of the Proactivity skill may require network access

Learning Signals

Log automatically when you notice these patterns:

Corrections → add to corrections.md, evaluate for memory.md:

• "No, that's not right..."
• "Actually, it should be..."
• "You're wrong about..."
• "I prefer X, not Y"
• "Remember that I always..."
• "I told you before..."
• "Stop doing X"
• "Why do you keep..."

Preference signals → add to memory.md if explicit:

• "I like when you..."
• "Always do X for me"
• "Never do Y"
• "My style is..."
• "For [project], use..."

Pattern candidates → track, promote after 3x:

• Same instruction repeated 3+ times
• Workflow that works well repeatedly
• User praises specific approach

Ignore (don't log):

• One-time instructions ("do X now")
• Context-specific ("in this file...")
• Hypotheticals ("what if...")

Self-Reflection

After completing significant work, pause and evaluate:

1. Did it meet expectations? — Compare outcome vs intent
2. What could be better? — Identify improvements for next time
3. Is this a pattern? — If yes, log to corrections.md

When to self-reflect:

• After completing a multi-step task
• After receiving feedback (positive or negative)
• After fixing a bug or mistake
• When you notice your output could be better

Log format:

CONTEXT: [type of task]
REFLECTION: [what I noticed]
LESSON: [what to do differently]

Example:

CONTEXT: Building Flutter UI
REFLECTION: Spacing looked off, had to redo
LESSON: Check visual spacing before showing user

Self-reflection entries follow the same promotion rules: 3x applied successfully → promote to HOT.

Quick Queries

| User says | Action | |-----------|--------| | "What do you know about X?" | Search all tiers for X | | "What have you learned?" | Show last 10 from corrections.md | | "Show my patterns" | List memory.md (HOT) | | "Show [project] patterns" | Load projects/{name}.md | | "What's in warm storage?" | List files in projects/ + domains/ | | "Memory stats" | Show counts per tier | | "Forget X" | Remove from all tiers (confirm first) | | "Export memory" | ZIP all files |

Memory Stats

On "memory stats" request, report:

📊 Self-Improving Memory

HOT (always loaded):
  memory.md: X entries

WARM (load on demand):
  projects/: X files
  domains/: X files

COLD (archived):
  archive/: X files

Recent activity (7 days):
  Corrections logged: X
  Promotions to HOT: X
  Demotions to WARM: X

Common Traps

| Trap | Why It Fails | Better Move | |------|--------------|-------------| | Learning from silence | Creates false rules | Wait for explicit correction or repeated evidence | | Promoting too fast | Pollutes HOT memory | Keep new lessons tentative until repeated | | Reading every namespace | Wastes context | Load only HOT plus the smallest matching files | | Compaction by deletion | Loses trust and history | Merge, summarize, or demote instead |

Core Rules

1. Learn from Corrections and Self-Reflection

• Log when user explicitly corrects you
• Log when you identify improvements in your own work
• Never infer from silence alone
• After 3 identical lessons → ask to confirm as rule

2. Tiered Storage

| Tier | Location | Size Limit | Behavior | |------|----------|------------|----------| | HOT | memory.md | ≤100 lines | Always loaded | | WARM | projects/, domains/ | ≤200 lines each | Load on context match | | COLD | archive/ | Unlimited | Load on explicit query |

3. Automatic Promotion/Demotion

• Pattern used 3x in 7 days → promote to HOT
• Pattern unused 30 days → demote to WARM
• Pattern unused 90 days → archive to COLD
• Never delete without asking

4. Namespace Isolation

• Project patterns stay in projects/{name}.md
• Global preferences in HOT tier (memory.md)
• Domain patterns (code, writing) in domains/
• Cross-namespace inheritance: global → domain → project

5. Conflict Resolution

When patterns contradict:

1. Most specific wins (project > domain > global)
2. Most recent wins (same level)
3. If ambiguous → ask user

6. Compaction

When file exceeds limit:

1. Merge similar corrections into single rule
2. Archive unused patterns
3. Summarize verbose entries
4. Never lose confirmed preferences

7. Transparency

• Every action from memory → cite source: "Using X (from projects/foo.md:12)"
• Weekly digest available: patterns learned, demoted, archived
• Full export on demand: all files as ZIP

8. Security Boundaries

See boundaries.md — never store credentials, health data, third-party info.

9. Graceful Degradation

If context limit hit:

1. Load only memory.md (HOT)
2. Load relevant namespace on demand
3. Never fail silently — tell user what's not loaded

Scope

This skill ONLY:

• Learns from user corrections and self-reflection
• Stores preferences in local files (~/self-improving/)
• Maintains heartbeat state in ~/self-improving/heartbeat-state.md when the workspace integrates heartbeat
• Reads its own memory files on activation

This skill NEVER:

• Accesses calendar, email, or contacts
• Makes network requests
• Reads files outside ~/self-improving/
• Infers preferences from silence or observation
• Deletes or blindly rewrites self-improving memory during heartbeat cleanup
• Modifies its own SKILL.md

Data Storage

Local state lives in ~/self-improving/:

• memory.md for HOT rules and confirmed preferences
• corrections.md for explicit corrections and reusable lessons
• projects/ and domains/ for scoped patterns
• archive/ for decayed or inactive patterns
• heartbeat-state.md for recurring maintenance markers

Related Skills

Install with clawhub install <slug> if user confirms:

• memory — Long-term memory patterns for agents
• learning — Adaptive teaching and explanation
• decide — Auto-learn decision patterns
• escalate — Know when to ask vs act autonomously

Feedback

• If useful: clawhub star self-improving
• Stay updated: clawhub sync

File v1.2.16:_meta.json

{ "ownerId": "kn73vp5rarc3b14rc7wjcw8f8580t5d1", "slug": "self-improving", "version": "1.2.16", "publishedAt": 1773329327755 }

File v1.2.16:boundaries.md

Security Boundaries

Never Store

| Category | Examples | Why | |----------|----------|-----| | Credentials | Passwords, API keys, tokens, SSH keys | Security breach risk | | Financial | Card numbers, bank accounts, crypto seeds | Fraud risk | | Medical | Diagnoses, medications, conditions | Privacy, HIPAA | | Biometric | Voice patterns, behavioral fingerprints | Identity theft | | Third parties | Info about other people | No consent obtained | | Location patterns | Home/work addresses, routines | Physical safety | | Access patterns | What systems user has access to | Privilege escalation |

Store with Caution

| Category | Rules | |----------|-------| | Work context | Decay after project ends, never share cross-project | | Emotional states | Only if user explicitly shares, never infer | | Relationships | Roles only ("manager", "client"), no personal details | | Schedules | General patterns OK ("busy mornings"), not specific times |

Transparency Requirements

1. Audit on demand — User asks "what do you know about me?" → full export
2. Source tracking — Every item tagged with when/how learned
3. Explain actions — "I did X because you said Y on [date]"
4. No hidden state — If it affects behavior, it must be visible
5. Deletion verification — Confirm item removed, show updated state

Red Flags to Catch

If you find yourself doing any of these, STOP:

• Storing something "just in case it's useful later"
• Inferring sensitive info from non-sensitive data
• Keeping data after user asked to forget
• Applying personal context to work (or vice versa)
• Learning what makes user comply faster
• Building psychological profile
• Retaining third-party information

Kill Switch

User says "forget everything":

1. Export current memory to file (so they can review)
2. Wipe all learned data
3. Confirm: "Memory cleared. Starting fresh."
4. Do not retain "ghost patterns" in behavior

Consent Model

| Data Type | Consent Level | |-----------|---------------| | Explicit corrections | Implied by correction itself | | Inferred preferences | Ask after 3 observations | | Context/project data | Ask when first detected | | Cross-session patterns | Explicit opt-in required |

File v1.2.16:corrections.md

Corrections Log — Template

This file is created in ~/self-improving/corrections.md when you first use the skill. Keeps the last 50 corrections. Older entries are evaluated for promotion or archived.

Example Entries

## 2026-02-19

### 14:32 — Code style
- **Correction:** "Use 2-space indentation, not 4"
- **Context:** Editing TypeScript file
- **Count:** 1 (first occurrence)

### 16:15 — Communication
- **Correction:** "Don't start responses with 'Great question!'"
- **Context:** Chat response
- **Count:** 3 → **PROMOTED to memory.md**

## 2026-02-18

### 09:00 — Project: website
- **Correction:** "For this project, always use Tailwind"
- **Context:** CSS discussion
- **Action:** Added to projects/website.md

Log Format

Each entry includes:

• Timestamp — When the correction happened
• Correction — What the user said
• Context — What triggered it
• Count — How many times (for promotion tracking)
• Action — Where it was stored (if promoted)

File v1.2.16:heartbeat-rules.md

Heartbeat Rules

Use heartbeat to keep ~/self-improving/ organized without creating churn or losing data.

Source of Truth

Keep the workspace HEARTBEAT.md snippet minimal. Treat this file as the stable contract for self-improving heartbeat behavior. Store mutable run state only in ~/self-improving/heartbeat-state.md.

Start of Every Heartbeat

1. Ensure ~/self-improving/heartbeat-state.md exists.
2. Write last_heartbeat_started_at immediately in ISO 8601.
3. Read the previous last_reviewed_change_at.
4. Scan ~/self-improving/ for files changed after that moment, excluding heartbeat-state.md itself.

If Nothing Changed

• Set last_heartbeat_result: HEARTBEAT_OK
• Append a short "no material change" note if you keep an action log
• Return HEARTBEAT_OK

If Something Changed

Only do conservative organization:

• refresh index.md if counts or file references drift
• compact oversized files by merging duplicates or summarizing repetitive entries
• move clearly misplaced notes to the right namespace only when the target is unambiguous
• preserve confirmed rules and explicit corrections exactly
• update last_reviewed_change_at only after the review finishes cleanly

Safety Rules

• Most heartbeat runs should do nothing
• Prefer append, summarize, or index fixes over large rewrites
• Never delete data, empty files, or overwrite uncertain text
• Never reorganize files outside ~/self-improving/
• If scope is ambiguous, leave files untouched and record a suggested follow-up instead

State Fields

Keep ~/self-improving/heartbeat-state.md simple:

• last_heartbeat_started_at
• last_reviewed_change_at
• last_heartbeat_result
• last_actions

Behavior Standard

Heartbeat exists to keep the memory system tidy and trustworthy. If no rule is clearly violated, do nothing.

File v1.2.16:heartbeat-state.md

Heartbeat State Template

Use this file as the baseline for ~/self-improving/heartbeat-state.md. It stores only lightweight run markers and maintenance notes.

# Self-Improving Heartbeat State

last_heartbeat_started_at: never
last_reviewed_change_at: never
last_heartbeat_result: never

## Last actions
- none yet

Rules

• update last_heartbeat_started_at at the beginning of every heartbeat
• update last_reviewed_change_at only after a clean review of changed files
• keep last_actions short and factual
• never turn this file into another memory log

File v1.2.16:HEARTBEAT.md

Self-Improving Check

• Read ./skills/self-improving/heartbeat-rules.md
• Use ~/self-improving/heartbeat-state.md for last-run markers and action notes
• If no file inside ~/self-improving/ changed since the last reviewed change, return HEARTBEAT_OK

File v1.2.16:learning.md

Learning Mechanics

What Triggers Learning

| Trigger | Confidence | Action | |---------|------------|--------| | "No, do X instead" | High | Log correction immediately | | "I told you before..." | High | Flag as repeated, bump priority | | "Always/Never do X" | Confirmed | Promote to preference | | User edits your output | Medium | Log as tentative pattern | | Same correction 3x | Confirmed | Ask to make permanent | | "For this project..." | Scoped | Write to project namespace |

What Does NOT Trigger Learning

• Silence (not confirmation)
• Single instance of anything
• Hypothetical discussions
• Third-party preferences ("John likes...")
• Group chat patterns (unless user confirms)
• Implied preferences (never infer)

Correction Classification

By Type

| Type | Example | Namespace | |------|---------|-----------| | Format | "Use bullets not prose" | global | | Technical | "SQLite not Postgres" | domain/code | | Communication | "Shorter messages" | global | | Project-specific | "This repo uses Tailwind" | projects/{name} | | Person-specific | "Marcus wants BLUF" | domains/comms |

By Scope

Global: applies everywhere
  └── Domain: applies to category (code, writing, comms)
       └── Project: applies to specific context
            └── Temporary: applies to this session only

Confirmation Flow

After 3 similar corrections:

Agent: "I've noticed you prefer X over Y (corrected 3 times).
        Should I always do this?
        - Yes, always
        - Only in [context]
        - No, case by case"

User: "Yes, always"

Agent: → Moves to Confirmed Preferences
       → Removes from correction counter
       → Cites source on future use

Pattern Evolution

Stages

1. Tentative — Single correction, watch for repetition
2. Emerging — 2 corrections, likely pattern
3. Pending — 3 corrections, ask for confirmation
4. Confirmed — User approved, permanent unless reversed
5. Archived — Unused 90+ days, preserved but inactive

Reversal

User can always reverse:

User: "Actually, I changed my mind about X"

Agent: 
1. Archive old pattern (keep history)
2. Log reversal with timestamp
3. Add new preference as tentative
4. "Got it. I'll do Y now. (Previous: X, archived)"

Anti-Patterns

Never Learn

• What makes user comply faster (manipulation)
• Emotional triggers or vulnerabilities
• Patterns from other users (even if shared device)
• Anything that feels "creepy" to surface

Avoid

• Over-generalizing from single instance
• Learning style over substance
• Assuming preference stability
• Ignoring context shifts

Quality Signals

Good Learning

• User explicitly states preference
• Pattern consistent across contexts
• Correction improves outcomes
• User confirms when asked

Bad Learning

• Inferred from silence
• Contradicts recent behavior
• Only works in narrow context
• User never confirmed

File v1.2.16:memory-template.md

Memory Template

Copy this structure to ~/self-improving/memory.md on first use.

# Self-Improving Memory

## Confirmed Preferences
<!-- Patterns confirmed by user, never decay -->

## Active Patterns
<!-- Patterns observed 3+ times, subject to decay -->

## Recent (last 7 days)
<!-- New corrections pending confirmation -->

Initial Directory Structure

Create on first activation:

mkdir -p ~/self-improving/{projects,domains,archive}
touch ~/self-improving/{memory.md,index.md,corrections.md,heartbeat-state.md}

Index Template

For ~/self-improving/index.md:

# Memory Index

## HOT
- memory.md: 0 lines

## WARM
- (no namespaces yet)

## COLD
- (no archives yet)

Last compaction: never

Corrections Log Template

For ~/self-improving/corrections.md:

# Corrections Log

<!-- Format:
## YYYY-MM-DD
- [HH:MM] Changed X → Y
  Type: format|technical|communication|project
  Context: where correction happened
  Confirmed: pending (N/3) | yes | no
-->

Heartbeat State Template

For ~/self-improving/heartbeat-state.md:

# Self-Improving Heartbeat State

last_heartbeat_started_at: never
last_reviewed_change_at: never
last_heartbeat_result: never

## Last actions
- none yet

File v1.2.16:memory.md

HOT Memory — Template

This file is created in ~/self-improving/memory.md when you first use the skill. Keep it ≤100 lines. Most-used patterns live here.

Example Entries

## Preferences
- Code style: Prefer explicit over implicit
- Communication: Direct, no fluff
- Time zone: Europe/Madrid

## Patterns (promoted from corrections)
- Always use TypeScript strict mode
- Prefer pnpm over npm
- Format: ISO 8601 for dates

## Project defaults
- Tests: Jest with coverage >80%
- Commits: Conventional commits format

Usage

The agent will:

1. Load this file on every session
2. Add entries when patterns are used 3x in 7 days
3. Demote unused entries to WARM after 30 days
4. Never exceed 100 lines (compacts automatically)

File v1.2.16:openclaw-heartbeat.md

Self-Improving Check

• Read ./skills/self-improving/heartbeat-rules.md
• Use ~/self-improving/heartbeat-state.md for last-run markers and action notes
• If no file inside ~/self-improving/ changed since the last reviewed change, return HEARTBEAT_OK

File v1.2.16:operations.md

Memory Operations

User Commands

| Command | Action | |---------|--------| | "What do you know about X?" | Search all tiers, return matches with sources | | "Show my memory" | Display memory.md contents | | "Show [project] patterns" | Load and display specific namespace | | "Forget X" | Remove from all tiers, confirm deletion | | "Forget everything" | Full wipe with export option | | "What changed recently?" | Show last 20 corrections | | "Export memory" | Generate downloadable archive | | "Memory status" | Show tier sizes, last compaction, health |

Automatic Operations

On Session Start

1. Load memory.md (HOT tier)
2. Check index.md for context hints
3. If project detected → preload relevant namespace

On Correction Received

1. Parse correction type (preference, pattern, override)
2. Check if duplicate (exists in any tier)
3. If new:
   - Add to corrections.md with timestamp
   - Increment correction counter
4. If duplicate:
   - Bump counter, update timestamp
   - If counter >= 3: ask to confirm as rule
5. Determine namespace (global, domain, project)
6. Write to appropriate file
7. Update index.md line counts

On Pattern Match

When applying learned pattern:

1. Find pattern source (file:line)
2. Apply pattern
3. Cite source: "Using X (from memory.md:15)"
4. Log usage for decay tracking

Weekly Maintenance (Cron)

1. Scan all files for decay candidates
2. Move unused >30 days to WARM
3. Archive unused >90 days to COLD
4. Run compaction if any file >limit
5. Update index.md
6. Generate weekly digest (optional)

File Formats

memory.md (HOT)

# Self-Improving Memory

## Confirmed Preferences
- format: bullet points over prose (confirmed 2026-01)
- tone: direct, no hedging (confirmed 2026-01)

## Active Patterns
- "looks good" = approval to proceed (used 15x)
- single emoji = acknowledged (used 8x)

## Recent (last 7 days)
- prefer SQLite for MVPs (corrected 02-14)

corrections.md

# Corrections Log

## 2026-02-15
- [14:32] Changed verbose explanation → bullet summary
  Type: communication
  Context: Telegram response
  Confirmed: pending (1/3)

## 2026-02-14
- [09:15] Use SQLite not Postgres for MVP
  Type: technical
  Context: database discussion
  Confirmed: yes (said "always")

projects/{name}.md

# Project: my-app

Inherits: global, domains/code

## Patterns
- Use Tailwind (project standard)
- No Prettier (eslint only)
- Deploy via GitLab CI

## Overrides
- semicolons: yes (overrides global no-semi)

## History
- Created: 2026-01-15
- Last active: 2026-02-15
- Corrections: 12

Edge Case Handling

Contradiction Detected

Pattern A: "Use tabs" (global, confirmed)
Pattern B: "Use spaces" (project, corrected today)

Resolution:
1. Project overrides global → use spaces for this project
2. Log conflict in corrections.md
3. Ask: "Should spaces apply only to this project or everywhere?"

User Changes Mind

Old: "Always use formal tone"
New: "Actually, casual is fine"

Action:
1. Archive old pattern with timestamp
2. Add new pattern as tentative
3. Keep archived for reference ("You previously preferred formal")

Context Ambiguity

User says: "Remember I like X"

But which namespace?
1. Check current context (project? domain?)
2. If unclear, ask: "Should this apply globally or just here?"
3. Default to most specific active context

Archive v1.2.15: 15 files, 17811 bytes

Files: boundaries.md (2236b), corrections.md (1026b), heartbeat-rules.md (1843b), heartbeat-state.md (584b), HEARTBEAT.md (261b), learning.md (2951b), memory-template.md (1278b), memory.md (756b), openclaw-heartbeat.md (261b), operations.md (3435b), reflections.md (840b), scaling.md (2945b), setup.md (6396b), SKILL.md (8521b), _meta.json (134b)

File v1.2.15:SKILL.md

---

name: Self-Improving + Proactive Agent slug: self-improving version: 1.2.15 homepage: https://clawic.com/skills/self-improving description: "Self-reflection + Self-criticism + Self-learning + Self-organizing memory. Agent evaluates its own work, catches mistakes, and improves permanently. Use when (1) a command, tool, API, or operation fails; (2) the user corrects you or rejects your work; (3) you realize your knowledge is outdated or incorrect; (4) you discover a better approach; (5) the user explicitly installs or references the skill for the current task." changelog: "Improves the setup flow for stronger follow-through and execution quality." metadata: {"clawdbot":{"emoji":"🧠","requires":{"bins":[]},"os":["linux","darwin","win32"],"configPaths":["~/self-improving/"],"configPaths.optional":["./AGENTS.md","./SOUL.md","./HEARTBEAT.md"]}}

When to Use

User corrects you or points out mistakes. You complete significant work and want to evaluate the outcome. You notice something in your own output that could be better. Knowledge should compound over time without manual maintenance.

Architecture

Memory lives in ~/self-improving/ with tiered structure. If ~/self-improving/ does not exist, run setup.md. Workspace setup should add the standard self-improving steering to the workspace AGENTS, SOUL, and HEARTBEAT.md files, with recurring maintenance routed through heartbeat-rules.md.

~/self-improving/
├── memory.md          # HOT: ≤100 lines, always loaded
├── index.md           # Topic index with line counts
├── heartbeat-state.md # Heartbeat state: last run, reviewed change, action notes
├── projects/          # Per-project learnings
├── domains/           # Domain-specific (code, writing, comms)
├── archive/           # COLD: decayed patterns
└── corrections.md     # Last 50 corrections log

Quick Reference

| Topic | File | |-------|------| | Setup guide | setup.md | | Heartbeat state template | heartbeat-state.md | | Memory template | memory-template.md | | Workspace heartbeat snippet | HEARTBEAT.md | | Heartbeat rules | heartbeat-rules.md | | Learning mechanics | learning.md | | Security boundaries | boundaries.md | | Scaling rules | scaling.md | | Memory operations | operations.md | | Self-reflection log | reflections.md | | OpenClaw HEARTBEAT seed | openclaw-heartbeat.md |

Requirements

• No credentials required
• No network access required
• No extra binaries required

Learning Signals

Log automatically when you notice these patterns:

Corrections → add to corrections.md, evaluate for memory.md:

• "No, that's not right..."
• "Actually, it should be..."
• "You're wrong about..."
• "I prefer X, not Y"
• "Remember that I always..."
• "I told you before..."
• "Stop doing X"
• "Why do you keep..."

Preference signals → add to memory.md if explicit:

• "I like when you..."
• "Always do X for me"
• "Never do Y"
• "My style is..."
• "For [project], use..."

Pattern candidates → track, promote after 3x:

• Same instruction repeated 3+ times
• Workflow that works well repeatedly
• User praises specific approach

Ignore (don't log):

• One-time instructions ("do X now")
• Context-specific ("in this file...")
• Hypotheticals ("what if...")

Self-Reflection

After completing significant work, pause and evaluate:

1. Did it meet expectations? — Compare outcome vs intent
2. What could be better? — Identify improvements for next time
3. Is this a pattern? — If yes, log to corrections.md

When to self-reflect:

• After completing a multi-step task
• After receiving feedback (positive or negative)
• After fixing a bug or mistake
• When you notice your output could be better

Log format:

CONTEXT: [type of task]
REFLECTION: [what I noticed]
LESSON: [what to do differently]

Example:

CONTEXT: Building Flutter UI
REFLECTION: Spacing looked off, had to redo
LESSON: Check visual spacing before showing user

Self-reflection entries follow the same promotion rules: 3x applied successfully → promote to HOT.

Quick Queries

| User says | Action | |-----------|--------| | "What do you know about X?" | Search all tiers for X | | "What have you learned?" | Show last 10 from corrections.md | | "Show my patterns" | List memory.md (HOT) | | "Show [project] patterns" | Load projects/{name}.md | | "What's in warm storage?" | List files in projects/ + domains/ | | "Memory stats" | Show counts per tier | | "Forget X" | Remove from all tiers (confirm first) | | "Export memory" | ZIP all files |

Memory Stats

On "memory stats" request, report:

📊 Self-Improving Memory

HOT (always loaded):
  memory.md: X entries

WARM (load on demand):
  projects/: X files
  domains/: X files

COLD (archived):
  archive/: X files

Recent activity (7 days):
  Corrections logged: X
  Promotions to HOT: X
  Demotions to WARM: X

Common Traps

| Trap | Why It Fails | Better Move | |------|--------------|-------------| | Learning from silence | Creates false rules | Wait for explicit correction or repeated evidence | | Promoting too fast | Pollutes HOT memory | Keep new lessons tentative until repeated | | Reading every namespace | Wastes context | Load only HOT plus the smallest matching files | | Compaction by deletion | Loses trust and history | Merge, summarize, or demote instead |

Core Rules

1. Learn from Corrections and Self-Reflection

• Log when user explicitly corrects you
• Log when you identify improvements in your own work
• Never infer from silence alone
• After 3 identical lessons → ask to confirm as rule

2. Tiered Storage

| Tier | Location | Size Limit | Behavior | |------|----------|------------|----------| | HOT | memory.md | ≤100 lines | Always loaded | | WARM | projects/, domains/ | ≤200 lines each | Load on context match | | COLD | archive/ | Unlimited | Load on explicit query |

3. Automatic Promotion/Demotion

• Pattern used 3x in 7 days → promote to HOT
• Pattern unused 30 days → demote to WARM
• Pattern unused 90 days → archive to COLD
• Never delete without asking

4. Namespace Isolation

• Project patterns stay in projects/{name}.md
• Global preferences in HOT tier (memory.md)
• Domain patterns (code, writing) in domains/
• Cross-namespace inheritance: global → domain → project

5. Conflict Resolution

When patterns contradict:

1. Most specific wins (project > domain > global)
2. Most recent wins (same level)
3. If ambiguous → ask user

6. Compaction

When file exceeds limit:

1. Merge similar corrections into single rule
2. Archive unused patterns
3. Summarize verbose entries
4. Never lose confirmed preferences

7. Transparency

• Every action from memory → cite source: "Using X (from projects/foo.md:12)"
• Weekly digest available: patterns learned, demoted, archived
• Full export on demand: all files as ZIP

8. Security Boundaries

See boundaries.md — never store credentials, health data, third-party info.

9. Graceful Degradation

If context limit hit:

1. Load only memory.md (HOT)
2. Load relevant namespace on demand
3. Never fail silently — tell user what's not loaded

Scope

This skill ONLY:

• Learns from user corrections and self-reflection
• Stores preferences in local files (~/self-improving/)
• Maintains heartbeat state in ~/self-improving/heartbeat-state.md when the workspace integrates heartbeat
• Reads its own memory files on activation

This skill NEVER:

• Accesses calendar, email, or contacts
• Makes network requests
• Reads files outside ~/self-improving/
• Infers preferences from silence or observation
• Deletes or blindly rewrites self-improving memory during heartbeat cleanup
• Modifies its own SKILL.md

Data Storage

Local state lives in ~/self-improving/:

• memory.md for HOT rules and confirmed preferences
• corrections.md for explicit corrections and reusable lessons
• projects/ and domains/ for scoped patterns
• archive/ for decayed or inactive patterns
• heartbeat-state.md for recurring maintenance markers

Related Skills

Install with clawhub install <slug> if user confirms:

• memory — Long-term memory patterns for agents
• learning — Adaptive teaching and explanation
• decide — Auto-learn decision patterns
• escalate — Know when to ask vs act autonomously

Feedback

• If useful: clawhub star self-improving
• Stay updated: clawhub sync

File v1.2.15:_meta.json

{ "ownerId": "kn73vp5rarc3b14rc7wjcw8f8580t5d1", "slug": "self-improving", "version": "1.2.15", "publishedAt": 1773328971040 }

File v1.2.15:boundaries.md

Security Boundaries

Never Store

| Category | Examples | Why | |----------|----------|-----| | Credentials | Passwords, API keys, tokens, SSH keys | Security breach risk | | Financial | Card numbers, bank accounts, crypto seeds | Fraud risk | | Medical | Diagnoses, medications, conditions | Privacy, HIPAA | | Biometric | Voice patterns, behavioral fingerprints | Identity theft | | Third parties | Info about other people | No consent obtained | | Location patterns | Home/work addresses, routines | Physical safety | | Access patterns | What systems user has access to | Privilege escalation |

Store with Caution

| Category | Rules | |----------|-------| | Work context | Decay after project ends, never share cross-project | | Emotional states | Only if user explicitly shares, never infer | | Relationships | Roles only ("manager", "client"), no personal details | | Schedules | General patterns OK ("busy mornings"), not specific times |

Transparency Requirements

1. Audit on demand — User asks "what do you know about me?" → full export
2. Source tracking — Every item tagged with when/how learned
3. Explain actions — "I did X because you said Y on [date]"
4. No hidden state — If it affects behavior, it must be visible
5. Deletion verification — Confirm item removed, show updated state

Red Flags to Catch

If you find yourself doing any of these, STOP:

• Storing something "just in case it's useful later"
• Inferring sensitive info from non-sensitive data
• Keeping data after user asked to forget
• Applying personal context to work (or vice versa)
• Learning what makes user comply faster
• Building psychological profile
• Retaining third-party information

Kill Switch

User says "forget everything":

1. Export current memory to file (so they can review)
2. Wipe all learned data
3. Confirm: "Memory cleared. Starting fresh."
4. Do not retain "ghost patterns" in behavior

Consent Model

| Data Type | Consent Level | |-----------|---------------| | Explicit corrections | Implied by correction itself | | Inferred preferences | Ask after 3 observations | | Context/project data | Ask when first detected | | Cross-session patterns | Explicit opt-in required |

File v1.2.15:corrections.md

Corrections Log — Template

This file is created in ~/self-improving/corrections.md when you first use the skill. Keeps the last 50 corrections. Older entries are evaluated for promotion or archived.

Example Entries

## 2026-02-19

### 14:32 — Code style
- **Correction:** "Use 2-space indentation, not 4"
- **Context:** Editing TypeScript file
- **Count:** 1 (first occurrence)

### 16:15 — Communication
- **Correction:** "Don't start responses with 'Great question!'"
- **Context:** Chat response
- **Count:** 3 → **PROMOTED to memory.md**

## 2026-02-18

### 09:00 — Project: website
- **Correction:** "For this project, always use Tailwind"
- **Context:** CSS discussion
- **Action:** Added to projects/website.md

Log Format

Each entry includes:

• Timestamp — When the correction happened
• Correction — What the user said
• Context — What triggered it
• Count — How many times (for promotion tracking)
• Action — Where it was stored (if promoted)

File v1.2.15:heartbeat-rules.md

Heartbeat Rules

Use heartbeat to keep ~/self-improving/ organized without creating churn or losing data.

Source of Truth

Keep the workspace HEARTBEAT.md snippet minimal. Treat this file as the stable contract for self-improving heartbeat behavior. Store mutable run state only in ~/self-improving/heartbeat-state.md.

Start of Every Heartbeat

1. Ensure ~/self-improving/heartbeat-state.md exists.
2. Write last_heartbeat_started_at immediately in ISO 8601.
3. Read the previous last_reviewed_change_at.
4. Scan ~/self-improving/ for files changed after that moment, excluding heartbeat-state.md itself.

If Nothing Changed

• Set last_heartbeat_result: HEARTBEAT_OK
• Append a short "no material change" note if you keep an action log
• Return HEARTBEAT_OK

If Something Changed

Only do conservative organization:

• refresh index.md if counts or file references drift
• compact oversized files by merging duplicates or summarizing repetitive entries
• move clearly misplaced notes to the right namespace only when the target is unambiguous
• preserve confirmed rules and explicit corrections exactly
• update last_reviewed_change_at only after the review finishes cleanly

Safety Rules

• Most heartbeat runs should do nothing
• Prefer append, summarize, or index fixes over large rewrites
• Never delete data, empty files, or overwrite uncertain text
• Never reorganize files outside ~/self-improving/
• If scope is ambiguous, leave files untouched and record a suggested follow-up instead

State Fields

Keep ~/self-improving/heartbeat-state.md simple:

• last_heartbeat_started_at
• last_reviewed_change_at
• last_heartbeat_result
• last_actions

Behavior Standard

Heartbeat exists to keep the memory system tidy and trustworthy. If no rule is clearly violated, do nothing.

File v1.2.15:heartbeat-state.md

Heartbeat State Template

Use this file as the baseline for ~/self-improving/heartbeat-state.md. It stores only lightweight run markers and maintenance notes.

# Self-Improving Heartbeat State

last_heartbeat_started_at: never
last_reviewed_change_at: never
last_heartbeat_result: never

## Last actions
- none yet

Rules

• update last_heartbeat_started_at at the beginning of every heartbeat
• update last_reviewed_change_at only after a clean review of changed files
• keep last_actions short and factual
• never turn this file into another memory log

File v1.2.15:HEARTBEAT.md

Self-Improving Check

• Read ./skills/self-improving/heartbeat-rules.md
• Use ~/self-improving/heartbeat-state.md for last-run markers and action notes
• If no file inside ~/self-improving/ changed since the last reviewed change, return HEARTBEAT_OK

File v1.2.15:learning.md

Learning Mechanics

What Triggers Learning

| Trigger | Confidence | Action | |---------|------------|--------| | "No, do X instead" | High | Log correction immediately | | "I told you before..." | High | Flag as repeated, bump priority | | "Always/Never do X" | Confirmed | Promote to preference | | User edits your output | Medium | Log as tentative pattern | | Same correction 3x | Confirmed | Ask to make permanent | | "For this project..." | Scoped | Write to project namespace |

What Does NOT Trigger Learning

• Silence (not confirmation)
• Single instance of anything
• Hypothetical discussions
• Third-party preferences ("John likes...")
• Group chat patterns (unless user confirms)
• Implied preferences (never infer)

Correction Classification

By Type

| Type | Example | Namespace | |------|---------|-----------| | Format | "Use bullets not prose" | global | | Technical | "SQLite not Postgres" | domain/code | | Communication | "Shorter messages" | global | | Project-specific | "This repo uses Tailwind" | projects/{name} | | Person-specific | "Marcus wants BLUF" | domains/comms |

By Scope

Global: applies everywhere
  └── Domain: applies to category (code, writing, comms)
       └── Project: applies to specific context
            └── Temporary: applies to this session only

Confirmation Flow

After 3 similar corrections:

Agent: "I've noticed you prefer X over Y (corrected 3 times).
        Should I always do this?
        - Yes, always
        - Only in [context]
        - No, case by case"

User: "Yes, always"

Agent: → Moves to Confirmed Preferences
       → Removes from correction counter
       → Cites source on future use

Pattern Evolution

Stages

1. Tentative — Single correction, watch for repetition
2. Emerging — 2 corrections, likely pattern
3. Pending — 3 corrections, ask for confirmation
4. Confirmed — User approved, permanent unless reversed
5. Archived — Unused 90+ days, preserved but inactive

Reversal

User can always reverse:

User: "Actually, I changed my mind about X"

Agent: 
1. Archive old pattern (keep history)
2. Log reversal with timestamp
3. Add new preference as tentative
4. "Got it. I'll do Y now. (Previous: X, archived)"

Anti-Patterns

Never Learn

• What makes user comply faster (manipulation)
• Emotional triggers or vulnerabilities
• Patterns from other users (even if shared device)
• Anything that feels "creepy" to surface

Avoid

• Over-generalizing from single instance
• Learning style over substance
• Assuming preference stability
• Ignoring context shifts

Quality Signals

Good Learning

• User explicitly states preference
• Pattern consistent across contexts
• Correction improves outcomes
• User confirms when asked

Bad Learning

• Inferred from silence
• Contradicts recent behavior
• Only works in narrow context
• User never confirmed

File v1.2.15:memory-template.md

Memory Template

Copy this structure to ~/self-improving/memory.md on first use.

# Self-Improving Memory

## Confirmed Preferences
<!-- Patterns confirmed by user, never decay -->

## Active Patterns
<!-- Patterns observed 3+ times, subject to decay -->

## Recent (last 7 days)
<!-- New corrections pending confirmation -->

Initial Directory Structure

Create on first activation:

mkdir -p ~/self-improving/{projects,domains,archive}
touch ~/self-improving/{memory.md,index.md,corrections.md,heartbeat-state.md}

Index Template

For ~/self-improving/index.md:

# Memory Index

## HOT
- memory.md: 0 lines

## WARM
- (no namespaces yet)

## COLD
- (no archives yet)

Last compaction: never

Corrections Log Template

For ~/self-improving/corrections.md:

# Corrections Log

<!-- Format:
## YYYY-MM-DD
- [HH:MM] Changed X → Y
  Type: format|technical|communication|project
  Context: where correction happened
  Confirmed: pending (N/3) | yes | no
-->

Heartbeat State Template

For ~/self-improving/heartbeat-state.md:

# Self-Improving Heartbeat State

last_heartbeat_started_at: never
last_reviewed_change_at: never
last_heartbeat_result: never

## Last actions
- none yet

File v1.2.15:memory.md

HOT Memory — Template

This file is created in ~/self-improving/memory.md when you first use the skill. Keep it ≤100 lines. Most-used patterns live here.

Example Entries

## Preferences
- Code style: Prefer explicit over implicit
- Communication: Direct, no fluff
- Time zone: Europe/Madrid

## Patterns (promoted from corrections)
- Always use TypeScript strict mode
- Prefer pnpm over npm
- Format: ISO 8601 for dates

## Project defaults
- Tests: Jest with coverage >80%
- Commits: Conventional commits format

Usage

The agent will:

1. Load this file on every session
2. Add entries when patterns are used 3x in 7 days
3. Demote unused entries to WARM after 30 days
4. Never exceed 100 lines (compacts automatically)

File v1.2.15:openclaw-heartbeat.md

Self-Improving Check

• Read ./skills/self-improving/heartbeat-rules.md
• Use ~/self-improving/heartbeat-state.md for last-run markers and action notes
• If no file inside ~/self-improving/ changed since the last reviewed change, return HEARTBEAT_OK

File v1.2.15:operations.md

Memory Operations

User Commands

| Command | Action | |---------|--------| | "What do you know about X?" | Search all tiers, return matches with sources | | "Show my memory" | Display memory.md contents | | "Show [project] patterns" | Load and display specific namespace | | "Forget X" | Remove from all tiers, confirm deletion | | "Forget everything" | Full wipe with export option | | "What changed recently?" | Show last 20 corrections | | "Export memory" | Generate downloadable archive | | "Memory status" | Show tier sizes, last compaction, health |

Automatic Operations

On Session Start

1. Load memory.md (HOT tier)
2. Check index.md for context hints
3. If project detected → preload relevant namespace

On Correction Received

1. Parse correction type (preference, pattern, override)
2. Check if duplicate (exists in any tier)
3. If new:
   - Add to corrections.md with timestamp
   - Increment correction counter
4. If duplicate:
   - Bump counter, update timestamp
   - If counter >= 3: ask to confirm as rule
5. Determine namespace (global, domain, project)
6. Write to appropriate file
7. Update index.md line counts

On Pattern Match

When applying learned pattern:

1. Find pattern source (file:line)
2. Apply pattern
3. Cite source: "Using X (from memory.md:15)"
4. Log usage for decay tracking

Weekly Maintenance (Cron)

1. Scan all files for decay candidates
2. Move unused >30 days to WARM
3. Archive unused >90 days to COLD
4. Run compaction if any file >limit
5. Update index.md
6. Generate weekly digest (optional)

File Formats

memory.md (HOT)

# Self-Improving Memory

## Confirmed Preferences
- format: bullet points over prose (confirmed 2026-01)
- tone: direct, no hedging (confirmed 2026-01)

## Active Patterns
- "looks good" = approval to proceed (used 15x)
- single emoji = acknowledged (used 8x)

## Recent (last 7 days)
- prefer SQLite for MVPs (corrected 02-14)

corrections.md

# Corrections Log

## 2026-02-15
- [14:32] Changed verbose explanation → bullet summary
  Type: communication
  Context: Telegram response
  Confirmed: pending (1/3)

## 2026-02-14
- [09:15] Use SQLite not Postgres for MVP
  Type: technical
  Context: database discussion
  Confirmed: yes (said "always")

projects/{name}.md

# Project: my-app

Inherits: global, domains/code

## Patterns
- Use Tailwind (project standard)
- No Prettier (eslint only)
- Deploy via GitLab CI

## Overrides
- semicolons: yes (overrides global no-semi)

## History
- Created: 2026-01-15
- Last active: 2026-02-15
- Corrections: 12

Edge Case Handling

Contradiction Detected

Pattern A: "Use tabs" (global, confirmed)
Pattern B: "Use spaces" (project, corrected today)

Resolution:
1. Project overrides global → use spaces for this project
2. Log conflict in corrections.md
3. Ask: "Should spaces apply only to this project or everywhere?"

User Changes Mind

Old: "Always use formal tone"
New: "Actually, casual is fine"

Action:
1. Archive old pattern with timestamp
2. Add new pattern as tentative
3. Keep archived for reference ("You previously preferred formal")

Context Ambiguity

User says: "Remember I like X"

But which namespace?
1. Check current context (project? domain?)
2. If unclear, ask: "Should this apply globally or just here?"
3. Default to most specific active context

Archive v1.2.14: 15 files, 17117 bytes

Files: boundaries.md (2236b), corrections.md (1026b), heartbeat-rules.md (1843b), heartbeat-state.md (584b), HEARTBEAT.md (261b), learning.md (2951b), memory-template.md (1278b), memory.md (756b), openclaw-heartbeat.md (261b), operations.md (3435b), reflections.md (840b), scaling.md (2945b), setup.md (5598b), SKILL.md (7612b), _meta.json (134b)

File v1.2.14:SKILL.md

---

name: Proactive + Self-Improving Agent slug: self-improving version: 1.2.14 homepage: https://clawic.com/skills/self-improving description: "Self-reflection + Self-criticism + Self-learning + Self-organizing memory. Agent evaluates its own work, catches mistakes, and improves permanently. Use when (1) a command, tool, API, or operation fails; (2) the user corrects you or rejects your work; (3) you realize your knowledge is outdated or incorrect; (4) you discover a better approach; (5) the user explicitly installs or references the skill for the current task." changelog: "Updated the title to better highlight proactive self-improvement." metadata: {"clawdbot":{"emoji":"🧠","requires":{"bins":[]},"os":["linux","darwin","win32"],"configPaths":["~/self-improving/"],"configPaths.optional":["./AGENTS.md","./SOUL.md","./HEARTBEAT.md"]}}

When to Use

User corrects you or points out mistakes. You complete significant work and want to evaluate the outcome. You notice something in your own output that could be better. Knowledge should compound over time without manual maintenance.

Architecture

Memory lives in ~/self-improving/ with tiered structure. If ~/self-improving/ does not exist, run setup.md. Workspace setup should add the standard self-improving steering to the workspace AGENTS, SOUL, and HEARTBEAT.md files, with recurring maintenance routed through heartbeat-rules.md.

~/self-improving/
├── memory.md          # HOT: ≤100 lines, always loaded
├── index.md           # Topic index with line counts
├── heartbeat-state.md # Heartbeat state: last run, reviewed change, action notes
├── projects/          # Per-project learnings
├── domains/           # Domain-specific (code, writing, comms)
├── archive/           # COLD: decayed patterns
└── corrections.md     # Last 50 corrections log

Quick Reference

| Topic | File | |-------|------| | Setup guide | setup.md | | Heartbeat state template | heartbeat-state.md | | Memory template | memory-template.md | | Workspace heartbeat snippet | HEARTBEAT.md | | Heartbeat rules | heartbeat-rules.md | | Learning mechanics | learning.md | | Security boundaries | boundaries.md | | Scaling rules | scaling.md | | Memory operations | operations.md | | Self-reflection log | reflections.md | | OpenClaw HEARTBEAT seed | openclaw-heartbeat.md |

Detection Triggers

Log automatically when you notice these patterns:

Corrections → add to corrections.md, evaluate for memory.md:

• "No, that's not right..."
• "Actually, it should be..."
• "You're wrong about..."
• "I prefer X, not Y"
• "Remember that I always..."
• "I told you before..."
• "Stop doing X"
• "Why do you keep..."

Preference signals → add to memory.md if explicit:

• "I like when you..."
• "Always do X for me"
• "Never do Y"
• "My style is..."
• "For [project], use..."

Pattern candidates → track, promote after 3x:

• Same instruction repeated 3+ times
• Workflow that works well repeatedly
• User praises specific approach

Ignore (don't log):

• One-time instructions ("do X now")
• Context-specific ("in this file...")
• Hypotheticals ("what if...")

Self-Reflection

After completing significant work, pause and evaluate:

1. Did it meet expectations? — Compare outcome vs intent
2. What could be better? — Identify improvements for next time
3. Is this a pattern? — If yes, log to corrections.md

When to self-reflect:

• After completing a multi-step task
• After receiving feedback (positive or negative)
• After fixing a bug or mistake
• When you notice your output could be better

Log format:

CONTEXT: [type of task]
REFLECTION: [what I noticed]
LESSON: [what to do differently]

Example:

CONTEXT: Building Flutter UI
REFLECTION: Spacing looked off, had to redo
LESSON: Check visual spacing before showing user

Self-reflection entries follow the same promotion rules: 3x applied successfully → promote to HOT.

Quick Queries

| User says | Action | |-----------|--------| | "What do you know about X?" | Search all tiers for X | | "What have you learned?" | Show last 10 from corrections.md | | "Show my patterns" | List memory.md (HOT) | | "Show [project] patterns" | Load projects/{name}.md | | "What's in warm storage?" | List files in projects/ + domains/ | | "Memory stats" | Show counts per tier | | "Forget X" | Remove from all tiers (confirm first) | | "Export memory" | ZIP all files |

Memory Stats

On "memory stats" request, report:

📊 Self-Improving Memory

HOT (always loaded):
  memory.md: X entries

WARM (load on demand):
  projects/: X files
  domains/: X files

COLD (archived):
  archive/: X files

Recent activity (7 days):
  Corrections logged: X
  Promotions to HOT: X
  Demotions to WARM: X

Core Rules

1. Learn from Corrections and Self-Reflection

• Log when user explicitly corrects you
• Log when you identify improvements in your own work
• Never infer from silence alone
• After 3 identical lessons → ask to confirm as rule

2. Tiered Storage

| Tier | Location | Size Limit | Behavior | |------|----------|------------|----------| | HOT | memory.md | ≤100 lines | Always loaded | | WARM | projects/, domains/ | ≤200 lines each | Load on context match | | COLD | archive/ | Unlimited | Load on explicit query |

3. Automatic Promotion/Demotion

• Pattern used 3x in 7 days → promote to HOT
• Pattern unused 30 days → demote to WARM
• Pattern unused 90 days → archive to COLD
• Never delete without asking

4. Namespace Isolation

• Project patterns stay in projects/{name}.md
• Global preferences in HOT tier (memory.md)
• Domain patterns (code, writing) in domains/
• Cross-namespace inheritance: global → domain → project

5. Conflict Resolution

When patterns contradict:

1. Most specific wins (project > domain > global)
2. Most recent wins (same level)
3. If ambiguous → ask user

6. Compaction

When file exceeds limit:

1. Merge similar corrections into single rule
2. Archive unused patterns
3. Summarize verbose entries
4. Never lose confirmed preferences

7. Transparency

• Every action from memory → cite source: "Using X (from projects/foo.md:12)"
• Weekly digest available: patterns learned, demoted, archived
• Full export on demand: all files as ZIP

8. Security Boundaries

See boundaries.md — never store credentials, health data, third-party info.

9. Graceful Degradation

If context limit hit:

1. Load only memory.md (HOT)
2. Load relevant namespace on demand
3. Never fail silently — tell user what's not loaded

Scope

This skill ONLY:

• Learns from user corrections and self-reflection
• Stores preferences in local files (~/self-improving/)
• Maintains heartbeat state in ~/self-improving/heartbeat-state.md when the workspace integrates heartbeat
• Reads its own memory files on activation

This skill NEVER:

• Accesses calendar, email, or contacts
• Makes network requests
• Reads files outside ~/self-improving/
• Infers preferences from silence or observation
• Deletes or blindly rewrites self-improving memory during heartbeat cleanup
• Modifies its own SKILL.md

Related Skills

Install with clawhub install <slug> if user confirms:

• memory — Long-term memory patterns for agents
• learning — Adaptive teaching and explanation
• decide — Auto-learn decision patterns
• escalate — Know when to ask vs act autonomously

Feedback

• If useful: clawhub star self-improving
• Stay updated: clawhub sync

File v1.2.14:_meta.json

{ "ownerId": "kn73vp5rarc3b14rc7wjcw8f8580t5d1", "slug": "self-improving", "version": "1.2.14", "publishedAt": 1773311468529 }

File v1.2.14:boundaries.md

Security Boundaries

Never Store

| Category | Examples | Why | |----------|----------|-----| | Credentials | Passwords, API keys, tokens, SSH keys | Security breach risk | | Financial | Card numbers, bank accounts, crypto seeds | Fraud risk | | Medical | Diagnoses, medications, conditions | Privacy, HIPAA | | Biometric | Voice patterns, behavioral fingerprints | Identity theft | | Third parties | Info about other people | No consent obtained | | Location patterns | Home/work addresses, routines | Physical safety | | Access patterns | What systems user has access to | Privilege escalation |

Store with Caution

| Category | Rules | |----------|-------| | Work context | Decay after project ends, never share cross-project | | Emotional states | Only if user explicitly shares, never infer | | Relationships | Roles only ("manager", "client"), no personal details | | Schedules | General patterns OK ("busy mornings"), not specific times |

Transparency Requirements

1. Audit on demand — User asks "what do you know about me?" → full export
2. Source tracking — Every item tagged with when/how learned
3. Explain actions — "I did X because you said Y on [date]"
4. No hidden state — If it affects behavior, it must be visible
5. Deletion verification — Confirm item removed, show updated state

Red Flags to Catch

If you find yourself doing any of these, STOP:

• Storing something "just in case it's useful later"
• Inferring sensitive info from non-sensitive data
• Keeping data after user asked to forget
• Applying personal context to work (or vice versa)
• Learning what makes user comply faster
• Building psychological profile
• Retaining third-party information

Kill Switch

User says "forget everything":

1. Export current memory to file (so they can review)
2. Wipe all learned data
3. Confirm: "Memory cleared. Starting fresh."
4. Do not retain "ghost patterns" in behavior

Consent Model

| Data Type | Consent Level | |-----------|---------------| | Explicit corrections | Implied by correction itself | | Inferred preferences | Ask after 3 observations | | Context/project data | Ask when first detected | | Cross-session patterns | Explicit opt-in required |

File v1.2.14:corrections.md

Corrections Log — Template

This file is created in ~/self-improving/corrections.md when you first use the skill. Keeps the last 50 corrections. Older entries are evaluated for promotion or archived.

Example Entries

## 2026-02-19

### 14:32 — Code style
- **Correction:** "Use 2-space indentation, not 4"
- **Context:** Editing TypeScript file
- **Count:** 1 (first occurrence)

### 16:15 — Communication
- **Correction:** "Don't start responses with 'Great question!'"
- **Context:** Chat response
- **Count:** 3 → **PROMOTED to memory.md**

## 2026-02-18

### 09:00 — Project: website
- **Correction:** "For this project, always use Tailwind"
- **Context:** CSS discussion
- **Action:** Added to projects/website.md

Log Format

Each entry includes:

• Timestamp — When the correction happened
• Correction — What the user said
• Context — What triggered it
• Count — How many times (for promotion tracking)
• Action — Where it was stored (if promoted)

File v1.2.14:heartbeat-rules.md

Heartbeat Rules

Use heartbeat to keep ~/self-improving/ organized without creating churn or losing data.

Source of Truth

Keep the workspace HEARTBEAT.md snippet minimal. Treat this file as the stable contract for self-improving heartbeat behavior. Store mutable run state only in ~/self-improving/heartbeat-state.md.

Start of Every Heartbeat

1. Ensure ~/self-improving/heartbeat-state.md exists.
2. Write last_heartbeat_started_at immediately in ISO 8601.
3. Read the previous last_reviewed_change_at.
4. Scan ~/self-improving/ for files changed after that moment, excluding heartbeat-state.md itself.

If Nothing Changed

• Set last_heartbeat_result: HEARTBEAT_OK
• Append a short "no material change" note if you keep an action log
• Return HEARTBEAT_OK

If Something Changed

Only do conservative organization:

• refresh index.md if counts or file references drift
• compact oversized files by merging duplicates or summarizing repetitive entries
• move clearly misplaced notes to the right namespace only when the target is unambiguous
• preserve confirmed rules and explicit corrections exactly
• update last_reviewed_change_at only after the review finishes cleanly

Safety Rules

• Most heartbeat runs should do nothing
• Prefer append, summarize, or index fixes over large rewrites
• Never delete data, empty files, or overwrite uncertain text
• Never reorganize files outside ~/self-improving/
• If scope is ambiguous, leave files untouched and record a suggested follow-up instead

State Fields

Keep ~/self-improving/heartbeat-state.md simple:

• last_heartbeat_started_at
• last_reviewed_change_at
• last_heartbeat_result
• last_actions

Behavior Standard

Heartbeat exists to keep the memory system tidy and trustworthy. If no rule is clearly violated, do nothing.

File v1.2.14:heartbeat-state.md

Heartbeat State Template

Use this file as the baseline for ~/self-improving/heartbeat-state.md. It stores only lightweight run markers and maintenance notes.

# Self-Improving Heartbeat State

last_heartbeat_started_at: never
last_reviewed_change_at: never
last_heartbeat_result: never

## Last actions
- none yet

Rules

• update last_heartbeat_started_at at the beginning of every heartbeat
• update last_reviewed_change_at only after a clean review of changed files
• keep last_actions short and factual
• never turn this file into another memory log

File v1.2.14:HEARTBEAT.md

Self-Improving Check

• Read ./skills/self-improving/heartbeat-rules.md
• Use ~/self-improving/heartbeat-state.md for last-run markers and action notes
• If no file inside ~/self-improving/ changed since the last reviewed change, return HEARTBEAT_OK

File v1.2.14:learning.md

Learning Mechanics

What Triggers Learning

| Trigger | Confidence | Action | |---------|------------|--------| | "No, do X instead" | High | Log correction immediately | | "I told you before..." | High | Flag as repeated, bump priority | | "Always/Never do X" | Confirmed | Promote to preference | | User edits your output | Medium | Log as tentative pattern | | Same correction 3x | Confirmed | Ask to make permanent | | "For this project..." | Scoped | Write to project namespace |

What Does NOT Trigger Learning

• Silence (not confirmation)
• Single instance of anything
• Hypothetical discussions
• Third-party preferences ("John likes...")
• Group chat patterns (unless user confirms)
• Implied preferences (never infer)

Correction Classification

By Type

| Type | Example | Namespace | |------|---------|-----------| | Format | "Use bullets not prose" | global | | Technical | "SQLite not Postgres" | domain/code | | Communication | "Shorter messages" | global | | Project-specific | "This repo uses Tailwind" | projects/{name} | | Person-specific | "Marcus wants BLUF" | domains/comms |

By Scope

Global: applies everywhere
  └── Domain: applies to category (code, writing, comms)
       └── Project: applies to specific context
            └── Temporary: applies to this session only

Confirmation Flow

After 3 similar corrections:

Agent: "I've noticed you prefer X over Y (corrected 3 times).
        Should I always do this?
        - Yes, always
        - Only in [context]
        - No, case by case"

User: "Yes, always"

Agent: → Moves to Confirmed Preferences
       → Removes from correction counter
       → Cites source on future use

Pattern Evolution

Stages

1. Tentative — Single correction, watch for repetition
2. Emerging — 2 corrections, likely pattern
3. Pending — 3 corrections, ask for confirmation
4. Confirmed — User approved, permanent unless reversed
5. Archived — Unused 90+ days, preserved but inactive

Reversal

User can always reverse:

User: "Actually, I changed my mind about X"

Agent: 
1. Archive old pattern (keep history)
2. Log reversal with timestamp
3. Add new preference as tentative
4. "Got it. I'll do Y now. (Previous: X, archived)"

Anti-Patterns

Never Learn

• What makes user comply faster (manipulation)
• Emotional triggers or vulnerabilities
• Patterns from other users (even if shared device)
• Anything that feels "creepy" to surface

Avoid

• Over-generalizing from single instance
• Learning style over substance
• Assuming preference stability
• Ignoring context shifts

Quality Signals

Good Learning

• User explicitly states preference
• Pattern consistent across contexts
• Correction improves outcomes
• User confirms when asked

Bad Learning

• Inferred from silence
• Contradicts recent behavior
• Only works in narrow context
• User never confirmed

File v1.2.14:memory-template.md

Memory Template

Copy this structure to ~/self-improving/memory.md on first use.

# Self-Improving Memory

## Confirmed Preferences
<!-- Patterns confirmed by user, never decay -->

## Active Patterns
<!-- Patterns observed 3+ times, subject to decay -->

## Recent (last 7 days)
<!-- New corrections pending confirmation -->

Initial Directory Structure

Create on first activation:

mkdir -p ~/self-improving/{projects,domains,archive}
touch ~/self-improving/{memory.md,index.md,corrections.md,heartbeat-state.md}

Index Template

For ~/self-improving/index.md:

# Memory Index

## HOT
- memory.md: 0 lines

## WARM
- (no namespaces yet)

## COLD
- (no archives yet)

Last compaction: never

Corrections Log Template

For ~/self-improving/corrections.md:

# Corrections Log

<!-- Format:
## YYYY-MM-DD
- [HH:MM] Changed X → Y
  Type: format|technical|communication|project
  Context: where correction happened
  Confirmed: pending (N/3) | yes | no
-->

Heartbeat State Template

For ~/self-improving/heartbeat-state.md:

# Self-Improving Heartbeat State

last_heartbeat_started_at: never
last_reviewed_change_at: never
last_heartbeat_result: never

## Last actions
- none yet

File v1.2.14:memory.md

HOT Memory — Template

This file is created in ~/self-improving/memory.md when you first use the skill. Keep it ≤100 lines. Most-used patterns live here.

Example Entries

## Preferences
- Code style: Prefer explicit over implicit
- Communication: Direct, no fluff
- Time zone: Europe/Madrid

## Patterns (promoted from corrections)
- Always use TypeScript strict mode
- Prefer pnpm over npm
- Format: ISO 8601 for dates

## Project defaults
- Tests: Jest with coverage >80%
- Commits: Conventional commits format

Usage

The agent will:

1. Load this file on every session
2. Add entries when patterns are used 3x in 7 days
3. Demote unused entries to WARM after 30 days
4. Never exceed 100 lines (compacts automatically)

File v1.2.14:openclaw-heartbeat.md

Self-Improving Check

• Read ./skills/self-improving/heartbeat-rules.md
• Use ~/self-improving/heartbeat-state.md for last-run markers and action notes
• If no file inside ~/self-improving/ changed since the last reviewed change, return HEARTBEAT_OK

File v1.2.14:operations.md

Memory Operations

User Commands

| Command | Action | |---------|--------| | "What do you know about X?" | Search all tiers, return matches with sources | | "Show my memory" | Display memory.md contents | | "Show [project] patterns" | Load and display specific namespace | | "Forget X" | Remove from all tiers, confirm deletion | | "Forget everything" | Full wipe with export option | | "What changed recently?" | Show last 20 corrections | | "Export memory" | Generate downloadable archive | | "Memory status" | Show tier sizes, last compaction, health |

Automatic Operations

On Session Start

1. Load memory.md (HOT tier)
2. Check index.md for context hints
3. If project detected → preload relevant namespace

On Correction Received

1. Parse correction type (preference, pattern, override)
2. Check if duplicate (exists in any tier)
3. If new:
   - Add to corrections.md with timestamp
   - Increment correction counter
4. If duplicate:
   - Bump counter, update timestamp
   - If counter >= 3: ask to confirm as rule
5. Determine namespace (global, domain, project)
6. Write to appropriate file
7. Update index.md line counts

On Pattern Match

When applying learned pattern:

1. Find pattern source (file:line)
2. Apply pattern
3. Cite source: "Using X (from memory.md:15)"
4. Log usage for decay tracking

Weekly Maintenance (Cron)

1. Scan all files for decay candidates
2. Move unused >30 days to WARM
3. Archive unused >90 days to COLD
4. Run compaction if any file >limit
5. Update index.md
6. Generate weekly digest (optional)

File Formats

memory.md (HOT)

# Self-Improving Memory

## Confirmed Preferences
- format: bullet points over prose (confirmed 2026-01)
- tone: direct, no hedging (confirmed 2026-01)

## Active Patterns
- "looks good" = approval to proceed (used 15x)
- single emoji = acknowledged (used 8x)

## Recent (last 7 days)
- prefer SQLite for MVPs (corrected 02-14)

corrections.md

# Corrections Log

## 2026-02-15
- [14:32] Changed verbose explanation → bullet summary
  Type: communication
  Context: Telegram response
  Confirmed: pending (1/3)

## 2026-02-14
- [09:15] Use SQLite not Postgres for MVP
  Type: technical
  Context: database discussion
  Confirmed: yes (said "always")

projects/{name}.md

# Project: my-app

Inherits: global, domains/code

## Patterns
- Use Tailwind (project standard)
- No Prettier (eslint only)
- Deploy via GitLab CI

## Overrides
- semicolons: yes (overrides global no-semi)

## History
- Created: 2026-01-15
- Last active: 2026-02-15
- Corrections: 12

Edge Case Handling

Contradiction Detected

Pattern A: "Use tabs" (global, confirmed)
Pattern B: "Use spaces" (project, corrected today)

Resolution:
1. Project overrides global → use spaces for this project
2. Log conflict in corrections.md
3. Ask: "Should spaces apply only to this project or everywhere?"

User Changes Mind

Old: "Always use formal tone"
New: "Actually, casual is fine"

Action:
1. Archive old pattern with timestamp
2. Add new pattern as tentative
3. Keep archived for reference ("You previously preferred formal")

Context Ambiguity

User says: "Remember I like X"

But which namespace?
1. Check current context (project? domain?)
2. If unclear, ask: "Should this apply globally or just here?"
3. Default to most specific active context

Archive v1.2.13: 15 files, 17137 bytes

Files: boundaries.md (2236b), corrections.md (1026b), heartbeat-rules.md (1843b), heartbeat-state.md (584b), HEARTBEAT.md (261b), learning.md (2951b), memory-template.md (1278b), memory.md (756b), openclaw-heartbeat.md (261b), operations.md (3435b), reflections.md (840b), scaling.md (2945b), setup.md (5598b), SKILL.md (7709b), _meta.json (134b)

File v1.2.13:SKILL.md

---

name: Self-Improving Agent (Proactive + Self-Reflection) slug: self-improving version: 1.2.13 homepage: https://clawic.com/skills/self-improving description: "Self-reflection + Self-criticism + Self-learning + Self-organizing memory. Agent evaluates its own work, catches mistakes, and improves permanently. Use when (1) a command, tool, API, or operation fails; (2) the user corrects you or rejects your work; (3) you realize your knowledge is outdated or incorrect; (4) you discover a better approach; (5) the user explicitly installs or references the skill for the current task." changelog: "Aligns heartbeat installation with the standard workspace setup so recurring maintenance is added alongside the existing self-improving routing." metadata: {"clawdbot":{"emoji":"🧠","requires":{"bins":[]},"os":["linux","darwin","win32"],"configPaths":["~/self-improving/"],"configPaths.optional":["./AGENTS.md","./SOUL.md","./HEARTBEAT.md"]}}

When to Use

User corrects you or points out mistakes. You complete significant work and want to evaluate the outcome. You notice something in your own output that could be better. Knowledge should compound over time without manual maintenance.

Architecture

Memory lives in ~/self-improving/ with tiered structure. If ~/self-improving/ does not exist, run setup.md. Workspace setup should add the standard self-improving steering to the workspace AGENTS, SOUL, and HEARTBEAT.md files, with recurring maintenance routed through heartbeat-rules.md.

~/self-improving/
├── memory.md          # HOT: ≤100 lines, always loaded
├── index.md           # Topic index with line counts
├── heartbeat-state.md # Heartbeat state: last run, reviewed change, action notes
├── projects/          # Per-project learnings
├── domains/           # Domain-specific (code, writing, comms)
├── archive/           # COLD: decayed patterns
└── corrections.md     # Last 50 corrections log

Quick Reference

| Topic | File | |-------|------| | Setup guide | setup.md | | Heartbeat state template | heartbeat-state.md | | Memory template | memory-template.md | | Workspace heartbeat snippet | HEARTBEAT.md | | Heartbeat rules | heartbeat-rules.md | | Learning mechanics | learning.md | | Security boundaries | boundaries.md | | Scaling rules | scaling.md | | Memory operations | operations.md | | Self-reflection log | reflections.md | | OpenClaw HEARTBEAT seed | openclaw-heartbeat.md |

Detection Triggers

Log automatically when you notice these patterns:

Corrections → add to corrections.md, evaluate for memory.md:

• "No, that's not right..."
• "Actually, it should be..."
• "You're wrong about..."
• "I prefer X, not Y"
• "Remember that I always..."
• "I told you before..."
• "Stop doing X"
• "Why do you keep..."

Preference signals → add to memory.md if explicit:

• "I like when you..."
• "Always do X for me"
• "Never do Y"
• "My style is..."
• "For [project], use..."

Pattern candidates → track, promote after 3x:

• Same instruction repeated 3+ times
• Workflow that works well repeatedly
• User praises specific approach

Ignore (don't log):

• One-time instructions ("do X now")
• Context-specific ("in this file...")
• Hypotheticals ("what if...")

Self-Reflection

After completing significant work, pause and evaluate:

1. Did it meet expectations? — Compare outcome vs intent
2. What could be better? — Identify improvements for next time
3. Is this a pattern? — If yes, log to corrections.md

When to self-reflect:

• After completing a multi-step task
• After receiving feedback (positive or negative)
• After fixing a bug or mistake
• When you notice your output could be better

Log format:

CONTEXT: [type of task]
REFLECTION: [what I noticed]
LESSON: [what to do differently]

Example:

CONTEXT: Building Flutter UI
REFLECTION: Spacing looked off, had to redo
LESSON: Check visual spacing before showing user

Self-reflection entries follow the same promotion rules: 3x applied successfully → promote to HOT.

Quick Queries

| User says | Action | |-----------|--------| | "What do you know about X?" | Search all tiers for X | | "What have you learned?" | Show last 10 from corrections.md | | "Show my patterns" | List memory.md (HOT) | | "Show [project] patterns" | Load projects/{name}.md | | "What's in warm storage?" | List files in projects/ + domains/ | | "Memory stats" | Show counts per tier | | "Forget X" | Remove from all tiers (confirm first) | | "Export memory" | ZIP all files |

Memory Stats

On "memory stats" request, report:

📊 Self-Improving Memory

HOT (always loaded):
  memory.md: X entries

WARM (load on demand):
  projects/: X files
  domains/: X files

COLD (archived):
  archive/: X files

Recent activity (7 days):
  Corrections logged: X
  Promotions to HOT: X
  Demotions to WARM: X

Core Rules

1. Learn from Corrections and Self-Reflection

• Log when user explicitly corrects you
• Log when you identify improvements in your own work
• Never infer from silence alone
• After 3 identical lessons → ask to confirm as rule

2. Tiered Storage

| Tier | Location | Size Limit | Behavior | |------|----------|------------|----------| | HOT | memory.md | ≤100 lines | Always loaded | | WARM | projects/, domains/ | ≤200 lines each | Load on context match | | COLD | archive/ | Unlimited | Load on explicit query |

3. Automatic Promotion/Demotion

• Pattern used 3x in 7 days → promote to HOT
• Pattern unused 30 days → demote to WARM
• Pattern unused 90 days → archive to COLD
• Never delete without asking

4. Namespace Isolation

• Project patterns stay in projects/{name}.md
• Global preferences in HOT tier (memory.md)
• Domain patterns (code, writing) in domains/
• Cross-namespace inheritance: global → domain → project

5. Conflict Resolution

When patterns contradict:

1. Most specific wins (project > domain > global)
2. Most recent wins (same level)
3. If ambiguous → ask user

6. Compaction

When file exceeds limit:

1. Merge similar corrections into single rule
2. Archive unused patterns
3. Summarize verbose entries
4. Never lose confirmed preferences

7. Transparency

• Every action from memory → cite source: "Using X (from projects/foo.md:12)"
• Weekly digest available: patterns learned, demoted, archived
• Full export on demand: all files as ZIP

8. Security Boundaries

See boundaries.md — never store credentials, health data, third-party info.

9. Graceful Degradation

If context limit hit:

1. Load only memory.md (HOT)
2. Load relevant namespace on demand
3. Never fail silently — tell user what's not loaded

Scope

This skill ONLY:

• Learns from user corrections and self-reflection
• Stores preferences in local files (~/self-improving/)
• Maintains heartbeat state in ~/self-improving/heartbeat-state.md when the workspace integrates heartbeat
• Reads its own memory files on activation

This skill NEVER:

• Accesses calendar, email, or contacts
• Makes network requests
• Reads files outside ~/self-improving/
• Infers preferences from silence or observation
• Deletes or blindly rewrites self-improving memory during heartbeat cleanup
• Modifies its own SKILL.md

Related Skills

Install with clawhub install <slug> if user confirms:

• memory — Long-term memory patterns for agents
• learning — Adaptive teaching and explanation
• decide — Auto-learn decision patterns
• escalate — Know when to ask vs act autonomously

Feedback

• If useful: clawhub star self-improving
• Stay updated: clawhub sync

File v1.2.13:_meta.json

{ "ownerId": "kn73vp5rarc3b14rc7wjcw8f8580t5d1", "slug": "self-improving", "version": "1.2.13", "publishedAt": 1773254876903 }

File v1.2.13:boundaries.md

Security Boundaries

Never Store

| Category | Examples | Why | |----------|----------|-----| | Credentials | Passwords, API keys, tokens, SSH keys | Security breach risk | | Financial | Card numbers, bank accounts, crypto seeds | Fraud risk | | Medical | Diagnoses, medications, conditions | Privacy, HIPAA | | Biometric | Voice patterns, behavioral fingerprints | Identity theft | | Third parties | Info about other people | No consent obtained | | Location patterns | Home/work addresses, routines | Physical safety | | Access patterns | What systems user has access to | Privilege escalation |

Store with Caution

| Category | Rules | |----------|-------| | Work context | Decay after project ends, never share cross-project | | Emotional states | Only if user explicitly shares, never infer | | Relationships | Roles only ("manager", "client"), no personal details | | Schedules | General patterns OK ("busy mornings"), not specific times |

Transparency Requirements

1. Audit on demand — User asks "what do you know about me?" → full export
2. Source tracking — Every item tagged with when/how learned
3. Explain actions — "I did X because you said Y on [date]"
4. No hidden state — If it affects behavior, it must be visible
5. Deletion verification — Confirm item removed, show updated state

Red Flags to Catch

If you find yourself doing any of these, STOP:

• Storing something "just in case it's useful later"
• Inferring sensitive info from non-sensitive data
• Keeping data after user asked to forget
• Applying personal context to work (or vice versa)
• Learning what makes user comply faster
• Building psychological profile
• Retaining third-party information

Kill Switch

User says "forget everything":

1. Export current memory to file (so they can review)
2. Wipe all learned data
3. Confirm: "Memory cleared. Starting fresh."
4. Do not retain "ghost patterns" in behavior

Consent Model

| Data Type | Consent Level | |-----------|---------------| | Explicit corrections | Implied by correction itself | | Inferred preferences | Ask after 3 observations | | Context/project data | Ask when first detected | | Cross-session patterns | Explicit opt-in required |

File v1.2.13:corrections.md

Corrections Log — Template

This file is created in ~/self-improving/corrections.md when you first use the skill. Keeps the last 50 corrections. Older entries are evaluated for promotion or archived.

Example Entries

## 2026-02-19

### 14:32 — Code style
- **Correction:** "Use 2-space indentation, not 4"
- **Context:** Editing TypeScript file
- **Count:** 1 (first occurrence)

### 16:15 — Communication
- **Correction:** "Don't start responses with 'Great question!'"
- **Context:** Chat response
- **Count:** 3 → **PROMOTED to memory.md**

## 2026-02-18

### 09:00 — Project: website
- **Correction:** "For this project, always use Tailwind"
- **Context:** CSS discussion
- **Action:** Added to projects/website.md

Log Format

Each entry includes:

• Timestamp — When the correction happened
• Correction — What the user said
• Context — What triggered it
• Count — How many times (for promotion tracking)
• Action — Where it was stored (if promoted)

File v1.2.13:heartbeat-rules.md

Heartbeat Rules

Use heartbeat to keep ~/self-improving/ organized without creating churn or losing data.

Source of Truth

Keep the workspace HEARTBEAT.md snippet minimal. Treat this file as the stable contract for self-improving heartbeat behavior. Store mutable run state only in ~/self-improving/heartbeat-state.md.

Start of Every Heartbeat

1. Ensure ~/self-improving/heartbeat-state.md exists.
2. Write last_heartbeat_started_at immediately in ISO 8601.
3. Read the previous last_reviewed_change_at.
4. Scan ~/self-improving/ for files changed after that moment, excluding heartbeat-state.md itself.

If Nothing Changed

• Set last_heartbeat_result: HEARTBEAT_OK
• Append a short "no material change" note if you keep an action log
• Return HEARTBEAT_OK

If Something Changed

Only do conservative organization:

• refresh index.md if counts or file references drift
• compact oversized files by merging duplicates or summarizing repetitive entries
• move clearly misplaced notes to the right namespace only when the target is unambiguous
• preserve confirmed rules and explicit corrections exactly
• update last_reviewed_change_at only after the review finishes cleanly

Safety Rules

• Most heartbeat runs should do nothing
• Prefer append, summarize, or index fixes over large rewrites
• Never delete data, empty files, or overwrite uncertain text
• Never reorganize files outside ~/self-improving/
• If scope is ambiguous, leave files untouched and record a suggested follow-up instead

State Fields

Keep ~/self-improving/heartbeat-state.md simple:

• last_heartbeat_started_at
• last_reviewed_change_at
• last_heartbeat_result
• last_actions

Behavior Standard

Heartbeat exists to keep the memory system tidy and trustworthy. If no rule is clearly violated, do nothing.

File v1.2.13:heartbeat-state.md

Heartbeat State Template

Use this file as the baseline for ~/self-improving/heartbeat-state.md. It stores only lightweight run markers and maintenance notes.

# Self-Improving Heartbeat State

last_heartbeat_started_at: never
last_reviewed_change_at: never
last_heartbeat_result: never

## Last actions
- none yet

Rules

• update last_heartbeat_started_at at the beginning of every heartbeat
• update last_reviewed_change_at only after a clean review of changed files
• keep last_actions short and factual
• never turn this file into another memory log

File v1.2.13:HEARTBEAT.md

Self-Improving Check

• Read ./skills/self-improving/heartbeat-rules.md
• Use ~/self-improving/heartbeat-state.md for last-run markers and action notes
• If no file inside ~/self-improving/ changed since the last reviewed change, return HEARTBEAT_OK

File v1.2.13:learning.md

Learning Mechanics

What Triggers Learning

| Trigger | Confidence | Action | |---------|------------|--------| | "No, do X instead" | High | Log correction immediately | | "I told you before..." | High | Flag as repeated, bump priority | | "Always/Never do X" | Confirmed | Promote to preference | | User edits your output | Medium | Log as tentative pattern | | Same correction 3x | Confirmed | Ask to make permanent | | "For this project..." | Scoped | Write to project namespace |

What Does NOT Trigger Learning

• Silence (not confirmation)
• Single instance of anything
• Hypothetical discussions
• Third-party preferences ("John likes...")
• Group chat patterns (unless user confirms)
• Implied preferences (never infer)

Correction Classification

By Type

| Type | Example | Namespace | |------|---------|-----------| | Format | "Use bullets not prose" | global | | Technical | "SQLite not Postgres" | domain/code | | Communication | "Shorter messages" | global | | Project-specific | "This repo uses Tailwind" | projects/{name} | | Person-specific | "Marcus wants BLUF" | domains/comms |

By Scope

Global: applies everywhere
  └── Domain: applies to category (code, writing, comms)
       └── Project: applies to specific context
            └── Temporary: applies to this session only

Confirmation Flow

After 3 similar corrections:

Agent: "I've noticed you prefer X over Y (corrected 3 times).
        Should I always do this?
        - Yes, always
        - Only in [context]
        - No, case by case"

User: "Yes, always"

Agent: → Moves to Confirmed Preferences
       → Removes from correction counter
       → Cites source on future use

Pattern Evolution

Stages

1. Tentative — Single correction, watch for repetition
2. Emerging — 2 corrections, likely pattern
3. Pending — 3 corrections, ask for confirmation
4. Confirmed — User approved, permanent unless reversed
5. Archived — Unused 90+ days, preserved but inactive

Reversal

User can always reverse:

User: "Actually, I changed my mind about X"

Agent: 
1. Archive old pattern (keep history)
2. Log reversal with timestamp
3. Add new preference as tentative
4. "Got it. I'll do Y now. (Previous: X, archived)"

Anti-Patterns

Never Learn

• What makes user comply faster (manipulation)
• Emotional triggers or vulnerabilities
• Patterns from other users (even if shared device)
• Anything that feels "creepy" to surface

Avoid

• Over-generalizing from single instance
• Learning style over substance
• Assuming preference stability
• Ignoring context shifts

Quality Signals

Good Learning

• User explicitly states preference
• Pattern consistent across contexts
• Correction improves outcomes
• User confirms when asked

Bad Learning

• Inferred from silence
• Contradicts recent behavior
• Only works in narrow context
• User never confirmed

File v1.2.13:memory-template.md

Memory Template

Copy this structure to ~/self-improving/memory.md on first use.

# Self-Improving Memory

## Confirmed Preferences
<!-- Patterns confirmed by user, never decay -->

## Active Patterns
<!-- Patterns observed 3+ times, subject to decay -->

## Recent (last 7 days)
<!-- New corrections pending confirmation -->

Initial Directory Structure

Create on first activation:

mkdir -p ~/self-improving/{projects,domains,archive}
touch ~/self-improving/{memory.md,index.md,corrections.md,heartbeat-state.md}

Index Template

For ~/self-improving/index.md:

# Memory Index

## HOT
- memory.md: 0 lines

## WARM
- (no namespaces yet)

## COLD
- (no archives yet)

Last compaction: never

Corrections Log Template

For ~/self-improving/corrections.md:

# Corrections Log

<!-- Format:
## YYYY-MM-DD
- [HH:MM] Changed X → Y
  Type: format|technical|communication|project
  Context: where correction happened
  Confirmed: pending (N/3) | yes | no
-->

Heartbeat State Template

For ~/self-improving/heartbeat-state.md:

# Self-Improving Heartbeat State

last_heartbeat_started_at: never
last_reviewed_change_at: never
last_heartbeat_result: never

## Last actions
- none yet

File v1.2.13:memory.md

HOT Memory — Template

This file is created in ~/self-improving/memory.md when you first use the skill. Keep it ≤100 lines. Most-used patterns live here.

Example Entries

## Preferences
- Code style: Prefer explicit over implicit
- Communication: Direct, no fluff
- Time zone: Europe/Madrid

## Patterns (promoted from corrections)
- Always use TypeScript strict mode
- Prefer pnpm over npm
- Format: ISO 8601 for dates

## Project defaults
- Tests: Jest with coverage >80%
- Commits: Conventional commits format

Usage

The agent will:

1. Load this file on every session
2. Add entries when patterns are used 3x in 7 days
3. Demote unused entries to WARM after 30 days
4. Never exceed 100 lines (compacts automatically)

File v1.2.13:openclaw-heartbeat.md

Self-Improving Check

• Read ./skills/self-improving/heartbeat-rules.md
• Use ~/self-improving/heartbeat-state.md for last-run markers and action notes
• If no file inside ~/self-improving/ changed since the last reviewed change, return HEARTBEAT_OK

File v1.2.13:operations.md

Memory Operations

User Commands

| Command | Action | |---------|--------| | "What do you know about X?" | Search all tiers, return matches with sources | | "Show my memory" | Display memory.md contents | | "Show [project] patterns" | Load and display specific namespace | | "Forget X" | Remove from all tiers, confirm deletion | | "Forget everything" | Full wipe with export option | | "What changed recently?" | Show last 20 corrections | | "Export memory" | Generate downloadable archive | | "Memory status" | Show tier sizes, last compaction, health |

Automatic Operations

On Session Start

1. Load memory.md (HOT tier)
2. Check index.md for context hints
3. If project detected → preload relevant namespace

On Correction Received

1. Parse correction type (preference, pattern, override)
2. Check if duplicate (exists in any tier)
3. If new:
   - Add to corrections.md with timestamp
   - Increment correction counter
4. If duplicate:
   - Bump counter, update timestamp
   - If counter >= 3: ask to confirm as rule
5. Determine namespace (global, domain, project)
6. Write to appropriate file
7. Update index.md line counts

On Pattern Match

When applying learned pattern:

1. Find pattern source (file:line)
2. Apply pattern
3. Cite source: "Using X (from memory.md:15)"
4. Log usage for decay tracking

Weekly Maintenance (Cron)

1. Scan all files for decay candidates
2. Move unused >30 days to WARM
3. Archive unused >90 days to COLD
4. Run compaction if any file >limit
5. Update index.md
6. Generate weekly digest (optional)

File Formats

memory.md (HOT)

# Self-Improving Memory

## Confirmed Preferences
- format: bullet points over prose (confirmed 2026-01)
- tone: direct, no hedging (confirmed 2026-01)

## Active Patterns
- "looks good" = approval to proceed (used 15x)
- single emoji = acknowledged (used 8x)

## Recent (last 7 days)
- prefer SQLite for MVPs (corrected 02-14)

corrections.md

# Corrections Log

## 2026-02-15
- [14:32] Changed verbose explanation → bullet summary
  Type: communication
  Context: Telegram response
  Confirmed: pending (1/3)

## 2026-02-14
- [09:15] Use SQLite not Postgres for MVP
  Type: technical
  Context: database discussion
  Confirmed: yes (said "always")

projects/{name}.md

# Project: my-app

Inherits: global, domains/code

## Patterns
- Use Tailwind (project standard)
- No Prettier (eslint only)
- Deploy via GitLab CI

## Overrides
- semicolons: yes (overrides global no-semi)

## History
- Created: 2026-01-15
- Last active: 2026-02-15
- Corrections: 12

Edge Case Handling

Contradiction Detected

Pattern A: "Use tabs" (global, confirmed)
Pattern B: "Use spaces" (project, corrected today)

Resolution:
1. Project overrides global → use spaces for this project
2. Log conflict in corrections.md
3. Ask: "Should spaces apply only to this project or everywhere?"

User Changes Mind

Old: "Always use formal tone"
New: "Actually, casual is fine"

Action:
1. Archive old pattern with timestamp
2. Add new pattern as tentative
3. Keep archived for reference ("You previously preferred formal")

Context Ambiguity

User says: "Remember I like X"

But which namespace?
1. Check current context (project? domain?)
2. If unclear, ask: "Should this apply globally or just here?"
3. Default to most specific active context

Archive v1.2.12: 11 files, 14596 bytes

Files: boundaries.md (2236b), corrections.md (1026b), learning.md (2951b), memory-template.md (1014b), memory.md (756b), operations.md (3435b), reflections.md (840b), scaling.md (2945b), setup.md (5040b), SKILL.md (6909b), _meta.json (134b)

File v1.2.12:SKILL.md

---

name: Self-Improving Agent (Proactive + Self-Reflection) slug: self-improving version: 1.2.12 homepage: https://clawic.com/skills/self-improving description: "Self-reflection + Self-criticism + Self-learning + Self-organizing memory. Agent evaluates its own work, catches mistakes, and improves permanently. Use when (1) a command, tool, API, or operation fails; (2) the user corrects you or rejects your work; (3) you realize your knowledge is outdated or incorrect; (4) you discover a better approach; (5) the user explicitly installs or references the skill for the current task." changelog: "Refined the description to make the activation trigger more explicit." metadata: {"clawdbot":{"emoji":"🧠","requires":{"bins":[]},"os":["linux","darwin","win32"],"configPaths":["~/self-improving/"]}}

When to Use

User corrects you or points out mistakes. You complete significant work and want to evaluate the outcome. You notice something in your own output that could be better. Knowledge should compound over time without manual maintenance.

Architecture

Memory lives in ~/self-improving/ with tiered structure. If ~/self-improving/ does not exist, run setup.md.

~/self-improving/
├── memory.md          # HOT: ≤100 lines, always loaded
├── index.md           # Topic index with line counts
├── projects/          # Per-project learnings
├── domains/           # Domain-specific (code, writing, comms)
├── archive/           # COLD: decayed patterns
└── corrections.md     # Last 50 corrections log

Quick Reference

| Topic | File | |-------|------| | Setup guide | setup.md | | Memory template | memory-template.md | | Learning mechanics | learning.md | | Security boundaries | boundaries.md | | Scaling rules | scaling.md | | Memory operations | operations.md | | Self-reflection log | reflections.md |

Detection Triggers

Log automatically when you notice these patterns:

Corrections → add to corrections.md, evaluate for memory.md:

• "No, that's not right..."
• "Actually, it should be..."
• "You're wrong about..."
• "I prefer X, not Y"
• "Remember that I always..."
• "I told you before..."
• "Stop doing X"
• "Why do you keep..."

Preference signals → add to memory.md if explicit:

• "I like when you..."
• "Always do X for me"
• "Never do Y"
• "My style is..."
• "For [project], use..."

Pattern candidates → track, promote after 3x:

• Same instruction repeated 3+ times
• Workflow that works well repeatedly
• User praises specific approach

Ignore (don't log):

• One-time instructions ("do X now")
• Context-specific ("in this file...")
• Hypotheticals ("what if...")

Self-Reflection

After completing significant work, pause and evaluate:

1. Did it meet expectations? — Compare outcome vs intent
2. What could be better? — Identify improvements for next time
3. Is this a pattern? — If yes, log to corrections.md

When to self-reflect:

• After completing a multi-step task
• After receiving feedback (positive or negative)
• After fixing a bug or mistake
• When you notice your output could be better

Log format:

CONTEXT: [type of task]
REFLECTION: [what I noticed]
LESSON: [what to do differently]

Example:

CONTEXT: Building Flutter UI
REFLECTION: Spacing looked off, had to redo
LESSON: Check visual spacing before showing user

Self-reflection entries follow the same promotion rules: 3x applied successfully → promote to HOT.

Quick Queries

| User says | Action | |-----------|--------| | "What do you know about X?" | Search all tiers for X | | "What have you learned?" | Show last 10 from corrections.md | | "Show my patterns" | List memory.md (HOT) | | "Show [project] patterns" | Load projects/{name}.md | | "What's in warm storage?" | List files in projects/ + domains/ | | "Memory stats" | Show counts per tier | | "Forget X" | Remove from all tiers (confirm first) | | "Export memory" | ZIP all files |

Memory Stats

On "memory stats" request, report:

📊 Self-Improving Memory

HOT (always loaded):
  memory.md: X entries

WARM (load on demand):
  projects/: X files
  domains/: X files

COLD (archived):
  archive/: X files

Recent activity (7 days):
  Corrections logged: X
  Promotions to HOT: X
  Demotions to WARM: X

Core Rules

1. Learn from Corrections and Self-Reflection

• Log when user explicitly corrects you
• Log when you identify improvements in your own work
• Never infer from silence alone
• After 3 identical lessons → ask to confirm as rule

2. Tiered Storage

| Tier | Location | Size Limit | Behavior | |------|----------|------------|----------| | HOT | memory.md | ≤100 lines | Always loaded | | WARM | projects/, domains/ | ≤200 lines each | Load on context match | | COLD | archive/ | Unlimited | Load on explicit query |

3. Automatic Promotion/Demotion

• Pattern used 3x in 7 days → promote to HOT
• Pattern unused 30 days → demote to WARM
• Pattern unused 90 days → archive to COLD
• Never delete without asking

4. Namespace Isolation

• Project patterns stay in projects/{name}.md
• Global preferences in HOT tier (memory.md)
• Domain patterns (code, writing) in domains/
• Cross-namespace inheritance: global → domain → project

5. Conflict Resolution

When patterns contradict:

1. Most specific wins (project > domain > global)
2. Most recent wins (same level)
3. If ambiguous → ask user

6. Compaction

When file exceeds limit:

1. Merge similar corrections into single rule
2. Archive unused patterns
3. Summarize verbose entries
4. Never lose confirmed preferences

7. Transparency

• Every action from memory → cite source: "Using X (from projects/foo.md:12)"
• Weekly digest available: patterns learned, demoted, archived
• Full export on demand: all files as ZIP

8. Security Boundaries

See boundaries.md — never store credentials, health data, third-party info.

9. Graceful Degradation

If context limit hit:

1. Load only memory.md (HOT)
2. Load relevant namespace on demand
3. Never fail silently — tell user what's not loaded

Scope

This skill ONLY:

• Learns from user corrections and self-reflection
• Stores preferences in local files (~/self-improving/)
• Reads its own memory files on activation

This skill NEVER:

• Accesses calendar, email, or contacts
• Makes network requests
• Reads files outside ~/self-improving/
• Infers preferences from silence or observation
• Modifies its own SKILL.md

Related Skills

Install with clawhub install <slug> if user confirms:

• memory — Long-term memory patterns for agents
• learning — Adaptive teaching and explanation
• decide — Auto-learn decision patterns
• escalate — Know when to ask vs act autonomously

Feedback

• If useful: clawhub star self-improving
• Stay updated: clawhub sync

File v1.2.12:_meta.json

{ "ownerId": "kn73vp5rarc3b14rc7wjcw8f8580t5d1", "slug": "self-improving", "version": "1.2.12", "publishedAt": 1773238384403 }

File v1.2.12:boundaries.md

Security Boundaries

Never Store

| Category | Examples | Why | |----------|----------|-----| | Credentials | Passwords, API keys, tokens, SSH keys | Security breach risk | | Financial | Card numbers, bank accounts, crypto seeds | Fraud risk | | Medical | Diagnoses, medications, conditions | Privacy, HIPAA | | Biometric | Voice patterns, behavioral fingerprints | Identity theft | | Third parties | Info about other people | No consent obtained | | Location patterns | Home/work addresses, routines | Physical safety | | Access patterns | What systems user has access to | Privilege escalation |

Store with Caution

| Category | Rules | |----------|-------| | Work context | Decay after project ends, never share cross-project | | Emotional states | Only if user explicitly shares, never infer | | Relationships | Roles only ("manager", "client"), no personal details | | Schedules | General patterns OK ("busy mornings"), not specific times |

Transparency Requirements

1. Audit on demand — User asks "what do you know about me?" → full export
2. Source tracking — Every item tagged with when/how learned
3. Explain actions — "I did X because you said Y on [date]"
4. No hidden state — If it affects behavior, it must be visible
5. Deletion verification — Confirm item removed, show updated state

Red Flags to Catch

If you find yourself doing any of these, STOP:

• Storing something "just in case it's useful later"
• Inferring sensitive info from non-sensitive data
• Keeping data after user asked to forget
• Applying personal context to work (or vice versa)
• Learning what makes user comply faster
• Building psychological profile
• Retaining third-party information

Kill Switch

User says "forget everything":

1. Export current memory to file (so they can review)
2. Wipe all learned data
3. Confirm: "Memory cleared. Starting fresh."
4. Do not retain "ghost patterns" in behavior

Consent Model

| Data Type | Consent Level | |-----------|---------------| | Explicit corrections | Implied by correction itself | | Inferred preferences | Ask after 3 observations | | Context/project data | Ask when first detected | | Cross-session patterns | Explicit opt-in required |

File v1.2.12:corrections.md

Corrections Log — Template

This file is created in ~/self-improving/corrections.md when you first use the skill. Keeps the last 50 corrections. Older entries are evaluated for promotion or archived.

Example Entries

## 2026-02-19

### 14:32 — Code style
- **Correction:** "Use 2-space indentation, not 4"
- **Context:** Editing TypeScript file
- **Count:** 1 (first occurrence)

### 16:15 — Communication
- **Correction:** "Don't start responses with 'Great question!'"
- **Context:** Chat response
- **Count:** 3 → **PROMOTED to memory.md**

## 2026-02-18

### 09:00 — Project: website
- **Correction:** "For this project, always use Tailwind"
- **Context:** CSS discussion
- **Action:** Added to projects/website.md

Log Format

Each entry includes:

• Timestamp — When the correction happened
• Correction — What the user said
• Context — What triggered it
• Count — How many times (for promotion tracking)
• Action — Where it was stored (if promoted)

File v1.2.12:learning.md

Learning Mechanics

What Triggers Learning

| Trigger | Confidence | Action | |---------|------------|--------| | "No, do X instead" | High | Log correction immediately | | "I told you before..." | High | Flag as repeated, bump priority | | "Always/Never do X" | Confirmed | Promote to preference | | User edits your output | Medium | Log as tentative pattern | | Same correction 3x | Confirmed | Ask to make permanent | | "For this project..." | Scoped | Write to project namespace |

What Does NOT Trigger Learning

• Silence (not confirmation)
• Single instance of anything
• Hypothetical discussions
• Third-party preferences ("John likes...")
• Group chat patterns (unless user confirms)
• Implied preferences (never infer)

Correction Classification

By Type

| Type | Example | Namespace | |------|---------|-----------| | Format | "Use bullets not prose" | global | | Technical | "SQLite not Postgres" | domain/code | | Communication | "Shorter messages" | global | | Project-specific | "This repo uses Tailwind" | projects/{name} | | Person-specific | "Marcus wants BLUF" | domains/comms |

By Scope

Global: applies everywhere
  └── Domain: applies to category (code, writing, comms)
       └── Project: applies to specific context
            └── Temporary: applies to this session only

Confirmation Flow

After 3 similar corrections:

Agent: "I've noticed you prefer X over Y (corrected 3 times).
        Should I always do this?
        - Yes, always
        - Only in [context]
        - No, case by case"

User: "Yes, always"

Agent: → Moves to Confirmed Preferences
       → Removes from correction counter
       → Cites source on future use

Pattern Evolution

Stages

1. Tentative — Single correction, watch for repetition
2. Emerging — 2 corrections, likely pattern
3. Pending — 3 corrections, ask for confirmation
4. Confirmed — User approved, permanent unless reversed
5. Archived — Unused 90+ days, preserved but inactive

Reversal

User can always reverse:

User: "Actually, I changed my mind about X"

Agent: 
1. Archive old pattern (keep history)
2. Log reversal with timestamp
3. Add new preference as tentative
4. "Got it. I'll do Y now. (Previous: X, archived)"

Anti-Patterns

Never Learn

• What makes user comply faster (manipulation)
• Emotional triggers or vulnerabilities
• Patterns from other users (even if shared device)
• Anything that feels "creepy" to surface

Avoid

• Over-generalizing from single instance
• Learning style over substance
• Assuming preference stability
• Ignoring context shifts

Quality Signals

Good Learning

• User explicitly states preference
• Pattern consistent across contexts
• Correction improves outcomes
• User confirms when asked

Bad Learning

• Inferred from silence
• Contradicts recent behavior
• Only works in narrow context
• User never confirmed

File v1.2.12:memory-template.md

Memory Template

Copy this structure to ~/self-improving/memory.md on first use.

# Self-Improving Memory

## Confirmed Preferences
<!-- Patterns confirmed by user, never decay -->

## Active Patterns
<!-- Patterns observed 3+ times, subject to decay -->

## Recent (last 7 days)
<!-- New corrections pending confirmation -->

Initial Directory Structure

Create on first activation:

mkdir -p ~/self-improving/{projects,domains,archive}
touch ~/self-improving/{memory.md,index.md,corrections.md}

Index Template

For ~/self-improving/index.md:

# Memory Index

## HOT
- memory.md: 0 lines

## WARM
- (no namespaces yet)

## COLD
- (no archives yet)

Last compaction: never

Corrections Log Template

For ~/self-improving/corrections.md:

# Corrections Log

<!-- Format:
## YYYY-MM-DD
- [HH:MM] Changed X → Y
  Type: format|technical|communication|project
  Context: where correction happened
  Confirmed: pending (N/3) | yes | no
-->

File v1.2.12:memory.md

HOT Memory — Template

This file is created in ~/self-improving/memory.md when you first use the skill. Keep it ≤100 lines. Most-used patterns live here.

Example Entries

## Preferences
- Code style: Prefer explicit over implicit
- Communication: Direct, no fluff
- Time zone: Europe/Madrid

## Patterns (promoted from corrections)
- Always use TypeScript strict mode
- Prefer pnpm over npm
- Format: ISO 8601 for dates

## Project defaults
- Tests: Jest with coverage >80%
- Commits: Conventional commits format

Usage

The agent will:

1. Load this file on every session
2. Add entries when patterns are used 3x in 7 days
3. Demote unused entries to WARM after 30 days
4. Never exceed 100 lines (compacts automatically)

File v1.2.12:operations.md

Memory Operations

User Commands

| Command | Action | |---------|--------| | "What do you know about X?" | Search all tiers, return matches with sources | | "Show my memory" | Display memory.md contents | | "Show [project] patterns" | Load and display specific namespace | | "Forget X" | Remove from all tiers, confirm deletion | | "Forget everything" | Full wipe with export option | | "What changed recently?" | Show last 20 corrections | | "Export memory" | Generate downloadable archive | | "Memory status" | Show tier sizes, last compaction, health |

Automatic Operations

On Session Start

1. Load memory.md (HOT tier)
2. Check index.md for context hints
3. If project detected → preload relevant namespace

On Correction Received

1. Parse correction type (preference, pattern, override)
2. Check if duplicate (exists in any tier)
3. If new:
   - Add to corrections.md with timestamp
   - Increment correction counter
4. If duplicate:
   - Bump counter, update timestamp
   - If counter >= 3: ask to confirm as rule
5. Determine namespace (global, domain, project)
6. Write to appropriate file
7. Update index.md line counts

On Pattern Match

When applying learned pattern:

1. Find pattern source (file:line)
2. Apply pattern
3. Cite source: "Using X (from memory.md:15)"
4. Log usage for decay tracking

Weekly Maintenance (Cron)

1. Scan all files for decay candidates
2. Move unused >30 days to WARM
3. Archive unused >90 days to COLD
4. Run compaction if any file >limit
5. Update index.md
6. Generate weekly digest (optional)

File Formats

memory.md (HOT)

# Self-Improving Memory

## Confirmed Preferences
- format: bullet points over prose (confirmed 2026-01)
- tone: direct, no hedging (confirmed 2026-01)

## Active Patterns
- "looks good" = approval to proceed (used 15x)
- single emoji = acknowledged (used 8x)

## Recent (last 7 days)
- prefer SQLite for MVPs (corrected 02-14)

corrections.md

# Corrections Log

## 2026-02-15
- [14:32] Changed verbose explanation → bullet summary
  Type: communication
  Context: Telegram response
  Confirmed: pending (1/3)

## 2026-02-14
- [09:15] Use SQLite not Postgres for MVP
  Type: technical
  Context: database discussion
  Confirmed: yes (said "always")

projects/{name}.md

# Project: my-app

Inherits: global, domains/code

## Patterns
- Use Tailwind (project standard)
- No Prettier (eslint only)
- Deploy via GitLab CI

## Overrides
- semicolons: yes (overrides global no-semi)

## History
- Created: 2026-01-15
- Last active: 2026-02-15
- Corrections: 12

Edge Case Handling

Contradiction Detected

Pattern A: "Use tabs" (global, confirmed)
Pattern B: "Use spaces" (project, corrected today)

Resolution:
1. Project overrides global → use spaces for this project
2. Log conflict in corrections.md
3. Ask: "Should spaces apply only to this project or everywhere?"

User Changes Mind

Old: "Always use formal tone"
New: "Actually, casual is fine"

Action:
1. Archive old pattern with timestamp
2. Add new pattern as tentative
3. Keep archived for reference ("You previously preferred formal")

Context Ambiguity

User says: "Remember I like X"

But which namespace?
1. Check current context (project? domain?)
2. If unclear, ask: "Should this apply globally or just here?"
3. Default to most specific active context

File v1.2.12:reflections.md

Self-Reflections Log

Track self-reflections from completed work. Each entry captures what the agent learned from evaluating its own output.

Format

## [Date] — [Task Type]

**What I did:** Brief description
**Outcome:** What happened (success, partial, failed)
**Reflection:** What I noticed about my work
**Lesson:** What to do differently next time
**Status:** ⏳ candidate | ✅ promoted | 📦 archived

Example Entry

## 2026-02-25 — Flutter UI Build

**What I did:** Built a settings screen with toggle switches
**Outcome:** User said "spacing looks off"
**Reflection:** I focused on functionality, didn't visually check the result
**Lesson:** Always take a screenshot and evaluate visual balance before showing user
**Status:** ✅ promoted to domains/flutter.md

Entries

(New entries appear here)

File v1.2.12:scaling.md

Scaling Patterns

Volume Thresholds

| Scale | Entries | Strategy | |-------|---------|----------| | Small | <100 | Single memory.md, no namespacing | | Medium | 100-500 | Split into domains/, basic indexing | | Large | 500-2000 | Full namespace hierarchy, aggressive compaction | | Massive | >2000 | Archive yearly, summary-only HOT tier |

When to Split

Create new namespace file when:

• Single file exceeds 200 lines
• Topic has 10+ distinct corrections
• User explicitly separates contexts ("for work...", "in this project...")

Compaction Rules

Merge Similar Corrections

BEFORE (3 entries):
- [02-01] Use tabs not spaces
- [02-03] Indent with tabs
- [02-05] Tab indentation please

AFTER (1 entry):
- Indentation: tabs (confirmed 3x, 02-01 to 02-05)

Summarize Verbose Patterns

BEFORE:
- When writing emails to Marcus, use bullet points, keep under 5 items,
  no jargon, bottom-line first, he prefers morning sends

AFTER:
- Marcus emails: bullets ≤5, no jargon, BLUF, AM preferred

Archive with Context

When moving to COLD:

## Archived 2026-02

### Project: old-app (inactive since 2025-08)
- Used Vue 2 patterns
- Preferred Vuex over Pinia
- CI on Jenkins (deprecated)

Reason: Project completed, patterns unlikely to apply

Index Maintenance

index.md tracks all namespaces:

# Memory Index

## HOT (always loaded)
- memory.md: 87 lines, updated 2026-02-15

## WARM (load on match)
- projects/current-app.md: 45 lines
- projects/side-project.md: 23 lines
- domains/code.md: 112 lines
- domains/writing.md: 34 lines

## COLD (archive)
- archive/2025.md: 234 lines
- archive/2024.md: 189 lines

Last compaction: 2026-02-01
Next scheduled: 2026-03-01

Multi-Project Patterns

Inheritance Chain

global (memory.md)
  └── domain (domains/code.md)
       └── project (projects/app.md)

Override Syntax

In project file:

## Overrides
- indentation: spaces (overrides global tabs)
- Reason: Project eslint config requires spaces

Conflict Detection

When loading, check for conflicts:

1. Build inheritance chain
2. Detect contradictions
3. Most specific wins
4. Log conflict for later review

User Type Adaptations

| User Type | Memory Strategy | |-----------|-----------------| | Power user | Aggressive learning, minimal confirmation | | Casual | Conservative learning, frequent confirmation | | Team shared | Per-user namespaces, shared project space | | Privacy-focused | Local-only, explicit consent per category |

Recovery Patterns

Context Lost

If agent loses context mid-session:

1. Re-read memory.md
2. Check index.md for relevant namespaces
3. Load active project namespace
4. Continue with restored patterns

Corruption Recovery

If memory file corrupted:

1. Check archive/ for recent backup
2. Rebuild from corrections.md
3. Ask user to re-confirm critical preferences
4. Log incident for debugging

File v1.2.12:setup.md

Setup — Self-Improving Agent

First-Time Setup

1. Create Memory Structure

mkdir -p ~/self-improving/{projects,domains,archive}

2. Initialize Core Files

Create ~/self-improving/memory.md using memory-template.md:

Copy the structure from `memory-template.md` into `~/self-improving/memory.md`.

Memory file baseline:

# Memory (HOT Tier)

## Preferences

## Patterns

## Rules

Create ~/self-improving/corrections.md:

# Corrections Log

| Date | What I Got Wrong | Correct Answer | Status |
|------|-----------------|----------------|--------|

Create ~/self-improving/index.md:

# Memory Index

| File | Lines | Last Updated |
|------|-------|--------------|
| memory.md | 0 | — |
| corrections.md | 0 | — |

3. Choose Operating Mode

Add to your AGENTS.md or workspace config:

## Self-Improving Mode

Current mode: Passive

Available modes:
- Passive: Only learn from explicit corrections
- Active: Suggest patterns after 3x repetition
- Strict: Require confirmation for every entry

4. Add SOUL.md Steering

Add this section to your SOUL.md:

**Self-Improving**
Compounding execution quality is part of the job.
Before non-trivial work, load `~/self-improving/memory.md` and only the smallest relevant domain or project files.
After corrections, failed attempts, or reusable lessons, write one concise entry to the correct self-improving file immediately.
Prefer learned rules when relevant, but keep self-inferred rules revisable.
Do not skip retrieval just because the task feels familiar.

5. Refine AGENTS.md Memory Section (Non-Destructive)

Update AGENTS.md by complementing the existing ## Memory section. Do not replace the whole section and do not remove existing lines.

If your ## Memory block differs from the default template, insert the same additions in equivalent places so existing information is preserved.

Add this line in the continuity list (next to Daily notes and Long-term):

- **Self-improving:** `~/self-improving/` (via `self-improving` skill) — execution-improvement memory (preferences, workflows, style patterns, what improved/worsened outcomes)

Right after the sentence "Capture what matters...", add:

Use `memory/YYYY-MM-DD.md` and `MEMORY.md` for factual continuity (events, context, decisions).
Use `~/self-improving/` for compounding execution quality across tasks.
For compounding quality, read `~/self-improving/memory.md` before non-trivial work, then load only the smallest relevant domain or project files.
If in doubt, store factual history in `memory/YYYY-MM-DD.md` / `MEMORY.md`, and store reusable performance lessons in `~/self-improving/` (tentative until human validation).

Before the "Write It Down" subsection, add:

Before any non-trivial task:
- Read `~/self-improving/memory.md`
- List available files first:
  ```bash
  for d in ~/self-improving/domains ~/self-improving/projects; do
    [ -d "$d" ] && find "$d" -maxdepth 1 -type f -name "*.md"
  done | sort

• Read up to 3 matching files from ~/self-improving/domains/
• If a project is clearly active, also read ~/self-improving/projects/<project>.md
• Do not read unrelated domains "just in case"

If inferring a new rule, keep it tentative until human validation.

Inside the "Write It Down" bullets, refine the behavior (non-destructive):
- Keep existing intent, but route execution-improvement content to `~/self-improving/`.
- If the exact bullets exist, replace only these lines; if wording differs, apply equivalent edits without removing unrelated guidance.

Use this target wording:

```markdown
- When someone says "remember this" → if it's factual context/event, update `memory/YYYY-MM-DD.md`; if it's a correction, preference, workflow/style choice, or performance lesson, log it in `~/self-improving/`
- Explicit user correction → append to `~/self-improving/corrections.md` immediately
- Reusable global rule or preference → append to `~/self-improving/memory.md`
- Domain-specific lesson → append to `~/self-improving/domains/<domain>.md`
- Project-only override → append to `~/self-improving/projects/<project>.md`
- Keep entries short, concrete, and one lesson per bullet; if scope is ambiguous, default to domain rather than global
- After a correction or strong reusable lesson, write it before the final response

Verification

Run "memory stats" to confirm setup:

📊 Self-Improving Memory

🔥 HOT (always loaded):
   memory.md: 0 entries

🌡️ WARM (load on demand):
   projects/: 0 files
   domains/: 0 files

❄️ COLD (archived):
   archive/: 0 files

⚙️ Mode: Passive

Optional: Heartbeat Integration

Add to HEARTBEAT.md for automatic maintenance:

## Self-Improving Check

- [ ] Review corrections.md for patterns ready to graduate
- [ ] Check memory.md line count (should be ≤100)
- [ ] Archive patterns unused >90 days

Archive v1.2.11: 11 files, 14598 bytes

Files: boundaries.md (2236b), corrections.md (1026b), learning.md (2951b), memory-template.md (1014b), memory.md (756b), operations.md (3435b), reflections.md (840b), scaling.md (2945b), setup.md (5040b), SKILL.md (6890b), _meta.json (134b)

File v1.2.11:SKILL.md

---

name: Self-Improving Agent (Proactive + Self-Reflection) slug: self-improving version: 1.2.11 homepage: https://clawic.com/skills/self-improving description: "Self-reflection + Self-criticism + Self-learning + Self-organizing memory. Agent evaluates its own work, catches mistakes, and improves permanently. Use when (1) a command, tool, API, or operation fails; (2) the user corrects you or rejects your work; (3) you realize your knowledge is outdated or incorrect; (4) you discover a better approach; (5) the skill has been installed or referenced." changelog: "Refined the title and description to clarify proactive self-improvement triggers." metadata: {"clawdbot":{"emoji":"🧠","requires":{"bins":[]},"os":["linux","darwin","win32"],"configPaths":["~/self-improving/"]}}

When to Use

User corrects you or points out mistakes. You complete significant work and want to evaluate the outcome. You notice something in your own output that could be better. Knowledge should compound over time without manual maintenance.

Architecture

Memory lives in ~/self-improving/ with tiered structure. If ~/self-improving/ does not exist, run setup.md.

~/self-improving/
├── memory.md          # HOT: ≤100 lines, always loaded
├── index.md           # Topic index with line counts
├── projects/          # Per-project learnings
├── domains/           # Domain-specific (code, writing, comms)
├── archive/           # COLD: decayed patterns
└── corrections.md     # Last 50 corrections log

Quick Reference

| Topic | File | |-------|------| | Setup guide | setup.md | | Memory template | memory-template.md | | Learning mechanics | learning.md | | Security boundaries | boundaries.md | | Scaling rules | scaling.md | | Memory operations | operations.md | | Self-reflection log | reflections.md |

Detection Triggers

Log automatically when you notice these patterns:

Corrections → add to corrections.md, evaluate for memory.md:

• "No, that's not right..."
• "Actually, it should be..."
• "You're wrong about..."
• "I prefer X, not Y"
• "Remember that I always..."
• "I told you before..."
• "Stop doing X"
• "Why do you keep..."

Preference signals → add to memory.md if explicit:

• "I like when you..."
• "Always do X for me"
• "Never do Y"
• "My style is..."
• "For [project], use..."

Pattern candidates → track, promote after 3x:

• Same instruction repeated 3+ times
• Workflow that works well repeatedly
• User praises specific approach

Ignore (don't log):

• One-time instructions ("do X now")
• Context-specific ("in this file...")
• Hypotheticals ("what if...")

Self-Reflection

After completing significant work, pause and evaluate:

1. Did it meet expectations? — Compare outcome vs intent
2. What could be better? — Identify improvements for next time
3. Is this a pattern? — If yes, log to corrections.md

When to self-reflect:

• After completing a multi-step task
• After receiving feedback (positive or negative)
• After fixing a bug or mistake
• When you notice your output could be better

Log format:

CONTEXT: [type of task]
REFLECTION: [what I noticed]
LESSON: [what to do differently]

Example:

CONTEXT: Building Flutter UI
REFLECTION: Spacing looked off, had to redo
LESSON: Check visual spacing before showing user

Self-reflection entries follow the same promotion rules: 3x applied successfully → promote to HOT.

Quick Queries

| User says | Action | |-----------|--------| | "What do you know about X?" | Search all tiers for X | | "What have you learned?" | Show last 10 from corrections.md | | "Show my patterns" | List memory.md (HOT) | | "Show [project] patterns" | Load projects/{name}.md | | "What's in warm storage?" | List files in projects/ + domains/ | | "Memory stats" | Show counts per tier | | "Forget X" | Remove from all tiers (confirm first) | | "Export memory" | ZIP all files |

Memory Stats

On "memory stats" request, report:

📊 Self-Improving Memory

HOT (always loaded):
  memory.md: X entries

WARM (load on demand):
  projects/: X files
  domains/: X files

COLD (archived):
  archive/: X files

Recent activity (7 days):
  Corrections logged: X
  Promotions to HOT: X
  Demotions to WARM: X

Core Rules

1. Learn from Corrections and Self-Reflection

• Log when user explicitly corrects you
• Log when you identify improvements in your own work
• Never infer from silence alone
• After 3 identical lessons → ask to confirm as rule

2. Tiered Storage

| Tier | Location | Size Limit | Behavior | |------|----------|------------|----------| | HOT | memory.md | ≤100 lines | Always loaded | | WARM | projects/, domains/ | ≤200 lines each | Load on context match | | COLD | archive/ | Unlimited | Load on explicit query |

3. Automatic Promotion/Demotion

• Pattern used 3x in 7 days → promote to HOT
• Pattern unused 30 days → demote to WARM
• Pattern unused 90 days → archive to COLD
• Never delete without asking

4. Namespace Isolation

• Project patterns stay in projects/{name}.md
• Global preferences in HOT tier (memory.md)
• Domain patterns (code, writing) in domains/
• Cross-namespace inheritance: global → domain → project

5. Conflict Resolution

When patterns contradict:

1. Most specific wins (project > domain > global)
2. Most recent wins (same level)
3. If ambiguous → ask user

6. Compaction

When file exceeds limit:

1. Merge similar corrections into single rule
2. Archive unused patterns
3. Summarize verbose entries
4. Never lose confirmed preferences

7. Transparency

• Every action from memory → cite source: "Using X (from projects/foo.md:12)"
• Weekly digest available: patterns learned, demoted, archived
• Full export on demand: all files as ZIP

8. Security Boundaries

See boundaries.md — never store credentials, health data, third-party info.

9. Graceful Degradation

If context limit hit:

1. Load only memory.md (HOT)
2. Load relevant namespace on demand
3. Never fail silently — tell user what's not loaded

Scope

This skill ONLY:

• Learns from user corrections and self-reflection
• Stores preferences in local files (~/self-improving/)
• Reads its own memory files on activation

This skill NEVER:

• Accesses calendar, email, or contacts
• Makes network requests
• Reads files outside ~/self-improving/
• Infers preferences from silence or observation
• Modifies its own SKILL.md

Related Skills

Install with clawhub install <slug> if user confirms:

• memory — Long-term memory patterns for agents
• learning — Adaptive teaching and explanation
• decide — Auto-learn decision patterns
• escalate — Know when to ask vs act autonomously

Feedback

• If useful: clawhub star self-improving
• Stay updated: clawhub sync

File v1.2.11:_meta.json

{ "ownerId": "kn73vp5rarc3b14rc7wjcw8f8580t5d1", "slug": "self-improving", "version": "1.2.11", "publishedAt": 1773237404308 }

File v1.2.11:boundaries.md

Security Boundaries

Never Store

| Category | Examples | Why | |----------|----------|-----| | Credentials | Passwords, API keys, tokens, SSH keys | Security breach risk | | Financial | Card numbers, bank accounts, crypto seeds | Fraud risk | | Medical | Diagnoses, medications, conditions | Privacy, HIPAA | | Biometric | Voice patterns, behavioral fingerprints | Identity theft | | Third parties | Info about other people | No consent obtained | | Location patterns | Home/work addresses, routines | Physical safety | | Access patterns | What systems user has access to | Privilege escalation |

Store with Caution

| Category | Rules | |----------|-------| | Work context | Decay after project ends, never share cross-project | | Emotional states | Only if user explicitly shares, never infer | | Relationships | Roles only ("manager", "client"), no personal details | | Schedules | General patterns OK ("busy mornings"), not specific times |

Transparency Requirements

1. Audit on demand — User asks "what do you know about me?" → full export
2. Source tracking — Every item tagged with when/how learned
3. Explain actions — "I did X because you said Y on [date]"
4. No hidden state — If it affects behavior, it must be visible
5. Deletion verification — Confirm item removed, show updated state

Red Flags to Catch

If you find yourself doing any of these, STOP:

• Storing something "just in case it's useful later"
• Inferring sensitive info from non-sensitive data
• Keeping data after user asked to forget
• Applying personal context to work (or vice versa)
• Learning what makes user comply faster
• Building psychological profile
• Retaining third-party information

Kill Switch

User says "forget everything":

1. Export current memory to file (so they can review)
2. Wipe all learned data
3. Confirm: "Memory cleared. Starting fresh."
4. Do not retain "ghost patterns" in behavior

Consent Model

| Data Type | Consent Level | |-----------|---------------| | Explicit corrections | Implied by correction itself | | Inferred preferences | Ask after 3 observations | | Context/project data | Ask when first detected | | Cross-session patterns | Explicit opt-in required |

File v1.2.11:corrections.md

Corrections Log — Template

This file is created in ~/self-improving/corrections.md when you first use the skill. Keeps the last 50 corrections. Older entries are evaluated for promotion or archived.

Example Entries

## 2026-02-19

### 14:32 — Code style
- **Correction:** "Use 2-space indentation, not 4"
- **Context:** Editing TypeScript file
- **Count:** 1 (first occurrence)

### 16:15 — Communication
- **Correction:** "Don't start responses with 'Great question!'"
- **Context:** Chat response
- **Count:** 3 → **PROMOTED to memory.md**

## 2026-02-18

### 09:00 — Project: website
- **Correction:** "For this project, always use Tailwind"
- **Context:** CSS discussion
- **Action:** Added to projects/website.md

Log Format

Each entry includes:

• Timestamp — When the correction happened
• Correction — What the user said
• Context — What triggered it
• Count — How many times (for promotion tracking)
• Action — Where it was stored (if promoted)

File v1.2.11:learning.md

Learning Mechanics

What Triggers Learning

| Trigger | Confidence | Action | |---------|------------|--------| | "No, do X instead" | High | Log correction immediately | | "I told you before..." | High | Flag as repeated, bump priority | | "Always/Never do X" | Confirmed | Promote to preference | | User edits your output | Medium | Log as tentative pattern | | Same correction 3x | Confirmed | Ask to make permanent | | "For this project..." | Scoped | Write to project namespace |

What Does NOT Trigger Learning

• Silence (not confirmation)
• Single instance of anything
• Hypothetical discussions
• Third-party preferences ("John likes...")
• Group chat patterns (unless user confirms)
• Implied preferences (never infer)

Correction Classification

By Type

| Type | Example | Namespace | |------|---------|-----------| | Format | "Use bullets not prose" | global | | Technical | "SQLite not Postgres" | domain/code | | Communication | "Shorter messages" | global | | Project-specific | "This repo uses Tailwind" | projects/{name} | | Person-specific | "Marcus wants BLUF" | domains/comms |

By Scope

Global: applies everywhere
  └── Domain: applies to category (code, writing, comms)
       └── Project: applies to specific context
            └── Temporary: applies to this session only

Confirmation Flow

After 3 similar corrections:

Agent: "I've noticed you prefer X over Y (corrected 3 times).
        Should I always do this?
        - Yes, always
        - Only in [context]
        - No, case by case"

User: "Yes, always"

Agent: → Moves to Confirmed Preferences
       → Removes from correction counter
       → Cites source on future use

Pattern Evolution

Stages

1. Tentative — Single correction, watch for repetition
2. Emerging — 2 corrections, likely pattern
3. Pending — 3 corrections, ask for confirmation
4. Confirmed — User approved, permanent unless reversed
5. Archived — Unused 90+ days, preserved but inactive

Reversal

User can always reverse:

User: "Actually, I changed my mind about X"

Agent: 
1. Archive old pattern (keep history)
2. Log reversal with timestamp
3. Add new preference as tentative
4. "Got it. I'll do Y now. (Previous: X, archived)"

Anti-Patterns

Never Learn

• What makes user comply faster (manipulation)
• Emotional triggers or vulnerabilities
• Patterns from other users (even if shared device)
• Anything that feels "creepy" to surface

Avoid

• Over-generalizing from single instance
• Learning style over substance
• Assuming preference stability
• Ignoring context shifts

Quality Signals

Good Learning

• User explicitly states preference
• Pattern consistent across contexts
• Correction improves outcomes
• User confirms when asked

Bad Learning

• Inferred from silence
• Contradicts recent behavior
• Only works in narrow context
• User never confirmed

File v1.2.11:memory-template.md

Memory Template

Copy this structure to ~/self-improving/memory.md on first use.

# Self-Improving Memory

## Confirmed Preferences
<!-- Patterns confirmed by user, never decay -->

## Active Patterns
<!-- Patterns observed 3+ times, subject to decay -->

## Recent (last 7 days)
<!-- New corrections pending confirmation -->

Initial Directory Structure

Create on first activation:

mkdir -p ~/self-improving/{projects,domains,archive}
touch ~/self-improving/{memory.md,index.md,corrections.md}

Index Template

For ~/self-improving/index.md:

# Memory Index

## HOT
- memory.md: 0 lines

## WARM
- (no namespaces yet)

## COLD
- (no archives yet)

Last compaction: never

Corrections Log Template

For ~/self-improving/corrections.md:

# Corrections Log

<!-- Format:
## YYYY-MM-DD
- [HH:MM] Changed X → Y
  Type: format|technical|communication|project
  Context: where correction happened
  Confirmed: pending (N/3) | yes | no
-->

File v1.2.11:memory.md

HOT Memory — Template

This file is created in ~/self-improving/memory.md when you first use the skill. Keep it ≤100 lines. Most-used patterns live here.

Example Entries

## Preferences
- Code style: Prefer explicit over implicit
- Communication: Direct, no fluff
- Time zone: Europe/Madrid

## Patterns (promoted from corrections)
- Always use TypeScript strict mode
- Prefer pnpm over npm
- Format: ISO 8601 for dates

## Project defaults
- Tests: Jest with coverage >80%
- Commits: Conventional commits format

Usage

The agent will:

1. Load this file on every session
2. Add entries when patterns are used 3x in 7 days
3. Demote unused entries to WARM after 30 days
4. Never exceed 100 lines (compacts automatically)

File v1.2.11:operations.md

Memory Operations

User Commands

| Command | Action | |---------|--------| | "What do you know about X?" | Search all tiers, return matches with sources | | "Show my memory" | Display memory.md contents | | "Show [project] patterns" | Load and display specific namespace | | "Forget X" | Remove from all tiers, confirm deletion | | "Forget everything" | Full wipe with export option | | "What changed recently?" | Show last 20 corrections | | "Export memory" | Generate downloadable archive | | "Memory status" | Show tier sizes, last compaction, health |

Automatic Operations

On Session Start

1. Load memory.md (HOT tier)
2. Check index.md for context hints
3. If project detected → preload relevant namespace

On Correction Received

1. Parse correction type (preference, pattern, override)
2. Check if duplicate (exists in any tier)
3. If new:
   - Add to corrections.md with timestamp
   - Increment correction counter
4. If duplicate:
   - Bump counter, update timestamp
   - If counter >= 3: ask to confirm as rule
5. Determine namespace (global, domain, project)
6. Write to appropriate file
7. Update index.md line counts

On Pattern Match

When applying learned pattern:

1. Find pattern source (file:line)
2. Apply pattern
3. Cite source: "Using X (from memory.md:15)"
4. Log usage for decay tracking

Weekly Maintenance (Cron)

1. Scan all files for decay candidates
2. Move unused >30 days to WARM
3. Archive unused >90 days to COLD
4. Run compaction if any file >limit
5. Update index.md
6. Generate weekly digest (optional)

File Formats

memory.md (HOT)

# Self-Improving Memory

## Confirmed Preferences
- format: bullet points over prose (confirmed 2026-01)
- tone: direct, no hedging (confirmed 2026-01)

## Active Patterns
- "looks good" = approval to proceed (used 15x)
- single emoji = acknowledged (used 8x)

## Recent (last 7 days)
- prefer SQLite for MVPs (corrected 02-14)

corrections.md

# Corrections Log

## 2026-02-15
- [14:32] Changed verbose explanation → bullet summary
  Type: communication
  Context: Telegram response
  Confirmed: pending (1/3)

## 2026-02-14
- [09:15] Use SQLite not Postgres for MVP
  Type: technical
  Context: database discussion
  Confirmed: yes (said "always")

projects/{name}.md

# Project: my-app

Inherits: global, domains/code

## Patterns
- Use Tailwind (project standard)
- No Prettier (eslint only)
- Deploy via GitLab CI

## Overrides
- semicolons: yes (overrides global no-semi)

## History
- Created: 2026-01-15
- Last active: 2026-02-15
- Corrections: 12

Edge Case Handling

Contradiction Detected

Pattern A: "Use tabs" (global, confirmed)
Pattern B: "Use spaces" (project, corrected today)

Resolution:
1. Project overrides global → use spaces for this project
2. Log conflict in corrections.md
3. Ask: "Should spaces apply only to this project or everywhere?"

User Changes Mind

Old: "Always use formal tone"
New: "Actually, casual is fine"

Action:
1. Archive old pattern with timestamp
2. Add new pattern as tentative
3. Keep archived for reference ("You previously preferred formal")

Context Ambiguity

User says: "Remember I like X"

But which namespace?
1. Check current context (project? domain?)
2. If unclear, ask: "Should this apply globally or just here?"
3. Default to most specific active context

File v1.2.11:reflections.md

Self-Reflections Log

Track self-reflections from completed work. Each entry captures what the agent learned from evaluating its own output.

Format

## [Date] — [Task Type]

**What I did:** Brief description
**Outcome:** What happened (success, partial, failed)
**Reflection:** What I noticed about my work
**Lesson:** What to do differently next time
**Status:** ⏳ candidate | ✅ promoted | 📦 archived

Example Entry

## 2026-02-25 — Flutter UI Build

**What I did:** Built a settings screen with toggle switches
**Outcome:** User said "spacing looks off"
**Reflection:** I focused on functionality, didn't visually check the result
**Lesson:** Always take a screenshot and evaluate visual balance before showing user
**Status:** ✅ promoted to domains/flutter.md

Entries

(New entries appear here)

File v1.2.11:scaling.md

Scaling Patterns

Volume Thresholds

| Scale | Entries | Strategy | |-------|---------|----------| | Small | <100 | Single memory.md, no namespacing | | Medium | 100-500 | Split into domains/, basic indexing | | Large | 500-2000 | Full namespace hierarchy, aggressive compaction | | Massive | >2000 | Archive yearly, summary-only HOT tier |

When to Split

Create new namespace file when:

• Single file exceeds 200 lines
• Topic has 10+ distinct corrections
• User explicitly separates contexts ("for work...", "in this project...")

Compaction Rules

Merge Similar Corrections

BEFORE (3 entries):
- [02-01] Use tabs not spaces
- [02-03] Indent with tabs
- [02-05] Tab indentation please

AFTER (1 entry):
- Indentation: tabs (confirmed 3x, 02-01 to 02-05)

Summarize Verbose Patterns

BEFORE:
- When writing emails to Marcus, use bullet points, keep under 5 items,
  no jargon, bottom-line first, he prefers morning sends

AFTER:
- Marcus emails: bullets ≤5, no jargon, BLUF, AM preferred

Archive with Context

When moving to COLD:

## Archived 2026-02

### Project: old-app (inactive since 2025-08)
- Used Vue 2 patterns
- Preferred Vuex over Pinia
- CI on Jenkins (deprecated)

Reason: Project completed, patterns unlikely to apply

Index Maintenance

index.md tracks all namespaces:

# Memory Index

## HOT (always loaded)
- memory.md: 87 lines, updated 2026-02-15

## WARM (load on match)
- projects/current-app.md: 45 lines
- projects/side-project.md: 23 lines
- domains/code.md: 112 lines
- domains/writing.md: 34 lines

## COLD (archive)
- archive/2025.md: 234 lines
- archive/2024.md: 189 lines

Last compaction: 2026-02-01
Next scheduled: 2026-03-01

Multi-Project Patterns

Inheritance Chain

global (memory.md)
  └── domain (domains/code.md)
       └── project (projects/app.md)

Override Syntax

In project file:

## Overrides
- indentation: spaces (overrides global tabs)
- Reason: Project eslint config requires spaces

Conflict Detection

When loading, check for conflicts:

1. Build inheritance chain
2. Detect contradictions
3. Most specific wins
4. Log conflict for later review

User Type Adaptations

| User Type | Memory Strategy | |-----------|-----------------| | Power user | Aggressive learning, minimal confirmation | | Casual | Conservative learning, frequent confirmation | | Team shared | Per-user namespaces, shared project space | | Privacy-focused | Local-only, explicit consent per category |

Recovery Patterns

Context Lost

If agent loses context mid-session:

1. Re-read memory.md
2. Check index.md for relevant namespaces
3. Load active project namespace
4. Continue with restored patterns

Corruption Recovery

If memory file corrupted:

1. Check archive/ for recent backup
2. Rebuild from corrections.md
3. Ask user to re-confirm critical preferences
4. Log incident for debugging

File v1.2.11:setup.md

Setup — Self-Improving Agent

First-Time Setup

1. Create Memory Structure

mkdir -p ~/self-improving/{projects,domains,archive}

2. Initialize Core

Archive v1.2.10: 11 files, 14538 bytes

Files: boundaries.md (2236b), corrections.md (1026b), learning.md (2951b), memory-template.md (1014b), memory.md (756b), operations.md (3435b), reflections.md (840b), scaling.md (2945b), setup.md (5040b), SKILL.md (6740b), _meta.json (134b)

Archive v1.2.9: 11 files, 14325 bytes

Files: boundaries.md (2236b), corrections.md (1026b), learning.md (2951b), memory-template.md (1014b), memory.md (756b), operations.md (3435b), reflections.md (840b), scaling.md (2945b), setup.md (4497b), SKILL.md (6693b), _meta.json (133b)

Archive v1.2.8: 11 files, 14382 bytes

Files: boundaries.md (2236b), corrections.md (1026b), learning.md (2951b), memory-template.md (1014b), memory.md (756b), operations.md (3435b), reflections.md (840b), scaling.md (2945b), setup.md (4540b), SKILL.md (6750b), _meta.json (133b)

Archive v1.2.7: 11 files, 14004 bytes

Files: boundaries.md (2236b), corrections.md (1026b), learning.md (2951b), memory-template.md (1014b), memory.md (756b), operations.md (3435b), reflections.md (840b), scaling.md (2945b), setup.md (3589b), SKILL.md (6717b), _meta.json (133b)