OpenClaw Agent Skills: eight skills, one installer, and a dependency chain for contributors

Two releases tagged 44 minutes apart on the same morning

Three releases are visible and the spacing between them is uneven. v0.2.0 was tagged on 2026-09-24. Then v0.3.0 and v0.4.0 were both tagged on 2026-10-01, the first at 02:12 and the second at 02:56, forty-four minutes apart. The minor-to-minor jump in under an hour is unusual for a repository whose previous release was a week earlier, and it suggests a release was cut, something broke or was found missing, and a follow-up went out the same morning. The project keeps a changelog file at the root and a releasing document under `docs/`, so the sequence is recorded rather than inferred, but neither is visible in the overview. The default branch was pushed on 2026-10-02, the day after both tags, so the tree has already moved past what either release contains.

A v0.x version with a stable layout and no stated compatibility promise

The project is at 0.4.0 and its version history is three minor bumps in about a week. Nothing in the documentation says what changes between minors, and the absence is meaningful because the whole point of a shared skill catalogue is that other repositories depend on it. If a skill's frontmatter changes shape, every downstream consumer that routes on the description field is affected, and the guide here is explicit that descriptions should be kept short and useful for routing, which means those strings are load-bearing rather than decorative. So the practical reading is that a 0.x tag carries no compatibility guarantee, and a repository that vendors a snapshot of these skills is accepting that it will have to re-sync when the shape moves. The repository does at least have a versioning story for its own releases, with a changelog and a documented release process rather than ad hoc tagging.

The installer refuses to write inside its own source tree

One guard is stated more precisely than the rest of the documentation. Install targets must not contain or sit inside the source skills, and the installer checks every selected destination before changing files, including when forced and including in dry-run mode. Installing directly over the same source directory is skipped rather than attempted. That last clause is the one that matters, because the default target for a coding agent is a skills directory that a developer may already have symlinked back to this checkout, which is exactly the documented setup for two of the popular tools. Without the check, a forced install would truncate the source it was copying from. The dry-run mode is the cheap way to find out where things would land:

scripts/install-skills --dry-run

Since that check runs before any file changes and runs again under `--force`, a preview is a real test of the destination rather than a listing of what would happen if the paths happened to be fine.

Session publication and local transcript provenance

The beam skill publishes sessions to a remote catalog, while agent-transcript is described as local-only. The beam skill is self-contained, authenticated and redacted, and it publishes local coding sessions to a read-only catalog. The agent-transcript skill produces redacted pull request and issue transcript provenance, and is marked local-only. Read together, the pairing is the interesting part: a skill that uploads sessions and a skill that redacts transcripts are the two that touch provenance, and they are the two a team should read before installing anything else. One skill also has an explicit handling warning. Session exports can contain sensitive conversation data, and the session viewer's HTML output is to be treated as local and private unless it has been separately redacted and reviewed. That instruction is attached to the viewer rather than to the skills that generate the exports.

The admission rule is what keeps this catalogue from becoming a dumping ground

Most skill repositories accumulate product-specific instructions. This one refuses them in a sentence. Repo-specific product skills should stay in the repo they describe, and the example given is that a usage skill for one project belongs in that project's own repository, while a general review helper belongs here. The rule is reinforced by a separate file, `VISION.md`, which the overview points at for catalog boundaries and admission principles. Admission is not purely about generality either. The guide nominates one specific skill as a good candidate for vendoring into flagship repositories, on the grounds that review closeout is part of the contribution workflow, and then adds the qualifier that large operational skills should be vendored only when a repository genuinely needs them available without setup. So the boundary has three parts: general workflows live here, product knowledge lives with the product, and anything vendored downstream is a distribution artifact.

One skill is scoped to a different organisation's repositories

The readme-standard skill carries the narrowest scope in the catalogue and it is worth reading on its own. It covers house README structure, badge row, tone and verification gates, and it names a specific set of repositories belonging to a particular maintainer as the ones it applies to. So one of the eight entries in a catalogue whose stated purpose is reuse everywhere is deliberately scoped to one organisation's conventions. That is consistent with the admission rule rather than an exception to it, since a house style for someone else's repositories is not a general workflow. It also means the skill list is not homogeneous: three entries are about privacy and publishing, one is about presentation standards for a named set of projects, and the remaining four are operational workflows.

The contributor path needs two runtimes and a pinned toolchain

Running the skills costs one script. Checking them costs an environment. The contributor sequence is a Python 3.14 virtual environment, a pip install from a development requirements file, a Node install with scripts disabled, and then the shared check command, which runs frontmatter validation, syntax checks, all Python and Node tests, and a typecheck for the one skill that has TypeScript in it. Two details sit oddly next to each other. The development check pins a Python version and a Node version to match continuous integration, so local and CI behaviour are aligned by construction. The package manifest, meanwhile, declares no runtime dependency on Node at all and keeps TypeScript and its type definitions as development dependencies, which is consistent with the claim that installed skills never need a Node install. So the two requirements are genuinely different, and the second one only applies if you intend to change a skill rather than use one.

Editorial conclusion

OpenClaw Agent Skills suits someone running several repositories with the same review or handoff routine and tired of copying skill files by hand. It does not suit someone who wants one command and no decisions, because eight skills with different shapes have to be chosen from, and three of them assume you already know what a test box or a session catalog is. Five things to check before you adopt it. Check which of the eight skills you actually want, since the installer takes names rather than installing everything by default in the selective form. Check whether you want symlinks or copies, since the choice determines whether edits in your checkout are live. Check where your install target sits, because the installer refuses a destination inside the source tree. Check which skills publish anything, since two of them are described as uploading local sessions to a remote catalog. And check what a contributor install costs you, since the development check needs both a Python environment and a Node install. Licence is MIT, the newest release is v0.4.0 from 2026-10-01, and the default branch was pushed on 2026-10-02.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. openclaw/agent-skills on GitHub
4. README