Summary
Slim the Skill Workshop system-prompt section to the routing contract and move per-action mechanics into the skill_workshop tool schema; soften the wording so the section states one rule once.
Problem to solve
Whenever the skill_workshop tool is available, every conversation carries a 13-line system-prompt section (src/agents/skill-workshop-prompt.ts, injected at src/agents/system-prompt.ts:970). Three problems:
- Cost: it is paid on every API call for every session with the tool, but most of it is per-action mechanics (create vs update vs revise selection,
proposal_id resolution, the 160-byte description limit, list/inspect discovery rules) that only matter mid-tool-use — exactly what parameter descriptions in the tool schema are for.
- Tone/complexity: the section restates "do not do this manually / must go through
skill_workshop" three separate times (lines 13, 21, 22). Community feedback is blunt — users describe the wording as heavy-handed, and the documented workaround making the rounds is to disable the skill_workshop tool entirely so agents can write skills again, which throws away the whole review pipeline to escape one prompt section (Discord #clawtributors, 2026-06-08: "this wording is horrific imho, as it explicitly forbids any skill creation outside of the workshop" → "just disable the skill_workshop tool in your config").
- Perception: the workshop reads as a gate rather than a helper. The routing rule is legitimate (durable skill writes go through the reviewable proposal flow); it just doesn't need a page of prohibitions to say so.
Proposed solution
- Reduce the system-prompt section to ~3-4 lines: when to route to
skill_workshop (durable skill/playbook/workflow requests), that proposal writes and lifecycle changes go through the tool rather than manual file edits, and that proposals stay pending unless the user explicitly asks to apply/reject/quarantine.
- Move action-selection guidance (create/update/revise semantics,
proposal_id/name resolution, description byte limit, list/inspect for discovery) into the skill_workshop tool's action/parameter descriptions in src/agents/tools/skill-workshop-tool.ts, compressing overall so combined bytes go down, not sideways.
- Keep the injection gate as-is (section only present when the tool is available).
- Regenerate prompt snapshots; adjust
src/agents/system-prompt.test.ts and workshop tool tests.
Alternatives considered
- Move the whole section into an opt-in skill (community suggestion): loses the routing contract for everyone who does want reviewable proposals; the objection is verbosity/tone, not the existence of routing.
- Leave as-is: the escape hatch users share (disable the tool) silently kills proposal review — worse than the problem.
- Delete the routing rule entirely: direct skill writes bypass review/quarantine and the approval policy; the rule is the workshop's contract.
Impact
- Affected: every session on every agent where
skill_workshop is exposed (host agents by default).
- Severity: medium — recurring token cost plus a documented user pattern of disabling the review pipeline.
- Frequency: every API call in affected sessions.
- Consequence today: prompt bloat, and users opting out of the workshop wholesale.
Evidence
This issue is deliberately scoped to the prompt/schema split; the linked issues own the other workshop friction.
Summary
Slim the Skill Workshop system-prompt section to the routing contract and move per-action mechanics into the
skill_workshoptool schema; soften the wording so the section states one rule once.Problem to solve
Whenever the
skill_workshoptool is available, every conversation carries a 13-line system-prompt section (src/agents/skill-workshop-prompt.ts, injected atsrc/agents/system-prompt.ts:970). Three problems:proposal_idresolution, the 160-byte description limit, list/inspect discovery rules) that only matter mid-tool-use — exactly what parameter descriptions in the tool schema are for.skill_workshop" three separate times (lines 13, 21, 22). Community feedback is blunt — users describe the wording as heavy-handed, and the documented workaround making the rounds is to disable theskill_workshoptool entirely so agents can write skills again, which throws away the whole review pipeline to escape one prompt section (Discord#clawtributors, 2026-06-08: "this wording is horrific imho, as it explicitly forbids any skill creation outside of the workshop" → "just disable the skill_workshop tool in your config").Proposed solution
skill_workshop(durable skill/playbook/workflow requests), that proposal writes and lifecycle changes go through the tool rather than manual file edits, and that proposals stay pending unless the user explicitly asks to apply/reject/quarantine.proposal_id/nameresolution, description byte limit, list/inspect for discovery) into theskill_workshoptool's action/parameter descriptions insrc/agents/tools/skill-workshop-tool.ts, compressing overall so combined bytes go down, not sideways.src/agents/system-prompt.test.tsand workshop tool tests.Alternatives considered
Impact
skill_workshopis exposed (host agents by default).Evidence
src/agents/skill-workshop-prompt.ts(13 lines, three restatements of the manual-write prohibition); gate atsrc/agents/system-prompt.ts:970.src/agents/tools/skill-workshop-tool.ts.#clawtributors2026-06-08 thread (quotes above); adjacent friction tracked separately in [Bug]: Skill Workshop agent-tool apply times out because approval wait exceeds tool watchdog #91266 / skill_workshop apply times out ("Approval timed out") on large proposals (~28KB) #94249 / Skill Workshop apply popup carries no proposal details + fixed 60s TTL #93173 (approval timeouts/TTL), Skill Workshop loaded but skill_workshop tool hidden by coding profile lacks actionable diagnostic #87570 (tool hidden by tools.profile without diagnostic), skill_workshop MCP action=create makes a sibling skill when the proposal is clearly meant to patch existing skills #94947 (create-vs-update misrouting), Skill Workshop proposal can remain shown as waiting after skill is already active #90388 (stale waiting proposal), Feature Request: Post-task self-reflection for skill auto-creation (inspired by Hermes + SkillClaw), + prefix cache optimization (inspired by Reasonix) #95477 / [Feature]: Skill lifecycle management — auto-optimization on failure + usage-based retirement #95516 (auto-creation & lifecycle ideas).This issue is deliberately scoped to the prompt/schema split; the linked issues own the other workshop friction.