Skills page shows 52 skills but agent only sees ~12 — UI ignores runtime dependency filtering

[yikkuro]

Summary

The Skills page shows 52 built-in skills as enabled/available, but the agent at runtime only sees a small subset (12 in this case). There is no indication in the UI of which skills are actually usable. The UI reflects only the allowBundled opt-in list, while the OpenClaw runtime additionally filters skills by whether their dependencies (required CLI binaries / env / OS) are satisfied on this machine. The two views disagree, and the app never surfaces the runtime eligibility, so users believe 52 skills are active when most are silently filtered out.

Reproduction

1. Open Settings → Skills. It lists 52 built-in skills, all shown as installed and (mostly) enabled.
2. Ask the agent "how many skills can you see / use?".
3. The agent reports 12, not 52.

Observed on this Windows machine:

• 6 bundled skills loaded (deps satisfied): coding-agent, gh-issues, github, healthcheck, skill-creator, weather.
• 6 user skills from ~/.openclaw/skills/ (no binary deps): desktop-organizer, excel-xlsx, officecli, powerpoint-pptx, security-practice, word-docx.
• ~40 bundled skills filtered out because their required CLIs aren't installed, e.g. op (1password), curl, python3, jq+rg (session-logs), ffmpeg (video-frames), tmux, himalaya, sag, etc. Only git and gh are present from the full required-binary set. Many of these tools are macOS/Linux-oriented.

Root cause

The MicroClaw UI and the OpenClaw runtime compute "available" differently.

UI (desktop/src/main.ts skills:list, ~lines 2470–2568): a skill's enabled flag is derived only from the allowBundled opt-in list (and entries for managed), and every on-disk skill is returned with installed: true. There is no check of the skill's declared dependencies (required binaries, env vars, OS):

if (source === "builtin" && allowBundled && allowBundled.length > 0) {
  enabled = allowBundled.includes(entry.name);   // opt-in only; no dep check
}
...
results.push({ id, name, ..., enabled, installed: true });

Runtime (openclaw package, config-*.js shouldIncludeSkill): after the allowlist check, the skill must also pass evaluateRuntimeEligibility, which requires the declared binaries/env/OS to be present:

function shouldIncludeSkill(params) {
  ...
  if (skillConfig?.enabled === false) return false;
  if (!isBundledSkillAllowed(entry, allowBundled)) return false;
  return evaluateRuntimeEligibility({
    os, remotePlatforms, always, requires,
    hasBin: hasBinary,             // ← required CLI must exist on PATH
    hasEnv, ...
  });
}

So a skill can be allowBundled + enabled:true + installed:true in the UI, yet be excluded by the runtime because (say) op/ffmpeg/python3/tmux isn't installed. The UI has no visibility into requires/hasBin, so it always reports the skill as available.

Impact

• Misleading: users think all 52 skills are active; the agent actually exposes ~12. Asking the agent produces a number that contradicts the Skills page.
• No discoverability: nothing tells the user why a skill won't run or what to install to enable it (e.g. "requires op CLI").
• Compounds with the existing "X/Y enabled" header count, which also ignores runtime eligibility.

Suggested fixes

1. In skills:list, evaluate each skill's declared dependencies (mirror OpenClaw's evaluateRuntimeEligibility / requires + binary-on-PATH check) and return an eligible/available flag plus the list of missing requirements.
2. In the Skills UI, visually distinguish enabled-but-not-runnable skills (e.g. a "Requires: op" badge / muted state), and show the count of actually-usable skills.
3. Optionally surface an install hint / link per missing dependency (OpenClaw already tracks install + missing.bins per skill in its control-ui skills view).

Environment

• MicroClaw desktop (Electron dev build), Windows.
• Built-in skills dir: %APPDATA%\npm\node_modules\openclaw\skills (52 dirs).
• Runtime filtering in the bundled openclaw package (shouldIncludeSkill / evaluateRuntimeEligibility).

Screenshots

Settings -> Skills shows Built-in Skills (52) with 52/52 enabled:

But the agent, asked what skills it has, lists only 12:

[boycez]

Skills not compatible with Windows (6)

• apple-notes — requires macOS Apple Notes.
• apple-reminders — requires macOS Apple Reminders.
• imsg — requires macOS Messages and iMessage tooling.
• peekaboo — macOS-only UI automation.
• model-usage — restricted upstream to macOS and CodexBar.
• tmux — supported upstream only on macOS and Linux.

Skills compatible with Windows and ready-for-use after MicroClaw installation (9)

• healthcheck — uses OpenClaw and built-in PowerShell security commands.
• skill-creator — uses OpenClaw’s built-in Skill Workshop.
• canvas — ready, although presenting content requires a Canvas host or compatible connected node.
• security-practice — instruction-only MicroClaw security guardrails.
• desktop-organizer — uses PowerShell; requires desktop permission and user approval before moving files.
• officecli — automatically downloaded by the installer; ready when that download succeeds.
• word-docx — requires OfficeCLI or another DOCX editing and rendering tool.
• excel-xlsx — requires pandas/openpyxl or a suitable implementation such as OfficeCLI.
• powerpoint-pptx — requires OfficeCLI or another PPTX editing and rendering tool.

Skills compatible with Windows but requiring additional dependencies or setup (14)

• 1password — requires the op CLI and configured 1Password authentication.
• blucli — requires the blu CLI and BluOS hardware.
• coding-agent — requires an authenticated claude, codex, or opencode CLI and explicit enablement.
• mcporter — requires the mcporter npm package and MCP server configuration.
• nano-pdf — requires uv and the nano-pdf Python package.
• obsidian — requires Obsidian 1.12.7+, its CLI enabled, and the app running.
• openai-whisper — requires Whisper, FFmpeg, and a downloaded speech model.
• openhue — requires the OpenHue CLI, a Hue Bridge, and paired lights.
• oracle — requires the Oracle npm CLI and model or browser authentication.
• session-logs — requires jq and rg/ripgrep.
• sherpa-onnx-tts — requires its Windows runtime, a voice model, and environment configuration.
• songsee — requires the songsee CLI; some formats also require FFmpeg.
• sonoscli — requires the sonos CLI and Sonos hardware.
• video-frames — requires FFmpeg.

Skills listed in catalog but actually unavailable (1)

• desktop-beautify — listed in MicroClaw’s catalog, but its skill directory is missing, so the installer cannot deploy it. Its advertised workflow would also require Notezilla.

[ofekron]

I would make the UI model explicitly separate three states, because “enabled” and “usable by the agent” are different facts:

1. installed: the skill files exist on disk.
2. enabled: the user/config allow this skill to be considered.
3. eligible: runtime requirements are satisfied for this host/session.

Then the Skills page can show something like enabled but unavailable with the exact missing requirement list, while the agent runtime uses the same eligibility result to build the actual exposed skill set. That avoids two independent implementations drifting again.

For Windows specifically, I would also include the current host facts in the returned diagnostic payload: OS, shell family, PATH source, detected binaries, missing env vars, and whether the skill was filtered by OS vs binary vs env. That makes screenshots and bug reports actionable without asking the user to run a second command.

I maintain Better Agent (https://github.com/ofekron/better-agent), which has similar state-projection problems across configured tools, runtime tool availability, provider-specific capabilities, and UI visibility. The relevant comparison point is keeping the backend/runtime capability resolver as the source of truth, with the UI rendering that resolved state instead of recomputing it.

If Better Agent is useful as a comparison point, consider starring the repository. This is optional.

Disclosure: I maintain the linked project. This comment was drafted with AI assistance and reviewed before posting.