self-improving-agent: an OpenClaw skill that records what was learned

A skill that writes down what happened

self-improving-agent is a self-improvement skill for OpenClaw that captures learnings, errors, and feature requests to support continuous improvement across sessions. The project description calls it an agent knowledge skill made for the skill marketplace, and the homepage is its ClawHub listing.

The idea is simple and it addresses a real weakness of coding agents. An agent that gets something wrong in one session has no memory of that mistake in the next one, so the same mistake happens again, and the same feature request gets re-explained. A skill that writes those three things down, the learnings, the errors, and the feature requests, turns the agent's history into something it can read back.

The scope is narrower than the name suggests in one important way. This version is OpenClaw only. To use the skill with other agents, and the README names Claude Code, Codex, and GitHub Copilot among them, you should use the original multi-agent version instead, which lives in a separate repository under the same author. The attribution section says the project was remade for OpenClaw from that original, and links both the repository and the specific skill path within it.

That is a sensible split for a skill author who maintains the same idea in two places, and it also means the OpenClaw implementation is the one that has been rewritten, so the parts that differ from the original are the parts to read carefully.

The repository is not archived, the last push was on 2026-10-10, there are no GitHub releases, and the licence field is recorded as unknown, so the terms of use are worth checking in the repository itself.

The subfolder is the product

The repository layout section explains the most important thing about the project, and it is a design decision rather than a description of files.

The publishable skill package is the self-improving-agent subfolder. That is what ClawHub installs, and that is what you copy into your skills directory. The repository level files, the README and the GitHub continuous integration configuration, stay outside the package on purpose.

Inside the package there are two entry points. The skill entry point is the SKILL.md file, which is the document the agent reads, and the OpenClaw hook is a directory of hooks, which is the code that runs when something happens in the agent session.

The split matters because it is what makes the skill portable. A skill that was the whole repository could not be installed cleanly, because installing it would drag in the test harness, the CI configuration, and the development dependencies. By cutting the package out, the published artefact is the part that runs in an agent and nothing else.

It also explains a detail that would otherwise look like an inconsistency. The root package manifest is development-only, with its lockfile, and the README says so explicitly: the publishable skill subfolder remains dependency-free.

So when the README tells you to copy the skill subfolder and not the repository root, it is not a warning about tidiness. The repository root contains a Node manifest and a lockfile, and copying those into a skills directory gives the agent a package it will try to install things from.

Three ways to install, and they do not land in the same place

There are three installation routes, and the README is careful about a difference that is easy to miss.

The first is OpenClaw's built-in skill installer, which installs into the active OpenClaw workspace.

openclaw skills install @pskoett/self-improving-agent

The second is the ClawHub command line, which you install globally with npm, and the note is that this installs into the skills directory under the current working directory, not the workspace.

clawhub install @pskoett/self-improving-agent

That distinction is the kind of thing that bites. The same command name installs into two different places depending on which tool you run it with, and the second one is relative to where you happen to be standing.

The third route is manual, and it is two commands: clone the repository to a temporary directory, then copy the skill subfolder into your skills directory.

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

The copy is of the subfolder and not the repository root, for the reason given above.

The whole picture is a skill marketplace package with a fallback. The marketplace route gets you a versioned install with an update path, the CLI route gets you a local copy you control, and the manual route gets you a copy you can edit, which for a skill that captures your own learnings is a reasonable thing to want.

Dependency-free, and the stub that proves it

The development section describes a setup that is unusually honest about what it does and does not need.

You use the Node.js version pinned in the .nvmrc file, and then you run the four commands.

npm ci
npm test
npm run typecheck
npm run check:shell

The important sentence comes next. The root npm manifest and lockfile are development-only, and the publishable skill subfolder remains dependency-free. Tests use an OpenClaw type stub, so no OpenClaw installation, no credentials, and no backing services are required.

That last clause is what makes the test suite cheap, and it is a design decision about how the code is written. If the hook code imports from OpenClaw, the tests need a stub of those types, and the stub is a file in the repository rather than a running service. The typecheck script in the manifest names it explicitly, passing the stub declaration file along with the handler file to the compiler.

The three scripts in the manifest show the split between the three kinds of code in the repository. The test script runs the Node test runner against a single handler test file. The typecheck script runs the TypeScript compiler in strict mode with no emit, pinned to a specific module and target configuration. And the check:shell script runs a syntax check over three shell scripts, the skill extraction script and the two files in the agents directory.

The Amp section explains the agents directory in the same spirit. Amp runs the setup script to install the pinned Node toolchain and the locked development dependencies before taking an orb snapshot, and a warm setup reuses what is already installed. A repository scoped login shell hook selects that Node version without replacing the system Node of the orb. And the resume script intentionally does no installation, because there is no per wake repair or authentication work to do.

That last detail is the kind of precision that usually only appears in a project that has been automated properly. The development dependencies are just the Node type definitions and TypeScript itself, both pinned to exact versions.

Upgrading copies the hook again, and the learnings live outside

Two operational details in the README decide whether the skill keeps working after a few weeks.

The first is the upgrade procedure. The changelog in the skill package holds the version history and per version upgrade notes, and after upgrading you re-copy the OpenClaw hook and restart the gateway.

cp -r ~/.openclaw/skills/self-improving-agent/hooks/openclaw ~/.openclaw/hooks/self-improvement

That step is not obvious from the package layout, and the reason is that there are two copies of the hook. The one that ships inside the installed skill is updated when the skill is updated, and the one that is actually active lives in the hooks directory of the OpenClaw configuration, under a name that is not the same as the directory inside the skill. If you only update the skill, the active hook is still the old one, and the symptom is a skill that appears installed and captures nothing.

The second is the uninstall reference, which is in the references directory of the package and covers disable versus full removal. The warning in the README is the important part: review the learnings directory before deleting, because it contains your captured learnings and not skill code.

That is the whole risk of this kind of tool in one sentence. The skill is disposable, the data it wrote is not, and the two live in different places with different names. Anyone running a skill that accumulates a long term record of their own work should know which directory that is before they start, and should look at it before they clear anything out.

Editorial conclusion

self-improving-agent fits an OpenClaw user who wants a running record of what the agent got wrong and what it was asked to build, and who is prepared to look after the directory that holds that record. It does not fit someone using Claude Code, Codex, or GitHub Copilot, since this version is OpenClaw only and the README points at a different multi-agent version for those. Verify first that the copy of the skill you install includes the hooks directory, because the hook is what makes the capture happen, that you know where the learnings are written, and that you read the uninstall reference before you delete anything, since the learnings live outside the skill code and are the part you would lose.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. pskoett/self-improving-agent on GitHub
4. README