OpenClaw Skill Workshop

Propose, apply, and manage durable skill changes (skill_workshop) — the sanctioned path for editing a live skill's SKILL.md instead of writing to it directly.

Dogfooded 2026-08-26: adding a citation-discipline rule to the self-improving skill after two of its own reflection entries turned out not to match the session transcripts they described.

Goals

Turn a real, checked lesson ("self-improving log entries need to cite verifiable evidence") into a durable skill change, the correct way — a proposal the tool records and applies, not a direct file edit that bypasses the review trail the tool exists to provide.

Effectiveness

Adequate for authoring; broken for applying frontmatter. Drafting and creating the proposal worked cleanly — action=update with a full replacement proposal_content plus support_files for three template files landed exactly as written, including a brand-new Core Rule and three updated log-format templates. Applying it is where it broke: the agent-tool apply call itself timed out (a known, previously-documented failure mode for this tool), and the already-documented CLI fallback (openclaw skills workshop apply <id>) worked — but silently corrupted the skill's frontmatter every time.

What made it effective

Friction, pain points, surprises

apply clobbers frontmatter description and drops version, every time, regardless of proposal_content. The top-level description parameter is documented as cosmetic — "concise text shortens the proposal listing entry" — but on apply it silently overwrites the skill's actual YAML frontmatter description field, the text that governs when the skill triggers for future sessions. It happened identically on two separate apply calls in the same session: the first replaced a five-condition trigger description with a one-line proposal summary; the second replaced that with a proposal description about fixing the first bug, compounding rather than correcting it. In both cases the submitted proposal_content contained the correct, full frontmatter — the tool used the wrong source for that one field regardless. version disappeared from the frontmatter entirely on both applies, again despite being present and correctly formatted in proposal_content both times.

A cosmetic-sounding parameter turned out to be load-bearing. Nothing in the tool's own description flags description as anything other than a proposal-listing convenience string. There was no reason, from the schema alone, to expect it to overwrite live skill metadata that actually affects runtime behavior (skill triggering).

Recovery had to leave the tool's own path. After the second apply reproduced the exact same corruption, a third skill_workshop round would almost certainly have repeated it again — so the fix was a direct hand-edit of the live SKILL.md frontmatter, the exact action the tool exists to mediate and audit. Correct call given a confirmed, reproducible tool bug, but it means the one part of this change that most needed a clean record (a frontmatter fix, easy to get subtly wrong) has none.

Verdict: adequate with a real gap. Content authoring and template support-files work as designed, and the CLI apply fallback is a solid answer to the separate known apply-times-out issue. But description-overwrites-frontmatter is a distinct, reproducible bug that turns an ordinary "just pass a short summary" parameter into a silent live-metadata clobber — worth passing the exact existing frontmatter description (or leaving description unset, if the schema allows it) on any future update targeting a skill whose trigger description matters, until the tool itself is fixed.