[FEATURE] Visual skills management for product-side users: one place to see and control every skill

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

Claude Code adoption is visibly expanding beyond engineering into product roles: designers, PMs, product-side hybrids. This segment operates in an orchestration model: directing the agent, reviewing output, and encoding working methods as skills. For them, skills are the primary customization lever of the product. Skill management, however, still assumes a developer mental model (dotfiles, YAML, git), and the mismatch is becoming a real adoption friction.

Concrete case, myself: product designer at an IAM company, daily Claude Code user (design systems, Figma to code, shipping MRs), four personal skills authored with Claude. What "having control over my skills" required in practice:

• Discoverability: skills live in ~/.claude/skills, a hidden folder. Inspecting them required learning Cmd+Shift+., then a terminal command (defaults write com.apple.finder AppleShowAllFiles) to make hidden files visible at all.
• False empty state: Customize -> Skills does not list local skills (#77503, #64466) while the engine loads and uses all of them. The one surface accessible to a non-developer reports state that contradicts runtime behavior.
• Trigger opacity: understanding when a skill fires requires reading YAML frontmatter in a markdown file.
• Fragmented stores: local and account skills are disconnected, with no bridge or publish path (#80835, #68071).

None of this blocks a developer. For this typology of users it means no observability and no control over the component that shapes every session.

The workaround I converged on is telling: the skills folder became a git repo, and Claude generates a static HTML map (via a Python build script) rendering my skills and their reference files as clickable tabs, so the system state is finally inspectable in a browser. A user segment rebuilding its own management UI out of generated HTML is a strong unmet-need signal.

Two product observations behind this request. First, this segment is largely visual thinkers: they reason through visible state and direct manipulation, not filesystem conventions; discoverability through hidden folders is a structural mismatch, not a training gap. Second, as the operator role shifts from writing code to orchestrating agents, the inventory of agent capabilities stops being a config detail and becomes a core product surface. It deserves first-class information architecture.

Proposed Solution

A single management surface (Desktop app and/or Code tab) providing observability and control over every skill the engine would actually load:

• Scope badges: personal (~/.claude/skills), project (.claude/skills), plugin, account/cloud
• Trigger visibility in plain language: when the skill fires, surfaced from the description
• View and edit SKILL.md content
• Enable / disable per skill, ideally per project
• Publish local to account store / pull account to local (bridging #68071 and #80835)
• An interactive relationship map: skills do not stay isolated. They reference each other, share reference files, and route to one another (in my own system, one skill acts as a router that delegates work to the others). A graph view (nodes = skills, edges = references and routing) would show which skill is guiding which, and expose overlaps, conflicting triggers, and orphaned skills at a glance.

The relationship map is not a nice-to-have. Skill libraries compound in complexity as they grow, and at that point two user profiles emerge: those who can hold the system in their head (at a real cognitive-load cost) and those who need the structure externalized on screen to operate at all. A visual map serves both profiles: it reduces load for the first and unlocks the second. It is also the exact pattern I had to rebuild by hand in my HTML workaround, and the part I would least want to lose.

Files and git remain the source of truth for developer workflows. This is a presentation and control layer on top of existing stores, not a new storage system.

Alternative Solutions

• Asking Claude "what skills do I have": works, but the answer is ephemeral chat output. Trust requires inspectable state, not a report about it.
• My current workaround: git repo plus generated HTML map, described above.
• Fixing the visibility bugs (#77503, #64466) individually: necessary but not sufficient. It patches one store's visibility without addressing the unified control need.

Priority

High - Significant impact on productivity

Feature Category

Configuration and settings

Use Case Example

1. As a product designer, I author skills with Claude to encode my working methods: a design-to-code skill for our marketing site, a writing skill, an SEO skill, and a router skill that coordinates them.
2. Weeks later I need to check what my agent actually knows: which skills exist, which one will fire on a given request, and which skill routes to which.
3. Today that means unhiding ~/.claude/skills in Finder, opening each SKILL.md, reading YAML frontmatter, and reconstructing the relationships mentally.
4. With this feature, I would open one skills panel: every skill listed with scope badges and plain-language triggers, and a relationship map showing the routing at a glance.
5. This would save me time and, more importantly, give me trust: skills quietly shape every session, and for non-developer users an invisible system is an untrusted system.

Additional Context

Related issues, each reporting a fragment of this gap from the developer angle: #64466, #77503, #80835, #68071. This request consolidates them at the persona level: one unified, visual skills surface for a user segment that is growing faster than the current UX assumes.