Skill manager: view, add, edit, and link skills across every harness

[n0mahd]

Problem

Skills live in a different directory for every harness: ~/.claude/skills, ~/.agents/skills, <repo>/.claude/skills, <repo>/.agents/skills, ~/.pi/agent/skills, and so on. Users who move between providers end up with duplicated copies that drift apart, or skills that one harness sees and another doesn't. T3 Code already scans every one of these locations per provider for the $ picker, but there's no way to see the gaps or fix them (see #6987, #6883).

Proposal

Revive #4630's read-only Settings → Skills page and extend it to every supported provider (Claude, Codex, Cursor, Grok, OpenCode, Antigravity, Pi), with a small set of actions:

• View: skills grouped by user scope and by project, with per-harness coverage (which harnesses actually load it), its source (one real copy, a symlink, or a drifted duplicate) and the rendered SKILL.md. One view per connected environment, so multi-machine setups can compare.
• Add: create a SKILL.md in the Agent Skills standard location, .agents/skills/, at user scope or project scope.
• Edit: a SKILL.md editor that saves to the symlink's resolved target, so editing a linked skill edits its source.
• Link into all harnesses: symlink the skill into each harness directory that doesn't read .agents/skills (for example .claude/skills/<name>, the same pattern this repo already uses). It never overwrites a real directory. Same-name duplicates with different contents are shown as conflicts for the user to resolve. Precedence is keyed by (scope, location, directory), not by name, per the edge case raised in [Feature]: Discover repo-local `.agents/skills` (Agent Skills standard) provider-agnostically, not per provider #6883.
• Reverse: unlink from one harness, and delete a skill with confirmation.

Server-side these are service methods behind the existing environment auth, so MCP tools for agents are a small follow-up.

Out of scope for the first PR: a mobile UI, MCP tools, marketplace or remote installs, and copying skills between machines (git or dotfiles already do that).

Question for maintainers: would you accept a PR with this scope, or would you rather it ship as a read-only view first with editing and linking as a second PR? I'm happy to share a working prototype in this thread for feedback on the UX before opening anything.

[Yuruzuu]

This would actually be very nice. I'd love to see it at some point with MCP servers being editable per provider too :)

[Jdreioe]

It would be very nice

[n0mahd]

Update: before asking for a PR, I built a working prototype to test this idea against real skill folders. Here is what it showed, what it looks like, and a proposed split into small PRs. Nothing is opened yet. I'd like an explicit yes or no on direction and scope first.

What the prototype showed

• There is already a shared layout to build on. Codex reads .agents/skills/<name>/ (project) and ~/.agents/skills/<name>/ (global) directly, and both the skills CLI and OpenKnowledge install skills there and link other agents' folders to them. Claude only reads .claude/skills, so it needs a link. In one real project, Claude could use 1 of its 36 skills because nothing had linked them.
• Reading the agents' skill folders directly is cheap. Reading ~100 skills across every agent's folders takes 25–90 ms on a Raspberry Pi 5, and the page loads with ~34 KB over the WebSocket. There are no provider rescans, no watchers and no cache. My first version asked each provider to rescan a project instead; that took 18 s and started three extra processes.
• Updates are checkable with one GitHub request per source repo. The lock files the skills CLI already writes (skills-lock.json in a repo, ~/.agents/.skill-lock.json globally) record enough to tell "the source changed" apart from "you edited it". In that same project, 32 of 35 installed skills had upstream changes nobody knew about.

Screenshots (demo data)

Skills for a project, with agents shown as icons (✦ = every enabled agent can use it):

A skill is a folder, so the page shows all of its files and flags scripts agents can run:

An update from the skill's source, shown in T3's own diff view before anything changes:

Tidy up: move a third-party pack to Global or link it for every agent, and resolve duplicates:

Select many skills at once, for example a whole pack, and act on them together:

Phone width:

Proposed PRs, one problem each

1. feat(web): see which agents can use each skill: a read-only Settings → Skills page with project, global, and built-in or plugin skills, each skill's folder with a file viewer, and Reveal in Finder. This finishes what feat(web): add cross-harness skill manager #4630 started. It writes nothing.
2. feat: turn skills on or off for each agent: per-agent links, moving a skill between Global and a project, remove or delete, and bulk actions. It never replaces a real folder and only removes links it can prove are links. On Windows it uses directory junctions so it works without Developer Mode (see [Bug]: Codex ChatGPT connection fails on Windows without Developer Mode: shadow home symlinks fail with EPERM #14325). Agents get the same actions as MCP tools.
3. feat(web): create and edit skills: a new skill dialog and editing through the existing project file writes.
4. feat: tidy up a project's skills: a short health note (for example "Claude can't use 35 of this project's skills") and a guided cleanup.
5. feat: update skills from their source: detection, a diff preview, update one or update all, and merge choices for skills you edited. It stays compatible with npx skills update.

Mobile and scheduled update checks would come later.

Questions

1. Is this direction and scope welcome? I'd open (1) first and wait for review before starting (2).
2. Is it OK to treat .agents/skills as each skill's home and link other agents' folders to it?
3. Where should the per-agent folder list live: next to the existing skill scanners in each provider driver, or in one shared table?

_{Prototype and write-up by Claude Opus 5.5 (orchestrating) and Claude Sonnet 5.5 (implementing), run in T3 Code.}