openclaw - 💡(How to fix) Fix [Feature]: Skill Workshop targeting shared skills + cross-workspace pattern promotion [1 comments, 2 participants]

Summary

Allow Skill Workshop's pending-approval workflow to (1) propose refinements to existing shared skills in ~/.openclaw/skills/ and (2) promote cross-workspace patterns into shared skill candidates, gated by the same safety primitives already in the plugin.

Problem to solve

In multi-agent setups (orchestrator + multiple domain agents), shared skills in ~/.openclaw/skills/ are the high-leverage cross-cutting infrastructure — standardized procedures used by every agent. Skill Workshop captures per-workspace patterns well, but skillDir() in extensions/skill-workshop/index.js enforces <workspace>/skills/-only writes via a path-traversal check. The result: shared skills can never be improved via the workshop.

Two specific pains:

1. Refinements to existing shared skills don't happen automatically. When an agent uses a shared skill and discovers an ambiguity or pitfall, the workshop has no way to propose an append/replace. Improvement requires a human to read enough outputs to notice — exactly the bottleneck the workshop was designed to address.

2. Cross-cutting patterns don't get promoted. When multiple domain agents independently propose similar workspace skills (because they're solving similar work), there's no mechanism to detect the cross-workspace pattern and promote it to shared. Each agent reinvents the same procedure in isolation.

The existing safety primitives (pending approval, content scanning, quarantine, max bytes) are exactly what's needed for safe shared-skill modification. The only missing piece is opt-in support for targeting the shared skills root.

Proposed solution

Three additions, each opt-in and backwards-compatible:

PART A — Optional shared-skill targeting

Add config options to the skill-workshop plugin and per-agent config:

plugins.entries.skill-workshop.config: allowSharedTargeting: false # default; opt-in sharedSkillsRoot: "~/.openclaw/skills"

agents.list[].skillWorkshop: targetSharedSkills: false # default; opt-in per-agent

When targetSharedSkills is true for an agent:

• The workshop's suggest action accepts a target: "shared" | "workspace" parameter (default "workspace")
• When target is "shared", skillDir() resolves against sharedSkillsRoot instead of workspaceDir/skills
• Path-traversal check expanded to allow either root, but only the agent's selected target
• All other safety primitives unchanged: pending policy, scanner, quarantine, maxSkillBytes, maxPending
• Domain agents without the opt-in are unaffected — they continue writing per-workspace only
• apply: true should NOT be honored for shared-skill proposals regardless of approvalPolicy = "auto" — shared skills always require explicit human approval

PART B — Cross-workspace pattern detection

When allowSharedTargeting is true and reviewMode includes "llm" or "hybrid", add a periodic cross-workspace reviewer:

• Runs on a configurable interval (e.g., every N hours, or after each capture round)
• Reads pending and applied proposals across all workspaces
• When >= 3 workspaces have semantically-similar proposals (similarity threshold configurable), generate a "shared skill candidate" proposal targeting sharedSkillsRoot
• The candidate proposal includes the originating workspace proposals as evidence/source
• Goes through the same pending → safety scan → review → apply flow

Config: plugins.entries.skill-workshop.config.crossWorkspace: enabled: false # default; opt-in minMatchingWorkspaces: 3 similarityThreshold: 0.8 intervalHours: 24

PART C — Explicit promote_to_shared action

Add a new tool action that takes an applied workspace skill and creates a pending proposal for the equivalent shared skill:

