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 appro

Self Improvement Skill 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. For installation commands, see [references/installation.md](references/installation.md). For optional agent activation and hooks, see [references/hooks setup.md](references/hooks setup.md). Read these only when installing or configuring the skill. Pair with [ self healing ](../self healing/SKILL.md): 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 Similar to existing entry Link with See Also , consider priority bump Broadly applicable learning Promote to CLAUDE.md , AGENTS.md , and/or .github/copilot instructions.md Setup Create .learnings/ directory in project root if it doesn't exist: 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 : Every saved learning gets maintenance fields at capture, even if never promoted. Use [references/context maintenance.md](references/context maintenance.md); keep unknowns explicit. Error Entry Append to .learnings/ERRORS.md : Actual error message or output Feature Request Entry Append to .learnings/FEATURE REQUESTS.md : ID Generation Format: TYPE YYYYMMDD XXX TYPE: LRN (learning), ERR (error), FEAT (feature) YYYYMMDD: Current date XXX: Sequential number or random 3 chars (e.g., 001 , A7B ) Examples: LRN 20250115 001 , ERR 20250115 A3F , FEAT 20250115 002 Resolving Entries When an issue is fixed, update the entry: 1. Change Status : pending → Status : resolved 2. Add resolution block after Metadata: 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 How to Promote The main agent performs this step using the learning entry or the learning aggregator gap report. No dedicated agent preset is required. 1. Check eligibility and relevance. Apply the Promotion Rule below, read the supporting entries and related files, and check existing instructions. If the rule is already covered, record the existing target rather than duplicating it. Flag stale evidence or conflicting rules for human review; do not silently dismiss entries or overwrite existing guidance. 2. Distill the pattern into one to three actionable, contextual sentences. Choose the appropriate target and section, preserving its organization and any required synchronization across instruction files. Promotion changes instructions, not application code. 3. Show the proposed diff for human approval before writing instructions. Apply only the approved changes. In Copilot, present the diff and ask in chat. Skill edits require explicit scoped approval as described below. 4. Update the source entry after promotion: set Status : promoted , record Promoted : <target files and Promoted Date: YYYY MM DD , and retain the source IDs and Pattern Key. Do not mark an unapplied proposal as promoted. Promotion approval does not authorize committing or publishing. 5. Flag eval candidates for eval creator when the rule has a clear pass/fail condition. Include the Pattern Key, rule, target, source IDs, recurrence evidence, assertion, and verification method. When a gap report supplies a tracker , preserve it as the Pattern Key in the handoff. Projects using inline provenance can also place <! tracker:[pattern key] source:[entry IDs] promoted:YYYY MM DD eval:[eval ID] above the rule; omit unknown fields. Tracker comments are optional. Context Maintenance at Promotion Refine the capture time contract at promotion; use context decay when available. Keep metadata in the learning and only the rule or retrieval pointer in instructions. Review does not change recurrence or eligibility; see references/context maintenance.md . For stale skill guidance, surface a concrete proposal even on the first learning. Skill edits/retirement need explicit scoped approval, even without context decay ; see the same reference. 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): Learning (verbose): When modifying API endpoints, must regenerate TypeScript client. Forgetting this causes type mismatches at runtime. In AGENTS.md (actionable): Recurring Pattern Detection If logging something similar to an existing entry: 1. Search first : grep r "keyword" .learnings/ 2. Link entries : Add See Also : ERR 20250110 001 in Metadata 3. Bump priority if issue keeps recurring 4. 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 n "Pattern Key: <pattern key " .learnings/LEARNINGS.md 4. If found: Increment Recurrence Count Update Last Seen Add See Also links to related entries/tasks 5. If not found: Create a new LRN ... entry Set Source: simplify and harden Set Pattern Key , Recurrence Count: 1 , and First Seen / Last Seen Promotion Rule (System Prompt Feedback) Promote recurring patterns into agent context/system prompt files when all are true: Recurrence Count = 3 Seen across at least 2 distinct tasks Occurred within a 30 day window Promotion targets: CLAUDE.md AGENTS.md .github/copilot instructions.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 Review Actions Resolve fixed items Promote applicable learnings Link related entries Escalate recurring issues Review saved learnings, including one off and unpromoted entries, when their source, decision, dependency, or review point changes. Update the existing contract using references/context maintenance.md ; use context decay when available. A review is not recurrence or evidence for age based removal. 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. Promote selectively apply the promotion rule; prefer a source retrieval pointer when a copied fact would quickly become stale 8. Review regularly stale learnings lose value Gitignore Options Keep learnings local (per developer): Track learnings in repo (team wide): Don't add to .gitignore learnings become shared knowledge. Hybrid (track templates, ignore entries): Hook Integration Automatic reminders are opt in . Claude Code, Codex CLI, and Copilot have different event and output contracts; see [references/hooks setup.md](references/hooks setup.md). Amp loads skills on demand and uses a separate native plugin for per turn reminders; see [references/amp setup.md](references/amp setup.md). Reminders do not write learnings or guarantee capture. Automatic Skill Extraction Wh

self-improvement