[FEATURE] Sync Skills between Claude Desktop and Claude Code CLI

+1

+1

Skill portability across Claude surfaces is a top priority for a lot of people. Having to recreate skills separately in Desktop and CLI is a real workflow killer.

claude-brain solves the cross-machine part for CLI skills — keeping your skills directory synced via git hooks. But the Desktop ↔ CLI bridge really needs native support. Would be great to see a unified skill store that works everywhere.

+1
A simple cloud backup of all skills and pulldown of the skills when needed is an absolutely necessary. There is otherwise no tracking of what version is available on which device (if at all available)

I put my support behind this too!

but, it would need to sync Web, Desktop, and CLI. So ~/.claude/skills/ isn't the best place for it.

Was just looking at how I can do this, glad I found this. +1

This is definitely a huge +1. I switch between coding tasks (~30% of work) and business/workflow tasks, the latter of which I tend to use the desktop app for. I don't want to keep in sync manually skills that apply in both cases.

We had a similar discussion forever ago with MCPs - but the thing was that not everyone wanted the same list of MCPs on one service/app as they did in another. You're going to use different services for different purposes and different tools (eg. MCPs) for each one.

But, skills is a little different. But there are some skills that work in claude code that won't work in Claude desktop (eg. ones that make api requests to blocked URLs or ones that can't run CLI commands in Claude desktop's sandbox)

Claude Desktop > Code tab, I believe already pulls from ~/.claude/skills/ so that's not the issue we're talking about.

For now, manually copying/downloading the skills you want from ~/.claude/skills or Claude Desktop > Cowork tab > Customize and pasting/uploading them into the other doesn't take that long really...

+1

+1

+1

This is purportedly a tool to do this: https://github.com/kcchien/skills-cli

+1

+1

+1

+1
I Added a comment to an similar issue about why the skills/connectors/plugins settings in the "customize" window of the desktop app needs to be exposed and available to interact with programatically.

#Feature Request: API for syncing skills between Claude Code and Claude Chat/Projects #47968

My comment Text:

### Overview The lack of centralized, programmatically accessible skill management creates real friction for power users who work across multiple Claude surfaces (Claude Code, Claude API, Cowork, Claude.AI). Right now, there's no clean way to maintain a single source of truth for your skills/commands, which forces awkward workarounds that break down quickly. ### Current Pain Points Managing skills across Claude surfaces is a significant bottleneck for power users. Here's a breakdown of the core issues: - No scalable GUI management Any time I want to update a skill, I have to manually open the Desktop GUI, replace files, and propagate those changes elsewhere by hand. There's no sync, no automation hook, and no API surface. For users who treat skills as versioned configuration, this is a real bottleneck. - Duplicate skills / precedence problem I've had to resort to maintaining an external skills and configuration GitHub repo, running hooks on session start to install it. The problem is that if a skill exists both in the Desktop app and in my repo, the Desktop app version always wins — silently overwriting the repo version I'm actively trying to use. There's no way to control precedence or opt out of this behavior. To use these skills in claude.ai, I have to manually update them to ensure the latest versions are present in the Desktop app. - External repo-sync workaround breaks /commands in Claude Code In Claude Code, there's no way to reference skills defined in the Desktop app as slash commands, and this problem is compounded for users relying on the external repo-sync workaround. The core issue is that slash command registration for a Code session happens before any hooks run. This means that even if I use a pre-session hook to install/mount my skills repository, it's already too late — the session has already loaded its slash commands from either the Desktop GUI or the cloud customization registry. By the time my pre-hook executes and mounts my skills repo, the window for registering those commands has closed, effectively locking users who rely on this workaround out of a core feature. ### Proposed Solution The immediate priority should be exposing Claude's skills and the entire Customize menu/window programmatically via API. This single change would unlock a cascade of improvements: - Users could make edits, additions, and deletions to their skills programmatically - Automation pipelines (e.g., GitHub Actions) could keep a central Claude skills repository in sync and accessible across all surfaces - The slash commands issue would be resolved — no more race conditions with hook timing, because skills would be registered through a proper API rather than filesystem mounting - Users would no longer need to maintain or mount external skills repositories as a workaround A longer-term option worth exploring would be native GitHub repository sync — similar to how external skill repos work today, but built directly into Claude's connection layer. The application would read against a linked remote repository and allow users to kick off syncs on demand or on a schedule. That said, this feels like a phase two feature. The immediate, high-value win is simply API exposure of the skills/connectors/plugins customization layer. Once that exists, it becomes accessible to automation workflows, keeps skills up to date without manual intervention, and — critically for enterprise customers — allows organizations to programmatically push skill updates, connectors, and eventually plugin configurations across their entire org. That's a substantial unlock for teams trying to standardize Claude behavior at scale. This seems like a natural extension of the existing customization options, and the payoff for power users and enterprise customers would be substantial.

