Self Improvement Logging

The problem

Coding agents can fix a bug in one session, yet lose the cause, user corrections, tool constraints, and missing capabilities in chat history. When a similar issue appears later, the agent may repeat the mistake. This skill writes those signals into Markdown files in the repo or workspace, so future agents can search, reproduce, resolve, and promote stable rules into project memory.

How it works

• Local logs: maintain .learnings/ at the project root, with ERRORS.md, LEARNINGS.md, and FEATURE_REQUESTS.md, without overwriting existing files.
• Structured entries: use IDs like LRN-YYYYMMDD-XXX, ERR-YYYYMMDD-XXX, and FEAT-YYYYMMDD-XXX, plus status, priority, area tags, and context.
• Trigger logging: immediately record command failures, user corrections, stale knowledge, better practices, or feature requests, with reproduction steps and relevant file paths.
• Deduplicate and track: link similar entries with See Also; raise priority when issues recur and decide whether documentation, automation, or an architectural fix is needed.
• Promote memory: when a rule applies across features or contributors, distill it into concise guidance for CLAUDE.md, AGENTS.md, .github/copilot-instructions.md, or OpenClaw workspace files such as SOUL.md and TOOLS.md.

Boundaries

Best for long-lived, multi-agent, or team-shared engineering repositories. Avoid logging secrets, tokens, private keys, environment variables, or unredacted source; if logs will be committed, verify content safety first. It is not an automatic bug fixer, but a workflow that turns transient agent experience into reviewable, searchable, promotable project knowledge.