Self-Improvement Skill
Log learnings and errors to markdown files for continuous improvement. Agents can later process these into fixes, and important learnings get promoted to workspace memory. This version of the skill is built for OpenClaw only — for other agents, see the original multi-agent version at
https://github.com/pskoett/pskoett-ai-skills.
Capture, review, reuse, promotion, and maintenance are self-contained here: no companion skill, service, plugin, memory backend, or OpenClaw core change is required. The optional hook only reminds and captures possible errors; it does not enforce this workflow or revalidate claims.
First-Use Initialisation
Before logging anything, ensure the
directory and files exist in the project or workspace root. If any are missing, create them:
bash
mkdir -p .learnings
[ -f .learnings/LEARNINGS.md ] || printf "# Learnings\n\nCorrections, insights, and knowledge gaps captured during development.\n\n**Categories**: correction | insight | knowledge_gap | best_practice\n\n---\n" > .learnings/LEARNINGS.md
[ -f .learnings/ERRORS.md ] || printf "# Errors\n\nCommand failures and integration errors.\n\n---\n" > .learnings/ERRORS.md
[ -f .learnings/FEATURE_REQUESTS.md ] || printf "# Feature Requests\n\nCapabilities requested by the user.\n\n---\n" > .learnings/FEATURE_REQUESTS.md
Never overwrite existing files. This is a no-op if
is already initialised.
Do not log secrets, tokens, private keys, environment variables, or full source/config files unless the user explicitly asks for that level of detail. Prefer short summaries or redacted excerpts over raw command output or full transcripts.
If you want automatic reminders and session-end error detection, enable the opt-in hook described in
Optional: Enable Hook.
Quick Reference
| Situation | Action |
|---|
| Command/operation fails | Log to |
| User corrects you | Log to with category |
| User wants missing feature | Log to .learnings/FEATURE_REQUESTS.md
|
| API/external tool fails | Log to with integration details |
| Knowledge was outdated | Log to with category |
| Found better approach | Log to with category |
| Simplify/Harden recurring patterns | Log/update with Source: simplify-and-harden
|
| Similar to existing entry | Search by , confirm the same claim/scope; count only a new occurrence |
| Reusing or promoting saved knowledge | Review relevant/due claims using Maintenance below, including one-off/unpromoted entries |
| Source, decision, dependency, or task changes | Revalidate affected claims; do not expire them by age |
| Workflow improvements | Promote to (workspace) |
| Tool gotchas | Promote to (workspace) |
| Behavioral patterns | Promote to (workspace) |
OpenClaw Setup
OpenClaw uses workspace-based prompt injection with automatic skill loading.
Installation
Via OpenClaw's built-in installer (recommended) — installs into the
active OpenClaw workspace:
bash
openclaw skills install @pskoett/self-improving-agent
Via the ClawHub CLI (
) — installs into
under the current working directory, not the workspace:
bash
clawhub install @pskoett/self-improving-agent
Manual (the skill lives in the repo's
subfolder;
copy that folder, not the repo root):
bash
git clone https://github.com/pskoett/self-improving-agent.git /tmp/self-improving-agent-repo
cp -r /tmp/self-improving-agent-repo/self-improving-agent ~/.openclaw/skills/self-improving-agent
Workspace Structure
OpenClaw injects these files into every session:
~/.openclaw/workspace/
├── AGENTS.md # Multi-agent workflows, delegation patterns
├── SOUL.md # Behavioral guidelines, personality, principles
├── TOOLS.md # Tool capabilities, integration gotchas
├── MEMORY.md # Long-term memory (main session only)
├── memory/ # Daily memory files
│ └── YYYY-MM-DD.md
└── .learnings/ # This skill's log files
├── LEARNINGS.md
├── ERRORS.md
└── FEATURE_REQUESTS.md
Create Learning Files
bash
mkdir -p ~/.openclaw/workspace/.learnings
Then create the log files (or copy from
):
- — corrections, knowledge gaps, best practices
- — command failures, exceptions
- — user-requested capabilities
Promotion Targets
When learnings prove broadly applicable, promote them to workspace files:
| Learning Type | Promote To | Example |
|---|
| Behavioral patterns | | "Be concise, avoid disclaimers" |
| Workflow improvements | | "Spawn sub-agents for long tasks" |
| Tool gotchas | | "Git push needs auth configured first" |
Inter-Session Communication
OpenClaw provides tools to share learnings across sessions:
- sessions_list — View active/recent sessions
- sessions_history — Read another session's transcript
- sessions_send — Send a learning to another session
- sessions_spawn — Spawn a sub-agent for background work
Use these only in trusted environments and only when the user explicitly wants cross-session sharing. Prefer sending a short sanitized summary and relevant file paths, not raw transcripts, secrets, or full command output.
Optional: Enable Hook
For automatic reminders at session start and error detection at session end,
follow
Install or Upgrade the Hook,
then enable with
openclaw hooks enable self-improvement
. Select the actual
skill/hook paths, review local patches, and preserve the old copy before replacing it.
Fires on
(injects the reminder, plus a pending-triage note
when auto-detected errors await review) and on
/
(sweeps the ended session's transcript for error patterns into
<workspace>/.learnings/ERRORS.md
; opt-in — runs only when
exists). Internal
events have no per-tool-call callback, so this
integration detects errors at session end. OpenClaw's typed plugin hooks
separately expose
. See
hook systems and limitations.
Logging Format
Append an entry using the templates in assets/LEARNINGS.md, assets/ERRORS.md, or assets/FEATURE_REQUESTS.md. Keep the observation, context, suggested action, and metadata. See examples for completed entries.
At capture, add the Maintenance block below for each reusable claim. If no inference is established yet, record
Claim: unknown — needs triage
rather than inventing a rule. Legacy entries remain valid log records: initialize metadata only when captured or touched in relevant review, without bulk migration.
Maintenance: Cause-Aware Context Decay
Historical observations do not expire. Maintain the reusable inference or instruction, not whether the incident happened. This applies to all three
files, including one-off and unpromoted entries. Truth and usefulness are separate: a true fact may be irrelevant to this task; a useful workaround may no longer be correct.
Type determines HOW to revalidate
| Type | Check |
|---|
| Read the current authoritative source or inspect the current environment for the scoped fact. |
| Find an authoritative, applicable superseding decision; confirm its scope and effective state. Age or a different team's choice does not supersede it. |
| Establish the relevant version/configuration, then perform representative behavioral verification in that environment. An upgrade triggers a check, not automatic retirement. |
| Assess applicability and usefulness for the current task/project. Disuse does not prove falsehood. |
Use
when the cause is not established. If a claim has multiple causes, check each or split distinct claims into named Maintenance blocks. Do not infer semantic type/rate from priority, status, recurrence, or
regex matches. Session sweeps may mix unrelated errors: classify claims during triage, preserving and linking the original sweep.
Rate determines WHEN to review
- : volatile; check near each relevant use.
- : revisit at relevant task/project milestones during active work.
- : stable; review occasionally at relevant major changes or milestones.
- : expected to persist; review when authority, assumptions, or applicability is challenged.
- : no supported cadence yet; triage before relying on it.
These are qualitative rates, not universal half-lives, expiry dates, or deletion rules. Record a concrete trigger for the claim. Relevant events (source updates, superseding decisions, dependency/configuration changes, project/task shifts, contradictions) override cadence, even for
claims. No scheduler or autonomous background revalidation is needed.
Lightweight metadata beside the original entry
markdown
### Maintenance
- Claim: reusable inference/instruction, or unknown — needs triage
- Scope: applicable project/task/environment and limits, or unknown
- Authority: source path/section, decision ID, environment, or unknown
- Decay: reality | decision | dependency | relevance | unknown / fast | medium | slow | durable | unknown
- Revalidate: event/cadence; specific check to perform
- Validation: pending | verified | unresolved | contradicted
- Evidence: none yet; when checked, actual date, source/version/configuration, check and result (including failures/conflicts)
- Disposition: retain | revise | externalize | retire; reason and task applicability
- Guidance: none, or target file + section and source-learning ID
Start with
,
, and
Disposition: retain — provisional, not validated
unless actual evidence supports more. An attempted review is not validation: unavailable or conflicting evidence stays
, with the attempt date, blocker, and next check; do not advance a successful validation date. Keep past evidence dated and scoped when appending later results.
tracks issue resolution/promotion,
tracks support for the claim, and
tracks active guidance; none implies the others.
Review, reuse, and promotion loop
- Select entries relevant to the current task by area, files, keywords, or source IDs, plus affected/due claims at natural breakpoints. Do not audit the whole log every turn or select only pending/promoted/repeated entries.
- Triage legacy/mixed entries: identify the reusable claim, scope, authority, type/rate, and trigger. Keep unknowns explicit. A resolved incident, successful recovery, or repeated occurrence does not prove a universally valid rule.
- Check applicability and whether the trigger fired or evidence is due before reuse or promotion. Run the type-appropriate check when needed; record actual evidence, not an intended command. If evidence is missing/conflicting, do not present or promote the claim as verified. State uncertainty and seek the source or use an appropriately scoped fallback; do not remove safeguards while blocked.
- Choose (supported and useful, or explicitly provisional while blocked), (correct/narrow with evidence), (replace volatile detail with a usable retrieval instruction), or (exclude from active guidance with an evidenced reason). Externalization names where to look, what to read/test, and what to do if inaccessible/conflicting; a vague “check docs” is insufficient. Verify that the retrieval path is usable before treating it as validated.
- Record and propagate: append a dated review note with the outcome, reason, evidence, and old → new claim when changed. Preserve original observations, resolution, promotion targets/dates, and prior reviews. Update affected promoted guidance using its source link; keep its source-learning ID beside the revised rule (or a retirement note pointing to the preserved history). Never inflate / just because a review ran.
Never erase learning/promotion history or delete by age. Never change user preferences, weaken security policies, or rewrite skill assets merely because they are old or unused. Skill creation/modification requires explicit scoped approval; approval for this integration does not authorize future skill rewrites. If a needed target edit is outside granted scope, record the proposed change as pending in the source entry and report the still-active guidance rather than silently claiming it is updated.
For worked review outcomes and provenance, read maintenance examples.
To evaluate the maintenance instructions, use the isolated scenarios in
maintenance behavioral evaluations.
These are evaluation fixtures, not checks to run during ordinary learning capture.
ID Generation
- TYPE: (learning), (error), (feature)
- YYYYMMDD: Current date
- XXX: Sequential number or random 3 chars (e.g., , )
Resolving Entries
When an issue is fixed, update the entry:
- Change →
- Add resolution block after Metadata:
markdown
### Resolution
- **Resolved**: 2025-01-16T09:00:00Z
- **Commit/PR**: abc123 or #42
- **Notes**: Brief description of what was done
Other status values:
- - Actively being worked on
- - Decided not to address (add reason in Resolution notes)
- - Elevated to a workspace file (, , )
Keep the Resolution block when promoting. A working fix establishes what happened in that incident; validate any reusable rule separately through Maintenance.
Promoting to Workspace Memory
When a learning is broadly applicable (not a one-off fix), promote it to a workspace file so every session inherits it.
When to Promote
- Learning applies across multiple files/features
- Knowledge any contributor (human or AI) should know
- Prevents recurring mistakes
- Documents project-specific conventions
Promotion Targets
| Target | What Belongs There |
|---|
| Behavioral guidelines, communication style, principles |
| Tool capabilities, usage patterns, integration gotchas |
| Workflows, delegation patterns, automation rules |
When the learning is specific to a project repo you work in (not the
workspace), promote to that project's own agent file (e.g. its
)
instead.
How to Promote
- Review the scoped claim through Maintenance first. Promote only supported, useful guidance, not unresolved assumptions or recurrence alone.
- Distill and add a concise scoped rule or usable retrieval instruction to the appropriate target. Include
Source: .learnings/<file>.md#<entry-ID>
- Update the original entry: set , append the promotion date and target file/section, and set to that location. Preserve any resolution and earlier promotion history. Future revisions follow this two-way link.
Promotion Examples
Learning (verbose):
Project uses pnpm workspaces. Attempted
but failed.
Lock file is
. Must use
.
In TOOLS.md (externalized after checking the retrieval path):
markdown
## Build & Dependencies
- Before installing, read this repo's `package.json` `packageManager` field and lockfile. Use the declared manager; if missing or conflicting, consult the build instructions/maintainer before installing. Source: .learnings/LEARNINGS.md#LRN-20250115-002
Learning (verbose):
When modifying API endpoints, must regenerate TypeScript client.
Forgetting this causes type mismatches at runtime.
In AGENTS.md (actionable):
markdown
## After API Changes
1. Regenerate client: `pnpm run generate:api`
2. Check for type errors: `pnpm tsc --noEmit`
Source: .learnings/LEARNINGS.md#LRN-20250116-001 (scope: this repo's current generator/configuration)
Pattern-Key Taxonomy
is the stable dedup and recurrence key for entries in all three
log files: keyword grep misses semantically identical but differently-worded
entries, a shared key does not — and reliable keys are what make
and the promotion rule work.
Format:
— exactly two levels, lowercase, hyphenated
(e.g.
). Keep symptoms generic enough to recur: no
file names, versions, or hostnames in keys.
| Area | Scope | Example Keys |
|---|
| External API/service behavior | , , |
| Credentials, tokens, scopes | , |
| Compilation, bundling, CI | , |
| Config files, env vars, settings | , |
| Package managers, dependencies | , , |
| Filesystem | , |
| Network connectivity | , |
| Language/runtime errors not covered above | , |
| Shell/CLI mechanics | , |
| Git and other version control | , |
| / | Code-quality patterns from the simplify-and-harden feed | , |
Rules:
- Reuse before minting:
grep -rh "Pattern-Key:" .learnings/ | sort -u
- One key per manual entry; auto-swept OpenClaw entries may carry
several — triage unrelated claims separately and link to the preserved sweep.
- Mint new areas sparingly — only when several entries would share one.
- Generic sweep keys (, ) mean
"unclassified" — replace with a specific key during triage.
Recurring Pattern Detection
If logging something similar to an existing entry:
- Search by key first:
grep -n "Pattern-Key: area.symptom" .learnings/*.md
- Fallback keyword search:
grep -ri "keyword" .learnings/
- Fold, don't duplicate: confirm the same claim and scope, not just a key
match. For a genuinely new occurrence, bump , set
, and link the evidence; review/re-reading is not recurrence
- Bump priority if issue keeps recurring
- Consider systemic fix: Recurring issues often indicate:
- Missing knowledge (→ promote to or )
- Missing automation (→ add to )
- Architectural problem (→ create tech debt ticket)
Simplify & Harden Feed
If a task supplies simplify/harden candidates, ingest them here; no other skill
is required. Manual capture uses the same recurrence and maintenance rules.
Ingestion Workflow
- Read
simplify_and_harden.learning_loop.candidates
- For each candidate, use as the stable dedupe key.
- Search for an existing entry with that key:
grep -n "Pattern-Key: <pattern_key>" .learnings/LEARNINGS.md
- If found:
- Increment and update only for a new occurrence of the same scoped claim
- Add links to related entries/tasks
- If not found:
- Create a new entry
- Set
Source: simplify-and-harden
- Set , , and /
Promotion Rule (System Prompt Feedback)
Consider recurring patterns for promotion when all are true:
- Seen across at least 2 distinct tasks
- Occurred within a 30-day window
These are candidate signals, not proof or expiry rules. Apply Maintenance before promotion; one-off learnings still receive maintenance without meeting these thresholds.
Promotion targets:
,
, or
(workspace), or the
project's own agent file when the pattern is project-specific.
Write promoted rules as short prevention rules (what to do before/while coding),
not long incident write-ups.
Periodic Review
Review relevant/due claims using Maintenance at natural breakpoints; not the entire log every turn:
When to Review
- Before starting a new major task
- After completing a feature
- When working in an area with past learnings
- Weekly during active development
Quick Status Check
bash
# Count pending items
grep -h "Status\*\*: pending" .learnings/*.md | wc -l
# List pending high-priority items
grep -B5 "Priority\*\*: high" .learnings/*.md | grep "^## \["
# Find learnings for a specific area
grep -l "Area\*\*: backend" .learnings/*.md
Review Actions
- Resolve fixed items
- Revalidate relevant/due claims of any status, including one-off/unpromoted learnings
- Retain, revise, externalize, or retire active guidance while preserving history
- Promote supported, applicable learnings with source links
- Link related entries
- Escalate recurring issues
Detection Triggers
Evaluate the event in context before logging. The phrases below are cues,
not automatic logging commands; ordinary questions and follow-up tasks alone
do not justify persistent entries.
Corrections (→ learning with
category):
- "No, that's not right..."
- "Actually, it should be..."
- "You're wrong about..."
- "That's outdated..."
Feature Requests (→ feature request):
- Log only a requested capability shown to be missing from the relevant tool/version. Record evidence and limits.
- "Can you also..." or "Is there a way to..." is not evidence of a missing feature. Use existing capabilities normally; do not log ordinary follow-ups.
- If availability is unclear, check documentation or tool behavior, or ask. Do not create a feature request based on wording alone.
Knowledge Gaps (→ learning with
category):
- User provides information you didn't know
- Documentation you referenced is outdated
- API behavior differs from your understanding
Errors (→ error entry):
- Command returns non-zero exit code
- Exception or stack trace
- Unexpected output or behavior
- Timeout or connection failure
Priority Guidelines
| Priority | When to Use |
|---|
| Blocks core functionality, data loss risk, security issue |
| Significant impact, affects common workflows, recurring issue |
| Moderate impact, workaround exists |
| Minor inconvenience, edge case, nice-to-have |
Area Tags
Use to filter learnings by codebase region:
| Area | Scope |
|---|
| UI, components, client-side code |
| API, services, server-side code |
| CI/CD, deployment, Docker, cloud |
| Test files, testing utilities, coverage |
| Documentation, comments, READMEs |
| Configuration files, environment, settings |
Best Practices
- Log immediately - context is freshest right after the issue
- Be specific - future agents need to understand quickly
- Include reproduction steps - especially for errors
- Link related files - makes fixes easier
- Suggest concrete fixes - not just "investigate"
- Use consistent categories - enables filtering
- Promote supported guidance - validate scope and usefulness first; preserve provenance
- Review by cause and rate - age alone proves neither falsehood nor uselessness
Gitignore Options
Keep learnings local (per-developer):
This repo uses that default to avoid committing sensitive or noisy local logs by accident.
Track learnings in repo (team-wide):
Don't add to .gitignore - learnings become shared knowledge.
Hybrid (track templates, ignore entries):
gitignore
.learnings/*.md
!.learnings/.gitkeep
Upgrading & Uninstalling
Read
before upgrading — it carries per-version notes, and
hook changes require re-copying the hook and restarting the gateway.
To disable or remove the skill, follow
:
disabling and uninstalling preserve
and promoted workspace rules.
Permanent data deletion or edits to promoted guidance require separate,
explicit authorization; they are not part of uninstalling.
Skill Extraction (Approval Required)
When a learning may justify a reusable skill, use assets/SKILL-TEMPLATE.md. Extracting is optional, never a dependency of maintenance. Obtain explicit scoped approval before creating or modifying skill assets.
The template includes candidate criteria, helper commands, quality gates, and two-way provenance. Review the scoped claim before extraction; a resolved incident or recurrence alone is not verification. Later asset changes require their own scoped approval.