Related Issues - For Visibility:

All open as of 2026-04-11:

• anthropics/claude-code#31597
• anthropics/claude-code#37487
• anthropics/claude-code#20697
• anthropics/claude-code#36693
• anthropics/claude-code#26254
• anthropics/claude-code#26310
• anthropics/claude-code#40774
• anthropics/claude-code#47968

(Figured I'd pull from this recent mention so that we can have this listed in thread for tracking. Thank you Kevin Deldycke)

+1

+1

+1

+1 or claude API to claude desktop app or cowork. We have a repo of internal skills that we have to upload as zip files for each change which is not optimal.

Skills are one dimension of a broader gap — connectors, memory, files, and chat history all suffer the same surface-silo problem. Filed an umbrella issue at #55842 proposing a unified user state across Cowork and chat. Skills sync is load-bearing for that.

+1

+1

+1

+1

+1

+1

+1

+1

Anthropic please, for the love of god, just implement this already! The amount of threads I see begging for this feature on social media/discord/forums without any acknowledgement from your team is ridiculous. Everyday there are new issues opened related to being able to even just programmatically access skills/plugins, let alone asking for some sort of native sync.

You don't even have to give us a native sync feature with ui/ux. Just allow us to access stored skills/sync through the api or various configuration surfaces. Thousands of creative solutions have been offered to remedy this and nothing has been accepted or listened to. The corpses of these many issues filed now pile at your feat, a monument to corporate obstinance. The collective hours wasted engineering/maintaining workarounds to this problem are a catastrophic failure of product management and engineering management.

Just pick ONE option from the many or at least offer some explanation on why this is not something being prioritized.

+1

+1

Without a solution like the one proposed here, not only does the user have to add the same skill twice, but extra work is is required to maintain them.

This can lead to clumsy workarounds like:

• having to remember to manually keep a given skill updated in two places or risk skill drift between Claude Cowork and Claude Code. This is especially problematic when collaboratively building shared skills within a team across diverse surfaces and workflows.
• skipping the more "global" skill installation step and then having to remember to install relevant skills in each project that needs them. Forgetting something in a given project can lead to flawed outputs, wasted effort and time, rework, and lots of frustration with the products.

Yes. I can build automation to help with these items. But often this defeats the purpose of having skills in the first place!

It would be great to have full two-way synchronization of both skills in the cloud and skills in the local directory (~/.claude/skills/), and for all types of systems: Claude Chat, Claude CoWork, Claude code.

We had a similar discussion forever ago with MCPs - but the thing was that not everyone wanted the same list of MCPs on one service/app as they did in another.

Sure. This only means the config needs a way to specify which tools are exposed to the skill / MCP.

Even better, since Claude is great but not the whole world: A tool-agnostic location for both MCP config and skills. E.g. on Linux ~/.config/agents/skills etc.

Agreed. And if Antropic feels we still need a set of desktop-only skills, then we could have a different location for those non-shared skills.

I would also really like to have this!

Adding support, with one note on scope that may be worth separating out.

The proposal here is a single shared local location read by every surface. That closes the CLI/Desktop gap, but it cannot close the cloud one: a cloud sandbox has no access to the local filesystem, so scheduled routines and Cowork still resolve skills from the account-level claude.ai deployment store regardless of what lives locally. @marr00n raised the same point earlier in this thread. #76724 confirms the resolution model with a concrete failure.

The part that bites hardest in the cloud case is that drift is silent. If a skill is edited locally and never re-uploaded, the scheduled run completes successfully against the older deployed version, with no error and no version mismatch surfaced anywhere. There is currently no way for local tooling to even ask what version is deployed.

I have filed #84611 for that narrower piece: a programmatic publish path, and a way to list deployed skills with a version or content hash so local tooling can diff local against deployed. Complementary to this issue rather than a replacement. Also relevant: #47968 asked for the API previously and was auto-closed as stale, then locked.

Until this lands natively, here's a workaround pattern I've been running daily across Claude Code CLI and Claude Desktop/Cowork on the same skills:

• Single source of truth: the plugin (skills) lives in a git repo together with my markdown knowledge base.
• CLI side is fully automatic: ~/.claude/skills/<plugin> is a symlink into the repo working copy — every edit is live in the next CLI session, nothing to sync.
• Desktop/Cowork side is one manual step per version: a packaging script validates the skills and zips a .plugin file for upload. Two gotchas that cost me time: the filename must not contain the version (Cowork derives the plugin name from the filename, so a versioned name creates a duplicate plugin instead of updating it), and the local session cache under local-agent-mode-sessions/ is session-scoped — don't build tooling on that path.
• A git auto-commit tool (obsidian-git in my case) makes the repo side hands-free.

Repo with the scripts, the skills (sanitized) and a longer write-up: https://github.com/tkkrixi/claude-docs-sync

Native support would still be much better — the manual desktop upload is the remaining friction this can't remove.

@jmaxzh Happy to clarify. My main pain point was Desktop ↔ CLI sync on a single machine: the same skills maintained once, available in both. Version conflicts and multi-user reuse were secondary for me.

Also, a correction to my earlier comment: I wrote that one manual upload per version was the lower bound. That turned out to be wrong — a git-based marketplace repo solves it, including auto-updates. The working recipe, since none of this is documented:

1. The marketplace repo must be on github/gitlab/bitbucket/GH Enterprise — a self-hosted Gitea fails with "This host isn't supported".
2. marketplace.json goes in the repo root under .claude-plugin/.
3. The Claude GitHub App needs access to the repo — this is also what makes private marketplace repos work.
4. "Sync automatically" is off by default, hidden in the ... menu next to the marketplace name (next to "Synced commit" and "Check for updates").
5. The version field in the marketplace.json plugin entry is mandatory for update detection — bumping plugin.json alone leaves the "Update" button greyed out, because detection reads the marketplace manifest.

Full working example (MIT): https://github.com/tkkrixi/claude-docs-sync

What's still unsolved for me: this only covers distribution. True two-way sync (edit a skill on either side, both update) still needs the git repo as the single source of truth and manual pushes.

Hey Anthropic, this "Sounds like a skill issue"!

I too would love to see first class support, for the general case of dotfile sync'ing, from Anthropic.

I have found DIY (but hacky) ways to make this work for myself using a yadm ("yet another dotfile manager"), but I don't exactly love it. There are also convoluted workarounds for the case of ephemeral sessions --which sorta work but haven't always worked right. My current method of syncing for ephemeral sessions could easily have more pitfalls I still don't know about. It feels like a potentially dangerous attack surface from a security perspective also. All compelling reasons to prefer a "blessed" solution from Anthropic.

My current solution lives in my personal (public) dotfiles repo, but I'm filing an issue against my own solution for the ephemeral case because it just doesn't feel robust enough: https://github.com/mark-brannan/dotfiles/issues/17

--Can Claude solve me problems with Claude? (skill issue)