Skills Settings UI — browse and configure installed skills

[shanselman]

Summary

Add a settings/configuration UI for managing Clawdbot skills directly from the tray app, instead of requiring manual config file edits.

Background

Clawdbot skills are currently managed via CLI (clawdbot skills install/remove) and configured by editing JSON config files. A GUI would make skill management more accessible, especially for discovery and configuration of skill-specific options.

Proposed Features

Skills Browser

• List all installed skills with name, description, and enabled/disabled status
• Toggle skills on/off with a checkbox
• Show skill metadata (version, author, description from SKILL.md)
• Visual indicator for skills that have configuration options vs. simple on/off

Skill Configuration

• Per-skill settings form, dynamically generated from the skill's config schema (if available)
• Text fields, toggles, dropdowns as appropriate for each setting
• Save writes back to the gateway config and triggers a restart

Skill Discovery (stretch)

• Browse available skills from ClawdHub (clawdhub.com)
• One-click install from the UI
• Show install progress

Implementation Ideas

• New SkillsSettingsForm with a list/detail split layout
• Left panel: skill list with icons/status; right panel: detail/config for selected skill
• Read installed skills via gateway API
• Config changes go through gateway config.patch to stay safe
• Could reuse the SettingsDialog patterns already in the codebase

Acceptance Criteria

• Can view all installed skills and their status
• Can enable/disable skills from the UI
• Can edit skill-specific configuration where applicable
• Changes persist correctly (written to config, gateway restarted)
• Graceful handling when gateway is unreachable

[shanselman]

Closing as won't-implement. After investigating the OpenClaw architecture, skills are a gateway-side concept — they live on the gateway machine and are managed locally via \openclaw skills list/info/check. There is no gateway WebSocket API for skills management.

The Windows tray app is a node (remote device), not a gateway. Nodes expose capabilities (system.run, screen, camera, canvas) — which is a different layer than skills. The node-appropriate settings we already have (exec approval policy, capability registration, device pairing) are the correct UX for a remote node.

What we have vs. what this issue proposed:

• ✅ Capability management (system.run, screen, camera, canvas) — already working
• ✅ Exec approval policy UI — already implemented
• ✅ Node status / connection management — already working
• ❌ Skills browser/marketplace — not applicable to nodes (gateway-only concept)

If OpenClaw adds a gateway RPC for skills management in the future, we could revisit this as a 'remote gateway admin' feature, but that's a different scope.