Summary

The skill_workshop MCP tool's action=create always materializes a new sibling skill even when the proposal is clearly intended to patch one or more existing skills. There is no MCP action that maps to "improve / patch existing skill(s)" the way the CLI's openclaw skills workshop propose-update <skill> does, and the existing action=update only handles a single target skill.

This leads to silent wrong-target landings: a proposal whose content describes patches to skills A, B, C plus new helper scripts in skill D lands as a brand-new sibling skill containing all of that content, leaving A/B/C/D untouched.

Environment

• OpenClaw 2026.6.8 (844f405)
• macOS, Node v24.16.0
• MCP tool path: agent-side skill_workshop tool exposed by the standard OpenClaw runtime

Reproduction

1. Have at least one existing workspace skill (e.g., skills/foo/, skills/bar/).
2. Call the MCP tool:

   skill_workshop(
     action = "create",
     name = "foo-hardening",
     description = "...",
     proposal_content = "<markdown that describes patches to skills/foo/SKILL.md, skills/bar/SKILL.md, and adds skills/foo/scripts/new-helper.js>",
     support_files = [
       { path: "scripts/new-helper.js", content: "..." },
       { path: "references/extra.csv", content: "..." }
     ]
   )
   

3. Apply the proposal:

   openclaw skills workshop apply <proposal-id>
   

4. Observe the result: skills/foo-hardening/ is created as a new sibling skill containing SKILL.md, scripts/new-helper.js, references/extra.csv. skills/foo/ and skills/bar/ are untouched.

Expected behaviour

One of:

• The MCP tool exposes a propose-update or patch action that accepts one or more target skill names and a structured set of patches (markdown sections to insert, files to add/replace within an existing skill tree).
• The MCP tool's action=create rejects (or at least warns about) proposals whose proposal_content clearly references existing skill directories (skills/<name>/... paths in the scope table or support_files), and prompts for explicit per-skill propose-update calls.
• At minimum, the documentation in the tool's own description spells out that action=create always creates a sibling skill, and tells the agent to enumerate multi-skill changes as separate propose-update calls.

Actual behaviour

The MCP tool silently treats the whole multi-skill proposal as a single new skill. The user then has to manually re-apply the proposal's intended patches against the right existing skills, then delete the unintended sibling.

Workaround

After applying:

1. Move any support_files listed under scripts/ into the intended existing skill's scripts/ directory.
2. Append any references/ additions (CSVs, glossaries) to the intended existing files, deduping.
3. Extract every patch block from the sibling's SKILL.md and insert it into the right anchor in the intended existing skills' SKILL.md files.
4. Delete the sibling skill directory.
5. Preserve the sibling's SKILL.md as a historical record outside the skills tree.

Suggested fixes

1. Add skill_workshop action="propose-patch" (or rename and extend action="update") that takes a list of targets: [{ skill: "<existing-skill>", edits: [...] }]. Each edits[] entry would be an anchored append or insert, mirroring the edit tool's semantics.
2. In the current action="create": when the proposal_content references skills/<existing-skill-name>/ paths, return a structured warning that lists the affected existing skills and asks the agent to convert the call into N propose-update calls.
3. Document in the skill_workshop MCP tool description that proposals always create new sibling skills and that the agent must split multi-skill changes itself.

Impact

When this misfires, the new rules and new scripts the user wanted on their existing pipeline silently land in an unused sibling skill. The user keeps hitting the original gap in production until the agent (or the user) realizes the proposal didn't land where they thought it would. In the session that surfaced this issue, the misfire was caught the same day, but a less attentive review cycle would leave the workspace in a quietly broken state.

Happy to test a fix or share a redacted before/after of the workspace if useful.