Skills Manager: one library for AI agent skills across Claude Code, Codex and Cursor

The problem: skills scattered across every agent's dotfolder

Each coding agent keeps its own skills directory, and the paths do not agree. Claude Code, Codex, Cursor, Copilot and Gemini CLI each read from their own global folder, and project-local skill directories add a second layer on top. If you use three agents, the same skill exists in three places, and a fix you make in one copy never reaches the others. The README frames the project as "One app to manage AI agent skills across all your coding tools," and that is the scope: a desktop application, not a library you import.

The audience is developers who already have more than one agent installed and have started to lose track of which skill lives where. It is not aimed at someone who uses a single tool. If you only run Claude Code, its own skill directory is already a single source of truth, and adding a manager between you and that folder is overhead with no second target to sync to.

How the library, presets and workspaces fit together

The architecture has one central repository and several views onto it. Everything you install, whether from a Git repo, a local folder, a .zip or .skill archive, or the skills.sh marketplace, lands in that central repo. It defaults to ~/.skills-manager and the path is configurable in Settings. That repo is the source; the agent folders are destinations.

The Global Workspace is a per-agent page listing every skill in that agent's global folder, including skills installed outside Skills Manager, so the view reflects what the agent actually sees rather than what the app put there. Project Workspaces do the same for project-local skill folders and add a comparison against the central library, with sync available in either direction. Linked Workspaces point at an arbitrary directory as a skills root, for skills that live outside the default agent paths; the README notes these are managed standalone and do not take part in global preset sync.

Presets are the grouping layer. You name a set of skills, and in a workspace a preset pill activates or deactivates all of them for the current agent scope. The README is explicit that applying a preset is a one-time copy, not a live sync. That distinction matters more than it looks: editing a skill after applying a preset will not propagate to the agents you already applied it to, so the preset is a deployment step, not a subscription.

Installing Skills Manager and adding your first skill

On macOS the README gives a Homebrew cask, and a .dmg from the latest release as the alternative. Windows and Linux are described as downloads from the release page; the README text available here is cut off mid-sentence at "Download the installer f", so the exact Linux package format is not something this article can state.

brew install --cask skills-manager

After launching, the first real task is pointing the app at your central library. The default is ~/.skills-manager and it can be changed in Settings. If you already keep skills somewhere else, decide before you import anything, because moving the repo later means the agent folders you synced still point at the old location.

The repository also ships a CLI alongside the desktop app. The package.json exposes three scripts, and they wrap a Rust binary through a Node runner:

npm run cli:install
npm run cli

The README does not document the CLI's own subcommands, so treat these as the entry points the repository defines rather than a full command reference. For most users the app itself is the path: install a skill from the marketplace or a Git URL, tag it, then use the Add Skills sheet in a workspace to toggle which agents receive it. The agent icon badges on each skill card show live sync state, and clicking a badge installs or removes that skill for that agent.

Letting agents install skills instead of writing into folders

One feature deserves separate attention because it changes the failure mode. The README states that Claude Code, Codex, Cursor and the rest can install a skill, deploy it to another agent, or report what is where by driving Skills Manager rather than writing directly into an agent's folder. The Dashboard sets this up in one click.

The reason given is state integrity: sources, presets, update tracking and per-agent state stay intact. That is a genuine design argument. An agent that writes a file straight into ~/.claude/skills creates a skill the manager has no record of, so its source is unknown, it cannot be update-tracked, and it will not appear in the library view as a managed entry. Routing the write through the app keeps the record complete.

The cost is a dependency. Once agents go through the manager, the manager becomes part of the path for skill installation, and a skill installed while the app is not running may bypass it. The README does not describe what happens in that case, and it does not document rollback for a skill the manager installed on an agent's behalf.

Backup, sync conflicts and what the merge model actually promises

Multi-device sync uses a Git remote, and the README suggests a private GitHub repository connected with one sign-in, though any Git remote is accepted. The app backs the library up automatically and keeps connected devices in sync. Snapshot versions are restorable at any time.