{ action: "promote_to_shared", workspaceSkillName: "quarterly-forecast", sourceWorkspace: "workspace-agile-velocity" // Generates a pending proposal at sharedSkillsRoot/quarterly-forecast/ }

This makes manual promotion a first-class action with full safety flow (scanner, quarantine if critical, pending review).

Alternatives considered

1. Symlink hack — replace <workspace>/skills with a symlink to ~/.openclaw/skills for the orchestrator workspace. Works because path.resolve doesn't follow symlinks, but architecturally ugly: mixes the orchestrator's per-workspace skills with agency-wide infrastructure, no clean separation if you later want both, and future updates to path-resolution logic could break it. Also feels like an exploit of an unintended gap rather than a supported path.

2. Build a parallel custom plugin/skill — implement workshop-style behavior for shared skills outside the official plugin. Reinvents the wheel, maintenance burden moves to the user, no benefit from upstream improvements to safety scanning, content quarantine, or LLM review.

3. Manual port (status quo) — review per-workspace proposals, manually copy good ones to ~/.openclaw/skills/ via direct edit + git. Doesn't scale: 18 agents proposing similar things each week creates ongoing friction, and shared skill refinements still require a human noticing the pattern by reading outputs.

4. Manual editing of shared skills via developer tools (Claude Code, direct edits, git PRs) — works today and is what we do now. But it misses the value the workshop provides: surfacing patterns the human didn't notice. The whole point of the workshop is post-hoc reviewer analysis catching things the developer wouldn't think to check. Confining that to per-workspace cuts off the highest-leverage skill set from automated improvement.

Impact

Affected users/systems/channels:

• Multi-agent operators (agencies, teams) running orchestrator + worker patterns
• Anyone with shared skills representing cross-cutting infrastructure (the case the docs explicitly endorse)
• Solo-agent operators are unaffected — they don't typically maintain shared skills

Severity: Medium

• Not a blocker — the workshop still works for per-workspace skills
• But the entire shared-skill layer is excluded from automated improvement
• For multi-agent setups, shared skills are usually the highest-leverage skill type, so excluding them undermines the workshop's strongest case

Frequency: Weekly to daily

• Per-workspace proposals arrive frequently; each one COULD be a refinement to an existing shared skill but has to be either ignored or manually ported
• Cross-cutting patterns recur every time a new agent does similar work

Consequence:

• Manual review and manual porting of refinements (~30-60 min/week per active operator)
• Shared skills drift away from current best practice because there's no improvement loop
• Cross-workspace pattern recognition entirely manual — operator has to read across workspaces
• Discourages investment in shared skills since they can't compound the way per-workspace skills can

Evidence/examples

Source code reference (current limitation): extensions/skill-workshop/index.js:135-141 — skillDir() enforces <workspaceDir>/skills/ root with explicit path-traversal check. There is no override mechanism.

Concrete use case: Multi-agent operational setup with one orchestrator + multiple domain-specialist agents (one per business area or account). Shared skills cover cross-cutting infrastructure such as artifact storage, report generation, audit/analysis pipelines, and structured deliberation workflows. Each shared skill is used by every domain agent.

When an agent discovers a refinement (e.g., a step's instruction was unclear in a specific case, or a section format could benefit from a new field), there is no path for the workshop to capture and propose that refinement. Improvement only happens when a human reads outputs and notices the issue.

Cross-cutting pattern example: After enabling skill-workshop, expect multiple domain agents to independently propose similar workspace skills based on their work (e.g., similar report-generation procedures). Each proposal is per-workspace and has to be manually unified into a shared skill. With Part B, the workshop would surface this as a cross-workspace candidate after the third similar proposal.

Related issues (orthogonal to this proposal):

• #35272 — sub-agents can't access shared skills (visibility bug, not modification)
• #15717 — per-agent skills allowlist (which agents see which skills)

Neither addresses workshop-driven modification of shared skills.

Additional information

Implementation notes:

• Bulk of Part A is in skillDir() and resolveWorkspaceDir() in extensions/skill-workshop/index.js
• Proposal store keying (workspaceKey(workspaceDir)) needs an additional dimension for shared-targeted proposals so they don't collide with per-workspace proposals
• Part B (cross-workspace pattern detection) is more involved — a separate reviewer pass that reads across multiple workspace stores. Could land as a follow-up if Part A ships first.
• Part C (promote_to_shared action) is the smallest piece — could be the v1 if A and B are deferred.

Backwards compatibility:

• Default config values keep current behavior unchanged
• No existing user is affected unless they explicitly opt in
• No breaking changes to the tool's existing actions

Happy to:

• Test alpha builds against a real multi-agent setup with active shared-skill usage
• Provide more details on the use case
• Contribute a PR if there's directional alignment from maintainers