Self-learning: Turn corrections into reusable skills

Self-learning converts corrections and successful outcomes into repeatable skills. Skills serve as the persistent building block: they contain procedures that later sessions can locate and execute. Every acquired skill passes through Skill Workshop, following the identical governed proposal, scan, apply, and lifecycle pathway used for explicit skill creation.

auto serves as the default setting. OpenClaw detects strong learning signals and routes them through the standard scanner-gated Workshop service without seeking permission. Selecting propose requires manual review of each capture before activation, while off turns off autonomous capture entirely.

Experience review

Each autonomous capture originates from a model examining actual evidence. No template or pattern-matching mechanism exists: material reaching a proposal stage was composed by the reviewer according to Workshop authoring standards, never lifted from conversation content.

Following substantial work, OpenClaw may execute one isolated background review to identify a reusable recovery technique or a stable procedure capable of eliminating at least two future model or tool round trips. Deep turns the user halted also qualify: the incorrect path combined with its correction provides precisely the evidence worth preserving. The reviewer receives notification when a turn was interrupted and captures only procedures that demonstrably worked prior to the stop. Turns concluding with a provider or prompt error never trigger a review; that failure represents transient environmental noise, and a review on the same model would likely encounter it again.

Experience review initiates only when every condition below is satisfied:

• the foreground turn finished or was interrupted, yet did not conclude with a provider or prompt error;
• the current turn involved at least 10 model iterations, or same-sender shallow turns within the session accumulated that much unreviewed work (the accumulated review covers the bounded message window of those turns);
• the run qualified as an eligible foreground conversation, excluding cron, heartbeat, memory, overflow, hook, subagent, or review work;
• the runtime reported the resolved provider, model, and actual availability of skill_workshop;
• the system remained quiet for 30 seconds; and
• no agent or reply run remains active.

A subsequent foreground completion within the same session resets the quiet period. Only one experience review executes at a time. The foreground answer never experiences delay.

The reviewer operates in isolation and favors small, well-supported captures. It accesses a bounded workspace skill list, can list or inspect proposals, and may read a limited excerpt of a writable skill for context. It drafts at most one pending proposal: preferring to update a matching pending proposal, then to modify the existing skill governing the work, and generating a new skill only when nothing addresses the class. A patch proposal quotes the exact live text to change (or appends a new section) and the tool assembles the full body within the same read that hash-binds the proposal, so untouched content survives by construction and patches auto-apply in auto mode. A patch demands a full-skill read receipt: skills exceeding the bounded read budget cannot be patched autonomously. A full-body update rewrite always stays pending for operator review. Its one-mutation budget is shared across retries. Every mutation is a pending proposal, it never writes a live skill directly and cannot apply, reject, quarantine, message, or use general agent tools. The reviewed trajectory is evidence, not instructions.

Strong candidates include:

• a dependable recovery following repeated tool or model failures;
• a lasting user correction or standing instruction ("from now on," "always," "never," "stop doing X"), embedded as a procedure step in the skill governing that work;
• a non-obvious ordering constraint that prevented a recurring error;
• a stable multi-step workflow that required repeated discovery; or
• a reusable preflight that would avoid several future calls.

The reviewer should refrain for:

• routine successful work or a one-time request;
• personal facts and simple preferences;
• transient environment or service failures;
• generic advice without concrete supporting evidence;
• unsupported negative claims; or
• secrets and credential material.

Mode policy

Configure the mode via the CLI:

openclaw config set skills.workshop.autonomous.mode auto
openclaw config set skills.workshop.autonomous.mode propose
openclaw config set skills.workshop.autonomous.mode off

Alternatively, modify ~/.openclaw/openclaw.json:

{
  skills: {
    workshop: {
      autonomous: {
        mode: "auto",
      },
    },
  },
}

Switching modes leaves existing proposals and applied skills untouched. Manual history review, /learn, and explicit Workshop requests remain accessible in all three modes.

Why auto is safe to default

Automatic learning follows the same apply path as an operator-approved Workshop proposal. It grants the isolated reviewer no new tools and no way to circumvent lifecycle checks.

Every learned skill receives these protections:

• Security scan at apply: Workshop reruns the scanner immediately before the live write. A critical finding quarantines the proposal instead of applying it.
• Workspace-only writes: creates and updates can target only writable skills in the selected workspace. Bundled, plugin, managed, personal-agent, system, and extra-root skills remain outside the write boundary.
• Hash binding: update proposals bind to the current live skill and go stale if that target changes before apply.
• Rollback metadata: apply records the prior skill and support-file contents before the live write.
• Curator lifecycle: learned skills unused for 30 days become stale and after 90 days become archived. Pin keeps a skill active; restore returns an archived skill to new session snapshots.
• Authoring standards: learned skills use class-level names, trigger-first descriptions, evidence-backed steps, and token-efficient language.
• Bounded failure: an automatic apply is attempted once. A normal apply failure leaves the proposal pending, while a scanner-critical proposal is quarantined. OpenClaw does not retry in a loop.

