The OpenClaw Skill Workshop

An agent that can write its own skills needs a path where nothing goes live by accident. OpenClaw’s Skill Workshop is that governed path: agents and operators create a proposal, a pending draft with content, target binding, scanner state, hashes and rollback metadata, and it becomes a live skill only when applied. By default the Workshop writes only under the active agent’s own workshop-skills directory inside the state directory, separate from the session workspace and the managed skill library; bundled, plugin, ClawHub, project and workspace skills are edited through their own tools. Here are the lifecycle rules, the review surfaces, authoring from chat and the CLI, the learn and repair flows, and the settings.

The lifecycle rules

• Proposal first: generated content is stored as a proposal file, not a skill file; apply is the only live write, so create, update and revise never change active skills; creates and updates stay inside the agent’s Workshop directory, and a skill is Workshop-owned exactly when it lives there.
• No clobber: create fails if the target already exists in that directory, skills from other sources are never changed, and for same-named skills the loading order decides which definition wins; update proposals bind to the current target hash and go stale if the live skill changes before apply.
• Scanner gated and recoverable: apply reruns the security scanner before writing, only critical findings block it while warn-level findings stay visible, and rollback metadata is written before live files are touched; create and revise flush a complete immutable proposal generation and publish it with an atomic rename, so an interruption exposes either the previous generation or the new one.
• States: create, update, revise and evaluate leave a proposal pending; apply, reject and quarantine move it to applied, rejected or quarantined; a target change makes it stale; and only a pending proposal can be revised, applied, rejected or quarantined. Chat, CLI and Gateway all call the same service.

Apply is the only live write: create, update, and revise never change active skills.

Review, authoring, learning

In the Control UI the Workshop lives under plugins: a skills view lists what is installed in the selected agent’s Workshop directory with changed skills first and inline additions and removals against the retained applied version, and a suggestions view holds pending proposals to evaluate, revise, apply or reject; past applied, rejected, quarantined and stale proposals stay inspectable through the CLI and Gateway. From chat you ask for the skill you want and the agent calls the workshop tool and returns a proposal id: make a skill that runs the Monday inbox routine, update the trip-planning skill to check seat maps, show me the proposal, revise it, apply it. The learn command routes the current conversation or named sources, paths, URLs and pasted notes, into the best matching pending proposal or live skill and creates one only when needed, and it never applies. When a skill used in the current turn proves wrong, the agent reads the live skill and creates a targeted patch proposal, preparing one exact span when the whole skill exceeds the model’s read budget; a runtime receipt limits that to skills used in the run, and the repaired skill reaches new sessions while the running one keeps its snapshot. The CLI mirrors all of it: propose-create with a name, description and proposal file, propose-update, list, inspect, revise, evaluate through installed plugin evaluators, apply, reject and quarantine with reasons, each taking an agent id and JSON output.

Settings

• The autonomous mode is auto by default: off disables autonomous capture while keeping the durable-instruction nudge, propose creates pending proposals from corrections and substantial completed work, and auto uses normal agent tools for direct per-turn and weekly Workshop maintenance without proposal scanning or automatic rollback snapshots; user-prompted creation, the learn command and manual learning sessions work in every mode.
• The approval policy is auto by default, so agent-initiated apply, reject and quarantine run without another prompt; pending requires operator approval, the prompt names the proposal and target and shows the description, support-file count and body size, and an expired prompt leaves the proposal pending rather than acting, so agents should not retry an expired action in a loop.
• Caps: fifty pending and quarantined proposals per agent within one to two hundred, a forty-thousand-byte proposal body within roughly one thousand to two hundred thousand, a separate ten-thousand-character cap on autonomous proposals, and descriptions always capped at 160 bytes. A Control UI action can also scan past conversations without enabling autonomy: a normal session opens with mining instructions and follows the current mode.

OpenClaw self-learning covers the detached background review that feeds proposals, and OpenClaw skills configuration the full schema these settings sit in.

Where it fits

The Workshop is for skills the agent generates; hand-written workspace skills and the managed library keep their own surfaces, and personal library skills on a shared Gateway publish managed revisions rather than proposals. Create an OpenClaw skill is the hand-written path, and OpenClaw plugins the surface whose evaluators the evaluate step runs.

On Diali

On Diali the Workshop directory lives under the assistant’s state directory on its volume, so proposals and applied skills survive releases, and the review surface is the Control UI’s Workshop tab. Hosted OpenClaw on Diali is the assistant and Diali security describes the boundary around it.

• A proposal first; apply is the only live write.
• Hash-bound, scanner-gated, rollback-ready.
• Learn stages; it never applies.