[FEATURE] Programmatic publish of local skills to the account-level deployment store that Cowork and cloud routines resolve from

Preflight Checklist

• [x] I have searched existing requests (see "Alternative Solutions" for the related open issues, and for the closed+locked one that previously covered this)
• [x] This is a single feature request (not multiple features)

Problem Statement

Skill resolution differs by surface. Claude Code CLI reads skills from the local skills directory. Cowork, the Claude Desktop Skills panel, and scheduled cloud routines resolve skills from the account-level claude.ai deployment store (confirmed independently, on a different OS, in #76724).

There is no programmatic way to write to that deployment store. The only path is a human opening the Desktop Skills panel and uploading a zip by hand.

That makes deployed skills the one dependency of a cloud routine that cannot be managed as code:

• Cloud routines themselves are programmatically manageable; they can be listed, created, and updated via the routines/triggers API for the same authenticated user.
• The skills those routines invoke are not. A routine can be configured, versioned, and backed up by API, then silently run stale behavior because its skills were edited locally and never re-uploaded.

The failure mode is silent, and that is the core of this request. When a locally-edited skill has not been re-uploaded:

• Local and deployed copies diverge with no signal on either side.
• The cloud routine keeps completing successfully against the old skill version. No error, no warning, no version mismatch surfaced anywhere.
• Local tooling can detect that the skill changed locally, but cannot verify whether the upload ever happened. Only the human knows.

Concrete incident. I maintain a local script that hashes each skill folder and re-zips changed ones for manual upload. It originally hashed only SKILL.md. A change that landed purely in a skill's references/ directory produced no re-zip and no warning, so the deployed cloud copy went stale while my tooling reported everything current. The scheduled routine ran the old behavior for days before it was noticed. I have since changed the script to hash every file in the folder, but that only detects local change. It still cannot confirm what is actually deployed, because nothing exposes that.

It compounds with dependency chains. My cloud routine depends on 11 skills, several of which invoke each other via the Skill tool. A correct deployment is all-or-nothing: uploading 3 of 11 leaves the routine running a mix of new and old behavior, again with no way to detect it. Hand-maintaining an 11-item consistent set through a GUI is exactly the sort of thing that should be scriptable.

Proposed Solution

A write path to the account-level skill deployment store, authenticated as the same user. At minimum:

1. Publish/update a skill from a local directory or zip (create if absent, new version if already present).
2. List deployed skills with a version or content hash, so tooling can diff local against deployed and detect drift without guessing.
3. Delete/unpublish.

The shape matters less than the capability. Any of these would close it:

• An endpoint alongside the existing routines/triggers API, which already establishes the pattern of managing cloud-side account resources programmatically for the same authenticated user.
• A first-class CLI command, e.g. claude skills publish <dir> and claude skills list --deployed.
• A built-in tool callable from a session, mirroring how routines can already be listed and updated in-session.

If only one item ships, ship item 2. The read/diff half is both the higher-value piece and the cheaper one. Even a read-only "what version of each skill is currently deployed" would let user-side tooling detect drift and fail loudly, instead of silently reporting success. Publishing can stay manual as long as its result is verifiable.

Alternative Solutions

• #20697 (open) proposes a single shared local location read by every surface. That addresses the CLI/Desktop-Code-tab axis, but cannot address cloud: a cloud sandbox has no access to the local filesystem, so a shared local directory is unreachable there. Another commenter in that thread raised the same point. Complementary to this request, not a substitute.
• #47968 (closed, locked) requested essentially this API. It was auto-closed as stale, then locked, so the ask is currently unrepresented by any open issue and cannot be revived in place.
• #76724 (open) documents the resolution mismatch and asks for docs plus discoverability. Its discoverability ask overlaps the diagnostic half of this one. Worth noting there that a stale deployed skill is strictly worse than a missing one: missing fails loudly, stale runs silently with old behavior.
• Scripting the Desktop upload endpoint with a session cookie. Undocumented, cookie-authenticated, and liable to break without notice. A silently broken auto-upload is worse than the current manual step, because it reintroduces the exact stale-skill failure it was meant to prevent.

Priority

Important - significantly impairs reliable automation (not a hard blocker; the manual workaround exists but is unverifiable)

Feature Category

Skills / API

Use Case Example

A scheduled cloud routine that reviews pull requests, invoking a set of skills maintained in a git-backed local directory.

Desired flow:

1. Edit a skill locally, commit.
2. Run one command to publish changed skills.
3. Routine picks up the new behavior on its next firing, and tooling can confirm deployed state matches local.

Current flow:

1. Edit a skill locally, commit.
2. Run a local re-zip script.
3. Remember to open the Desktop app and hand-upload each changed zip.
4. No confirmation, anywhere, that deployed state matches local. If step 3 is skipped or partially completed, the routine runs stale behavior indefinitely and reports success.

Additional Context

The routines/triggers API is the precedent worth pointing at: it already exposes cloud-side, account-scoped resources for programmatic management by the authenticated user. Skills are the remaining piece of the same dependency graph with no equivalent path, which is what produces the silent-staleness gap.

#76724 independently confirms the resolution model (Cowork reads the deployment mount, not local disk) from a different user on Windows 11, so this is not environment-specific.