SkillDock: a desktop manager for AI coding skills, MCP servers and plugins

The handoff problem SkillDock is built around

Skills, MCP server definitions and plugin bundles live in per-tool directories. Claude Code reads one path, Cursor another, Codex another. The README frames the core workflow as "team collaboration without intermediate handoff directories": a publisher edits a skill locally and pushes it, a user pulls the update and sees who changed what. That is a real annoyance. The usual workaround is a shared folder, a dotfiles repo, or a script that copies files into each tool's config location, and every one of those loses the link between the file on disk and the repository it came from. SkillDock's answer is to keep Git-based skills and plugins as real repositories and treat the tool directories as sync targets rather than sources of truth. The target user is a developer on a team where more than one person maintains skills, and who runs at least two coding agents. If you use one tool and write your own skills, the scanning and sync machinery has nothing to do.

Real-directory scanning, and why that changes the diff

The README says SkillDock "scans each tool's real Skill directory, shows managed and unmanaged Skills, and lets users preview local changes before updating or pushing." Unmanaged is the interesting category: skills that exist in a tool's directory but were never installed through SkillDock. The app can import them into its own library or remove them from the current tool. That matters because most people accumulate skills by cloning a repo straight into the config folder, and any manager that only knows about its own installs will silently ignore half of what the agent actually loads. SkillDock also reports conflicting entries, which is the state you get when the same skill name exists in two places and you cannot tell which one wins at runtime. The README does not specify the resolution order the underlying tools use, so treat the conflict flag as a prompt to inspect, not as a fix.

Git as the storage layer, not a bolt-on

The Git workflow is the part with the most detail in the README. SkillDock detects upstream updates, local edits and pending pushes, and shows staged and unstaged diffs with the ability to revert individual files or hunks. Plugins get the same treatment, including "local change and pending-push detection for Git-backed plugins." This is a different design from managers that copy files into place and forget the origin. Here the repository stays the unit of record, and the per-tool enablement is metadata layered on top. The README states that SkillDock "preserves source information and tool enablement per skill, so a team-maintained skill can stay connected to its upstream repository while still being applied selectively." Hunk-level revert is a small feature with an outsized effect: it means a local tweak to a shared skill does not have to be thrown away when upstream moves, which is the failure mode of every copy-based sync script I have seen described.

Installing from skills.sh, ClawHub, MCP.Directory and Git

Install flows are split by package type. Skills come from skills.sh and ClawHub with one click, or from Git repositories and local folders. MCP servers come from MCP.Directory. Plugins come from Git repositories, after which you select the supported host tools and enable bundled skills, commands, agents and integrations. The README's own framing is that "a plugin can expose skills, agents, commands, MCP integrations, and host-specific capabilities; SkillDock installs the package once, tracks its source, and lets you enable or disable it for compatible tools." Note the asymmetry: skills and MCP servers have hosted directories, plugins do not, so plugin installation is Git-only. The README does not document a CLI, a config file format, or a way to script these installs, which is consistent with a desktop app but worth knowing before you plan to put it in CI.

Platform support and the tool list you should read carefully

The README badge lists the platform as "macOS Apple Silicon | Windows x64". There is no Intel Mac build and no Linux build mentioned anywhere in the supplied material. The supported tool list is long: Claude Code, Codex, Cursor, Windsurf, IntelliJ IDEA, OpenCode, Gemini, Antigravity, Continue, GitHub Copilot, Qwen Code, Trae, Trae CN, Cline, Roo Code, Kilo Code, Kiro, Goose, Junie, Augment, CodeBuddy, Droid, OpenClaw, CommandCode, Crush, Qoder, Zencoder, Hermes, iFlow, Pi, OMP, Grok Build, MiMo Code and WorkBuddy. A list that long invites a question the README does not answer: what "supported" means per tool. Detection of a config path and full read-write sync are different levels of integration, and the material here does not break the list down. Verify the two or three tools you actually use before assuming parity. The Tools screen is described as showing detected tools and their skill and MCP config locations, which is the place to check.

What the documentation does not settle

Several things a cautious adopter would want are absent. There is no description of how credentials or tokens for private Git repositories are stored, which matters because the app pushes on your behalf. There is no statement about whether the app phones home, beyond a settings entry for update checks. The install troubleshooting document exists (docs/install-troubleshooting.md) but its contents are not in the supplied material. The README badge says version 1.0.8 while the recent releases list runs to v1.0.20, so the badge lags the actual release; treat the releases page as the source of truth for what you are downloading. Release cadence is high, three releases in two days across v1.0.18 to v1.0.20, which suggests active work but also means the surface you audit today is not the surface you get next week. None of this is disqualifying. It is the ordinary gap between a fast-moving desktop tool and the documentation a team needs before standardizing on it.

The alternative: hand-rolled directory sync

The realistic alternative is not another GUI. It is a dotfiles repository plus a copy step, or a small script that symlinks each tool's skill directory back to a checkout. That approach has real advantages: it is text, it is reviewable, it works on Linux, and it runs in CI. What it does not do is tell you which skills in a tool's directory came from outside the repo (SkillDock's unmanaged category), surface conflicts between two copies of the same skill name, or show a hunk-level diff before an update lands. If your team already has a working symlink setup and everyone is comfortable editing JSON by hand, SkillDock replaces a script you understand with a binary you do not. The trade is legibility for visibility. That is a fair trade for some teams and a bad one for others, and the README does not pretend otherwise.

Licence, maintenance and what to check before installing

SkillDock is MIT licensed, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. That is a permissive licence with no copyleft obligation on your own code, but it also means no warranty, and the MIT text is not a security guarantee. Nothing in the supplied material tells you who maintains the project beyond the repository owner or how many people are involved, so plan for the bus factor accordingly. On upgrade cost: a desktop app with a built-in update check means upgrades are mostly automatic, but the app writes into your tool config directories, so a release that changes sync behaviour can change files your agents read. Before installing, confirm the release asset matches your platform (Apple Silicon or Windows x64), read docs/install-troubleshooting.md if the installer complains, and set the app storage directory in Settings to a path you already back up. Then import one unmanaged skill, inspect the diff, and only after that point the app at the rest of your library.

Editorial conclusion

SkillDock fits teams that already keep skills in Git and are tired of copying folders into each tool's config directory by hand. It does not fit anyone who wants a headless CLI, a server-side sync service, or a tool that can be audited line by line before it touches ~/.claude or ~/.cursor. Verify three things first: that the release build for your platform is signed or at least checksummed, that the app storage directory in Settings points somewhere you back up, and that a dry run on a throwaway skill shows the diff before it writes, not after.

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. wanghuan9/skilldock on GitHub