Reject a pending miscapture with one command:

openclaw skills workshop reject <proposal-id> --reason "Not reusable"

Applied captures remain visible in openclaw skills workshop list, retain their rollback metadata, and enter curator lifecycle management. This makes approval-free learning reversible and observable rather than silent.

Residual risk remains: learned content comes from conversation and tool output, and the scanner blocks recognized dangerous patterns, not every possible piece of bad advice. Review openclaw skills workshop list when in doubt.

Runtime support

Delayed experience review requires the runtime to report its resolved model and actual skill_workshop availability. The embedded runner and Codex app-server harness report those facts; Codex also reports its exact model-iteration count. Other CLI-backed runtimes fail closed until they provide the same runtime facts. /learn does not depend on delayed review and continues to work on those runtimes.

Cost and privacy

Experience review adds one bounded model run on the configured provider only after a substantial turn, not after every message. The review can make more than one provider request while it inspects or drafts its single proposal.

A deep-turn review receives only the current turn beginning with its most recent user message. A review triggered by accumulated shallow turns instead receives the bounded message window of those same-sender turns (at most 40 messages); accumulation restarts whenever the sender, provider, model, or auth profile changes, so no turn is disclosed to a provider identity other than its own. Either way the rendered trajectory is limited to 60,000 characters; when the bundle is too large, OpenClaw keeps the first message and newest evidence and marks the omitted middle.

The reviewer reuses the foreground provider, model, and available auth identity, with model fallbacks disabled. Provider pricing and data-handling terms apply to the additional run.

Manual history scanning follows a distinct bounded pathway. It examines as many as 20 meaningful sessions, each containing six or more model turns, scrubs any detected secrets, constrains the size of the transcript package, and may generate or update no more than three proposals that are still pending. Cursor position and coverage details are recorded in the shared state database, yet the transcript content itself is never duplicated into the scan state.

Warning

Both experience review and manual history scan have the ability to transmit qualifying conversation data, which includes tool inputs and their outcomes, to the designated model provider. Pick a provider and operating mode that align with the workspace's privacy and data handling standards.

Review and revert learning

Review all captures that are pending, applied, rejected, quarantined, or expired:

openclaw skills workshop list
openclaw skills workshop inspect <proposal-id>

Prevent a pending capture from turning active, or place it into quarantine for further review:

openclaw skills workshop reject <proposal-id> --reason "Too specific"
openclaw skills workshop quarantine <proposal-id> --reason "Needs security review"

Use the curator to examine and control skills that have already been applied:

openclaw skills curator status
openclaw skills curator pin <skill>
openclaw skills curator unpin <skill>
openclaw skills curator restore <skill>

When you need a clear proposal derived from the present conversation or from specified sources, employ /learn:

/learn
/learn docs/runbook.md; focus on recovery

/learn consistently generates a pending proposal and never applies it automatically.

For manual examination of prior work, navigate to Plugins -> Workshop in Control UI and choose Find skill ideas. Each click processes a single bounded window, and whatever result appears is left pending irrespective of the autonomous mode setting.

Configuration reference

Refer to Skills config for acceptable ranges and the full skills.* schema.

Troubleshooting

No capture appears

Verify the following conditions:

1. The active Gateway configuration has skills.workshop.autonomous.mode set to propose or auto.
2. The turn completed at least 10 model iterations and did not terminate with a provider or prompt error.
3. The conversation qualifies as foreground work.
4. The runtime confirmed the resolved model and the actual skill_workshop availability.
5. The run was not sandboxed, and tool policy still allows skill_workshop.
6. The Gateway remained operational and inactive throughout the 30-second quiet period.

An eligible experience review may still choose to abstain. When the evidence fails to meet the reusable-procedure threshold, having no proposal is the anticipated outcome.

Doctor reports that Workshop is hidden

In propose and auto modes, openclaw doctor verifies whether the default agent tool policy permits skill_workshop. Apply the reported tools.allow or tools.alsoAllow change, or switch the autonomous mode to off.

A proposal remains pending in auto mode

Automatic apply executes only once. Examine the proposal along with its scanner state:

openclaw skills workshop inspect <proposal-id>

A routine write or target failure keeps it pending for manual handling. A critical scanner finding shifts it to quarantine. Address the root cause and apply it manually; avoid constructing a retry loop around automatic capture.

Too many low-value captures appear

Move to propose to examine every capture, or off to turn off autonomous capture:

openclaw config set skills.workshop.autonomous.mode propose
openclaw config set skills.workshop.autonomous.mode off

After the mode change, existing proposals and applied skills stay visible.

Related

• Skill Workshop for proposal lifecycle and storage
• Creating skills for hand-authored skills
• Skills config for every skills.* setting
• Skills CLI for Workshop and curator commands