Summary

Skill Workshop can be enabled and loaded, with auto-capture working, while the manual skill_workshop tool is still hidden from agent sessions because the default/local tools.profile: "coding" does not include group:plugins.

This is consistent with the documented tool policy, so I do not think this is a runtime bug. The confusing part is that the normal inspection path makes the plugin look healthy, but does not point operators to the required tool-policy grant.

Environment

• OpenClaw: 2026.5.26 (10ad3aa)
• Surface: Telegram topic session / Codex agent run
• Plugin: Skill Workshop
• Tool profile: tools.profile: "coding"
• Skill Workshop config: approvalPolicy: pending, reviewMode: hybrid, autoCapture: true

What happened

After enabling Skill Workshop and resetting the current topic session:

• openclaw plugins list --enabled showed Skill Workshop as enabled.
• openclaw plugins inspect skill-workshop showed the plugin loaded.
• Skill Workshop config was present and valid.
• Auto-capture was working and had produced pending proposals.
• But in the agent session, ALL_TOOLS did not include skill_workshop, and tools.skill_workshop was undefined.

Inspection also showed:

• Shape: non-capability
• Capability mode: none

That initially made this look like a plugin capability/registration problem, but the actual cause was tool policy: coding does not include group:plugins.

Workaround verified

Adding the exact tool to tools.alsoAllow fixed the issue without opening up all plugin tools:

{
  "tools": {
    "profile": "coding",
    "alsoAllow": ["skill_workshop"]
  }
}

After restarting/starting a fresh run:

• the agent could see and call skill_workshop
• skill_workshop action=status returned successfully
• current status was pending=2, quarantined=0, applied=0, rejected=0

Why this is confusing

The operator-facing state says "plugin loaded" and "config valid", while the manually callable tool is absent. That absence is technically caused by tool policy, but the current diagnostics do not make that actionable.

The docs do state that:

• coding excludes group:plugins
• group:plugins contains tools owned by loaded plugins

But for Skill Workshop specifically, the expected workflow is easy to misread because auto-capture can work while the manual review tool is unavailable.

Request

Please add one of the following diagnostics/docs improvements:

• openclaw doctor warning when Skill Workshop is enabled but skill_workshop is not allowed by the active tool policy.
• plugins inspect skill-workshop hint such as: "Tool registered but hidden by tools.profile; add tools.alsoAllow: ["skill_workshop"] or allow group:plugins."
• Skill Workshop setup/docs note that tools.profile: "coding" users need tools.alsoAllow: ["skill_workshop"] for manual status/list/apply calls.
• Optionally, an install/enable-time hint for plugin-owned tools that are registered but filtered by the active profile.

Related issues

This is adjacent to, but not the same as:

• Tool policy pipeline falsely warns about plugin tools in alsoAllow #77801: plugin tools in alsoAllow warning as unknown
• [Bug]: Breaking change: api.registerTool() silently fails without contracts.tools since 2026.5.2 #77800 / [BUG] openclaw-lark plugin: contracts.tools not propagated through createCapabilityPluginRecord #77982 / Plugin loaded but registerTool fails — "plugin must declare contracts.tools" #80621: contracts.tools and plugin tool registration failures
• bug(plugins): plugin tools intermittently unavailable in sub-agent sessions despite contracts.tools and compiled dist (regression from #56208) #80847 / Active Memory embedded runner fails to expose plugin tools when hidden runner is on the DeepSeek provider path #84070: plugin tools unavailable in specific runner/provider contexts

In this case the plugin was loaded and the workaround is normal tool policy; the missing piece is an actionable diagnostic.