self-improvement

name

self-improvement

description

Captures learnings, errors, corrections, and feature requests to enable continuous improvement. Use when: (1) User corrects Claude ('No, that's wrong...', 'Actually...'), (2) User requests a capability that doesn't exist, (3) Claude realizes its knowledge is outdated or incorrect, (4) A better approach is discovered for a recurring task, (5) Receiving a Handoff block from self-healing (a recurring verified heal with a Recurrence-Count of at least 3) to distill into a memory file or new skill. For ACTIVE runtime failures where the agent needs to apply and verify a fix mid-task, use `self-healing` instead (it files HEAL- entries with proof; self-improvement promotes accumulated patterns). Also review learnings before major tasks. For CI-only/headless learning capture, use self-improvement-ci.

Self-Improvement Skill

Install

gh skill install pskoett/pskoett-skills self-improvement

For CI-only execution, use:

gh skill install pskoett/pskoett-skills self-improvement-ci

Fallback using the Agent Skills CLI:

npx skills add pskoett/pskoett-skills/skills/self-improvement
npx skills add pskoett/pskoett-skills/skills/self-improvement-ci

Log learnings and errors to markdown files for continuous improvement. Coding agents can later process these into fixes, and important learnings get promoted to project memory.

Pair with self-healing: self-healing is the active runtime recovery primitive — it diagnoses, patches, verifies, and files HEAL- entries to .learnings/HEALS.md when something breaks mid-task. Self-improvement (this skill) is the passive accumulation and promotion layer — it logs corrections, knowledge gaps, and feature requests, and promotes recurring heal handoffs to permanent memory. They share .learnings/ but write to different files; verify discipline lives in self-healing, promotion logic lives here.

Quick Reference

Situation	Action
Active failure mid-task — agent needs to fix it now	Use self-healing instead (files verified HEAL- to .learnings/HEALS.md)
Command/operation failed in the past (not actively healing)	Log to .learnings/ERRORS.md
User corrects you	Log to .learnings/LEARNINGS.md with category correction
User wants missing feature	Log to .learnings/FEATURE_REQUESTS.md
API/external tool fails	Log to .learnings/ERRORS.md with integration details
Self-healing Handoff block meets promotion rule (see Promotion Rule below)	Promote the Distilled Rule to CLAUDE.md / AGENTS.md / new skill
Knowledge was outdated	Log to .learnings/LEARNINGS.md with category knowledge_gap
Found better approach	Log to .learnings/LEARNINGS.md with category best_practice
Simplify/Harden recurring patterns	Log/update .learnings/LEARNINGS.md with Source: simplify-and-harden and a stable Pattern-Key
Same Pattern-Key already exists	Update that entry's recurrence metadata instead of appending a duplicate learning
Related but distinct pattern exists	Link it with See Also; do not reuse its Pattern-Key
Broadly applicable learning	Promote to CLAUDE.md, AGENTS.md, and/or .github/copilot-instructions.md
OpenClaw workspace targets (SOUL.md, TOOLS.md)	See references/openclaw-integration.md

Setup

Keep learning storage centralized. Do not create a real .learnings/ directory directly inside an individual repo. If a repo needs .learnings, create the real directory under ~/dotfiles/learnings/<repo-name>/.learnings and symlink the repo-local .learnings to it.

Use the repository directory name as <repo-name> unless the user specifies a different stable name:

mkdir -p "$HOME/dotfiles/learnings/$(basename "$PWD")/.learnings"
ln -s "$HOME/dotfiles/learnings/$(basename "$PWD")/.learnings" .learnings

Copy the file templates from assets/ (LEARNINGS.md, ERRORS.md, FEATURE_REQUESTS.md) or create files with headers.

Logging Format

Learning Entry

Append to .learnings/LEARNINGS.md:

## [LRN-YYYYMMDD-XXX] category

**Logged**: ISO-8601 timestamp
**Priority**: low | medium | high | critical
**Status**: pending
**Area**: frontend | backend | infra | tests | docs | config

### Summary
One-line description of what was learned

### Details
Full context: what happened, what was wrong, what's correct

### Suggested Action
Specific fix or improvement to make

### Metadata
- Source: conversation | error | user_feedback
- Related Files: path/to/file.ext
- Tags: tag1, tag2
- Pattern-Key: stable.semantic_key
- Recurrence-Count: 1
- First-Seen: 2025-01-15
- Last-Seen: 2025-01-15
- Task-Keys: conversation:20250115-api-timeout
- See Also: LRN-20250110-001 (optional; only for related but distinct patterns)

---

Error Entry

Append to .learnings/ERRORS.md:

## [ERR-YYYYMMDD-XXX] skill_or_command_name

**Logged**: ISO-8601 timestamp
**Priority**: high
**Status**: pending
**Area**: frontend | backend | infra | tests | docs | config

### Summary
Brief description of what failed

### Error

Actual error message or output

### Context
- Command/operation attempted
- Input or parameters used
- Environment details if relevant

### Suggested Fix
If identifiable, what might resolve this

### Metadata
- Reproducible: yes | no | unknown
- Related Files: path/to/file.ext
- See Also: ERR-20250110-001 (if recurring)

---

Feature Request Entry

Append to .learnings/FEATURE_REQUESTS.md:

## [FEAT-YYYYMMDD-XXX] capability_name

**Logged**: ISO-8601 timestamp
**Priority**: medium
**Status**: pending
**Area**: frontend | backend | infra | tests | docs | config

### Requested Capability
What the user wanted to do

### User Context
Why they needed it, what problem they're solving

### Complexity Estimate
simple | medium | complex

### Suggested Implementation
How this could be built, what it might extend

### Metadata
- Frequency: first_time | recurring
- Related Features: existing_feature_name

---

ID Generation

Format: TYPE-YYYYMMDD-XXX

• TYPE: LRN (learning), ERR (error), FEAT (feature)
• YYYYMMDD: Current date
• XXX: Three-digit sequence generated from the IDs already present in the current .learnings directory

Examples: LRN-20250115-001, ERR-20250115-002, FEAT-20250115-003

Generate an ID before appending any entry:

<self-improvement-skill>/scripts/next-entry-id.sh LRN --dir .learnings

Use ERR or FEAT for the other entry types. The helper scans every Markdown file in the storage directory, returns the next sequential ID for the date, and refuses to issue an ID while any duplicate ID exists. Do not guess a sequence or reuse an ID returned in an earlier task.

Resolving Entries

When an issue is fixed, update the entry:

1. Change **Status**: pending → **Status**: resolved
2. Add resolution block after Metadata:

### Resolution
- **Resolved**: 2025-01-16T09:00:00Z
- **Commit/PR**: abc123 or #42
- **Notes**: Brief description of what was done

Other status values:

• in_progress - Actively being worked on
• wont_fix - Decided not to address (add reason in Resolution notes)
• promoted - Elevated to CLAUDE.md, AGENTS.md, or .github/copilot-instructions.md
• promoted_to_skill - Extracted as a reusable skill (see Automatic Skill Extraction)

Promoting to Project Memory

When a learning is broadly applicable (not a one-off fix), promote it to permanent project memory.

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
CLAUDE.md	Project facts, conventions, gotchas for all Claude interactions
AGENTS.md	Agent-specific workflows, tool usage patterns, automation rules
.github/copilot-instructions.md	Project context and conventions for GitHub Copilot

OpenClaw workspace targets (SOUL.md, TOOLS.md) are covered in references/openclaw-integration.md.

How to Promote

1. Distill the learning into a concise rule or fact
2. Add to appropriate section in target file (create file if needed)
3. Update original entry:
   • Change **Status**: pending → **Status**: promoted
   • Add **Promoted**: CLAUDE.md, AGENTS.md, or .github/copilot-instructions.md

Promotion Examples

Learning (verbose):

Project uses pnpm workspaces. Attempted npm install but failed. Lock file is pnpm-lock.yaml. Must use pnpm install.

In CLAUDE.md (concise):

## Build & Dependencies
- Package manager: pnpm (not npm) - use `pnpm install`

Learning (verbose):

When modifying API endpoints, must regenerate TypeScript client. Forgetting this causes type mismatches at runtime.

In AGENTS.md (actionable):

## After API Changes
1. Regenerate client: `pnpm run generate:api`
2. Check for type errors: `pnpm tsc --noEmit`

Recurring Pattern Detection

Every learning entry must carry recurrence metadata. Errors and feature requests may continue to use See Also without this learning-specific schema.

Metadata Semantics

Field	Requirement	Meaning
Pattern-Key	Required	Stable semantic identity of the prevention rule, such as frontend.relative_same_origin_api
Recurrence-Count	Required	Number of distinct occurrences; do not count repeated mentions, commits, or evidence for one occurrence
First-Seen	Required	Date of the first known occurrence
Last-Seen	Required	Date of the latest known occurrence
Task-Keys	Required	Comma-separated set of distinct work units in which the pattern occurred
See Also	Optional	IDs for related but semantically different patterns

Use an existing issue, PR, job, plan log, or conversation identifier as the task key when available, prefixed by its source (for example, github:owner/repo#123). Otherwise use conversation:YYYYMMDD-short-slug. Multiple occurrences inside one work unit increment Recurrence-Count but add only one value to Task-Keys.

When capturing a learning:

1. Derive its Pattern-Key and current task key before writing.
2. Search for the exact key: grep -nFx -- "- Pattern-Key: <pattern-key>" .learnings/LEARNINGS.md.
3. If found, update that entry: increment Recurrence-Count once for the new occurrence, update Last-Seen, and add the task key only if it is new. Do not append another entry for the same pattern.
4. If not found, generate a unique ID and create an entry with count 1, equal first/last dates, and the current task key.
5. Add See Also only when another entry is related but has a different prevention rule.
6. Bump priority if impact or recurrence warrants it.
7. Consider systemic fix: Recurring issues often indicate:
   • Missing documentation (→ promote to CLAUDE.md or .github/copilot-instructions.md)
   • Missing automation (→ add to AGENTS.md)
   • Architectural problem (→ create tech debt ticket)

Simplify & Harden Feed

Use this workflow to ingest recurring patterns from the simplify-and-harden skill and turn them into durable prompt guidance.

Ingestion Workflow

1. Read simplify_and_harden.learning_loop.candidates from the task summary.
2. For each candidate, use pattern_key as the stable dedupe key.
3. Search .learnings/LEARNINGS.md for an existing entry with that key:
   • grep -nFx -- "- Pattern-Key: <pattern_key>" .learnings/LEARNINGS.md
4. If found:
   • Increment Recurrence-Count
   • Update Last-Seen
   • Add the current task key to Task-Keys if it is not already present
5. If not found:
   • Create a new LRN-... entry
   • Set Source: simplify-and-harden
   • Set Pattern-Key, Recurrence-Count: 1, First-Seen/Last-Seen, and Task-Keys

Promotion Rule (System Prompt Feedback)

Promote recurring patterns into agent context/system prompt files when all are true:

• Recurrence-Count >= 3
• Task-Keys contains at least 2 distinct values
• Occurred within a 30-day window

Promotion targets:

• CLAUDE.md
• AGENTS.md
• .github/copilot-instructions.md
• OpenClaw workspace files when applicable — see references/openclaw-integration.md

This three-condition rule is the single promotion threshold for this skill. The Quick Reference row for self-healing Handoff blocks and the aggregator skills (learning-aggregator, learning-aggregator-ci) all use this same rule.

Write promoted rules as short prevention rules (what to do before/while coding), not long incident write-ups.

Periodic Review

Review .learnings/ at natural breakpoints:

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

# 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
• Promote applicable learnings
• Link related entries
• Escalate recurring issues

Detection Triggers

Automatically log when you notice:

Corrections (→ learning with correction category):

• "No, that's not right..."
• "Actually, it should be..."
• "You're wrong about..."
• "That's outdated..."

Feature Requests (→ feature request):

• "Can you also..."
• "I wish you could..."
• "Is there a way to..."
• "Why can't you..."

Knowledge Gaps (→ learning with knowledge_gap 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
critical	Blocks core functionality, data loss risk, security issue
high	Significant impact, affects common workflows, recurring issue
medium	Moderate impact, workaround exists
low	Minor inconvenience, edge case, nice-to-have

Area Tags

Use to filter learnings by codebase region:

Area	Scope
frontend	UI, components, client-side code
backend	API, services, server-side code
infra	CI/CD, deployment, Docker, cloud
tests	Test files, testing utilities, coverage
docs	Documentation, comments, READMEs
config	Configuration files, environment, settings

Best Practices

1. Log immediately - context is freshest right after the issue
2. Be specific - future agents need to understand quickly
3. Include reproduction steps - especially for errors
4. Link related files - makes fixes easier
5. Suggest concrete fixes - not just "investigate"
6. Use consistent categories - enables filtering
7. Use stable pattern and task keys - makes recurrence and promotion auditable
8. Promote only with recorded evidence - verify every promotion condition from metadata
9. Review regularly - stale learnings lose value

Gitignore Options

Default: keep repo-local path as a symlink to centralized storage

.learnings/

Do not track repo-specific learning markdown files in the target repo. If a learning should become shared project policy, promote it into the repo's agent instructions or documentation instead of committing .learnings contents.

Hook Integration

Enable automatic reminders through agent hooks. This is opt-in - you must explicitly configure hooks. The same two scripts work across Claude Code and Codex CLI (both deliver JSON on stdin and accept the same additionalContext output shape); Copilot hooks can log but not inject context, so Copilot uses the instructions-file channel. Full per-agent setup including Codex and Copilot: references/hooks-setup.md.

Quick Setup (Claude Code)

Create .claude/settings.json in your project. The command path must point to where the skill is actually installed: .claude/skills/self-improvement/ for gh skill install / npx skills add, or skills/self-improvement/ if this repo is vendored into the project. Relative paths resolve from the project root.

{
  "hooks": {
    "UserPromptSubmit": [{
      "hooks": [{
        "type": "command",
        "command": "${CLAUDE_PROJECT_DIR}/.claude/skills/self-improvement/scripts/activator.sh"
      }]
    }]
  }
}

This injects a learning evaluation reminder after each prompt (~50-100 tokens overhead).

Full Setup (With Error Detection)

{
  "hooks": {
    "UserPromptSubmit": [{
      "hooks": [{
        "type": "command",
        "command": "${CLAUDE_PROJECT_DIR}/.claude/skills/self-improvement/scripts/activator.sh"
      }]
    }],
    "PostToolUse": [{
      "matcher": "Bash",
      "hooks": [{
        "type": "command",
        "command": "${CLAUDE_PROJECT_DIR}/.claude/skills/self-improvement/scripts/error-detector.sh"
      }]
    }]
  }
}

Hooks receive the event payload as JSON on stdin. The error detector parses tool_response from that JSON and returns its reminder as additionalContext JSON output, which is required for PostToolUse output to reach the model.

Available Hook Scripts

Script	Hook Type	Purpose
scripts/activator.sh	UserPromptSubmit (Claude Code, Codex)	Reminds to evaluate learnings after tasks (plain stdout is added to context for this event on both agents)
scripts/error-detector.sh	PostToolUse (Claude Code, Codex), postToolUse (Copilot, logging only)	Parses the stdin JSON payload for error patterns across all three agents' payload shapes; emits an additionalContext reminder

See references/hooks-setup.md for detailed configuration and troubleshooting.

Automatic Skill Extraction

When a learning is valuable enough to become a reusable skill, extract it using the provided helper.

Skill Extraction Criteria

A learning qualifies for skill extraction when ANY of these apply:

Criterion	Description
Recurring	Learning recurrence metadata meets the Promotion Rule
Verified	Status is resolved with working fix
Non-obvious	Required actual debugging/investigation to discover
Broadly applicable	Not project-specific; useful across codebases
User-flagged	User says "save this as a skill" or similar

Extraction Workflow

1. Identify candidate: Learning meets extraction criteria
2. Run helper (or create manually):

   ./skills/self-improvement/scripts/extract-skill.sh skill-name --dry-run
   ./skills/self-improvement/scripts/extract-skill.sh skill-name
   

3. Customize SKILL.md: Fill in template with learning content
4. Update learning: Set status to promoted_to_skill, add Skill-Path
5. Verify: Read skill in fresh session to ensure it's self-contained

Manual Extraction

If you prefer manual creation:

1. Create skills/<skill-name>/SKILL.md
2. Use template from assets/SKILL-TEMPLATE.md
3. Follow Agent Skills spec:
   • YAML frontmatter with name and description
   • Name must match folder name
   • No README.md inside skill folder

Extraction Detection Triggers

Watch for these signals that a learning should become a skill:

In conversation:

• "Save this as a skill"
• "I keep running into this"
• "This would be useful for other projects"
• "Remember this pattern"

In learning entries:

• Recurrence metadata meets the Promotion Rule
• High priority + resolved status
• Category: best_practice with broad applicability
• User feedback praising the solution

Skill Quality Gates

Before extraction, verify:

• Solution is tested and working
• Description is clear without original context
• Code examples are self-contained
• No project-specific hardcoded values
• Follows skill naming conventions (lowercase, hyphens)

Multi-Agent Support

This skill works across different AI coding agents with agent-specific activation.

Claude Code

Activation: Hooks (UserPromptSubmit, PostToolUse) Setup: .claude/settings.json with hook configuration Detection: Automatic via hook scripts

Codex CLI

Activation: Hooks (UserPromptSubmit, PostToolUse) — experimental, behind codex_hooks = true in config.toml Setup: <repo>/.codex/hooks.json or ~/.codex/hooks.json; same scripts, same payload/output shapes as Claude Code Detection: Automatic via hook scripts; see references/hooks-setup.md for the config Fallback: Add the self-improvement guidance to AGENTS.md if hooks are unavailable

GitHub Copilot

Activation: Instructions file (Copilot hooks exist in .github/hooks/*.json but their output is ignored for prompt/tool events — they can log, not inject context) Setup: Add to .github/copilot-instructions.md:

## Self-Improvement

After solving non-obvious issues, consider logging to `.learnings/`:
1. Derive stable pattern and task keys
2. Update an exact Pattern-Key match or create a uniquely identified entry
3. Promote high-value learnings only when the recorded evidence qualifies

Ask in chat: "Should I log this as a learning?"

Detection: Manual review at session end

OpenClaw (Optional)

OpenClaw-specific setup, promotion targets, and hybrid usage details are kept in references/openclaw-integration.md so this main skill stays focused on the core self-improvement workflow for coding agents.

Agent-Agnostic Guidance

Regardless of agent, apply self-improvement when you:

1. Discover something non-obvious - solution wasn't immediate
2. Correct yourself - initial approach was wrong
3. Learn project conventions - discovered undocumented patterns
4. Hit unexpected errors - especially if diagnosis was difficult
5. Find better approaches - improved on your original solution

Copilot Chat Integration

For Copilot users, add this to your prompts when relevant:

After completing this task, evaluate if any learnings should be logged to .learnings/ using the self-improvement skill format.

Or use quick prompts:

• "Log this to learnings"
• "Create a skill from this solution"
• "Check .learnings/ for related issues"