The interesting claim is the merge behaviour. The README says merges are skill-aware, so a rename on one machine combines cleanly with an edit on another, and that true conflicts never block: the local version stays put until you choose keep mine, use remote, or keep both. That is a reasonable posture for a library of small text files, and skill-aware merging is more than a plain Git pull would give you.

Two limits are worth naming. First, this is a backup and sync mechanism for the central library, not for the agent folders it deploys into; the README does not describe restoring an agent's global folder from a snapshot. Second, the sync depends on a Git remote you supply. There is no hosted service described, so the durability of your skills is tied to whichever remote you connect and to your ability to authenticate to it.

Where Skills Manager is the wrong tool

The clearest case against it is a single-agent setup. If you run one tool, the manager adds a layer between you and a folder you can already read, and every skill you install now has two locations to reason about instead of one.

A second case is a team that wants skills versioned alongside application code. Skills Manager keeps its own central repo and deploys outward; it does not make a project's skill folder the source of truth. If your workflow is a pull request that adds a skill to the repository and a CI check that validates it, a manager that copies skills into agent folders is a different model, and the Project Workspace comparison is a manual step rather than a review gate.

A third is Linux. The README's install section covers macOS with a concrete Homebrew command and points Windows and Linux at release downloads, but the available text stops before naming the Linux artifact. Anyone on Linux should check the release assets directly rather than assume a package exists. On the maintenance side, the last push was on 2026-09-08 and releases v1.37.0 through v1.38.0 landed within three days of it, so the project is moving; that is a statement about commit dates, not a quality judgement.

How it compares with managing skills by hand or with plain Git

The realistic alternative is doing this yourself: keep a Git repository of skill folders and symlink or copy them into each agent's directory with a shell script. That approach has real advantages. It has no GUI to learn, it works identically on every platform, and the entire state is text you can review in a diff. For two agents and a handful of skills, a script is often enough.

The difference is in what you get beyond the copy. Skills Manager adds a per-agent view that includes skills it did not install, tag-based filtering with an Untagged pill for finding unlabelled skills, upstream update checks for Git-based skills, in-app reading of SKILL.md and README.md with a comparison against the upstream version, an activity log with a Settings → Export Logs bundle for issue reports, and skill-aware merge on sync. Those are the parts a script does not give you, and they are the reason to accept the extra layer.

A second alternative is to pick one agent's native skill mechanism and standardise the team on it. That removes the multi-tool problem instead of managing it, and it is the honest choice if the other agents are incidental rather than load-bearing.

Licence, updates and the cost of keeping it current

The project is MIT licensed, and package.json carries "license": "MIT" with the repository root holding a LICENSE file. MIT is permissive: you can use, modify and redistribute the code, and the main practical obligation is keeping the copyright and licence notice with copies. That is a summary of the licence text, not legal advice; read LICENSE before you redistribute anything.

Upgrade cost is low by design. The README states the app checks for new versions and installs them on macOS and Windows, and that nothing downloads or installs on its own: checking only notifies, and installing and restarting each take a click. On Linux the in-app updater is not described, so upgrades there fall back to whatever the release page offers. The CHANGELOG.md and CHANGELOG-zh-CN.md files at the repository root are where release-by-release changes are recorded.

The recurring cost is not the binary, it is the mental model. You are choosing a central repo path, a sync mode (symlink or copy), which agents are enabled, and which presets apply where. Those decisions are all reversible in the app, but each one changes what a skill edit does. Teams that adopt it should write down the repo path and the sync mode, because those two settings determine whether editing a skill in the library reaches an agent at all.

Editorial conclusion

Adopt Skills Manager if you run several agents and want one library, one preset system and one backup remote instead of four hand-managed dotfolders. Skip it if you work with a single agent, or if you need a Linux install path the README spells out end to end, because it does not. Before trusting it with your skills, verify three things: that the default central repo at ~/.skills-manager is where you want your sources to live, whether you want symlink or copy as the sync mode, and how the app behaves when a project folder and the library disagree, since Project Workspaces let you push changes in either direction.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. xingkongliang/skills-manager on GitHub