SkillDeck puts twelve AI coding agents' skill directories behind one macOS window

The problem is twelve overlapping skill directories, not one missing feature

Each of the coding agents SkillDeck supports keeps its skills in its own directory under the home folder, and the list is long: Claude Code at ~/.claude/skills/, Codex at ~/.codex/skills/, Gemini CLI at ~/.gemini/skills/, Copilot CLI at ~/.copilot/skills/, OpenCode at ~/.config/opencode/skills/, Antigravity at ~/.gemini/antigravity/skills/, Cursor at ~/.cursor/skills/, Kiro at ~/.kiro/skills/, CodeBuddy at ~/.codebuddy/skills/, OpenClaw at ~/.openclaw/skills/, Trae at ~/.trae/skills/ and Qoder at ~/.qoder/skills/.

The problem the app describes is the consequence: no more manual file editing, symlink juggling, or YAML parsing by hand. A skill is a directory containing a SKILL.md file, and the same skill is often wanted in four or five of those directories at once. Copying produces divergence, where an edit in one place never reaches the others, and the natural fix, a symlink, is fiddly enough that people do not do it.

What makes this a desktop application rather than a script is the breadth of the surface. Twelve agents, twelve directory conventions, a marketplace browser for two catalogs, a split-pane markdown editor, an update checker, app-level proxy settings with Keychain-backed credentials, and a full interface in English and Simplified Chinese with in-app switching.

SkillDeck is written in Swift for macOS, requires macOS 14.0 or later, and the project homepage is crossoverjie.top/SkillDeck. The licence is MIT, the last push was on 2026-10-22, and the recent releases are v0.0.27 from that date, v0.0.26 from 2026-06-25 and v0.0.25 from 2026-06-12. A version number in the zero series is worth keeping in mind, since it signals an API and behaviour that may still move.

Skills reading priority: the shared fallback directories that create the duplication

The supported agents table has a column called Skills Reading Priority, and it is the most informative thing in the README.

Most agents read their own directory only. Claude Code reads ~/.claude/skills/ and nothing else, and the same holds for Gemini CLI, Antigravity, Kiro, CodeBuddy, OpenClaw, Trae and Qoder.

Four agents look further afield. Codex reads its own directory and then ~/.agents/skills/, described as a shared global location. Copilot CLI reads its own directory and then ~/.claude/skills/. Cursor reads its own and then ~/.claude/skills/. OpenCode reads its own, then ~/.claude/skills/, then ~/.agents/skills/.

That asymmetry is the real design constraint. Because OpenCode will happily read a skill from ~/.claude/skills/, a skill installed only for Claude Code is already visible to OpenCode and Cursor, and a skill in ~/.agents/skills/ is visible to Codex and OpenCode. So a naive install can make a skill appear in four agents without the user having assigned it there, and a user who wants a skill to appear in exactly one agent has to reason about the fallback order rather than about the agent's own folder.

This is also why the assignment feature exists. Agent Assignment works by toggling which agents a skill is installed to via symlink management, and the priority column is what tells the app which of those toggles actually change behaviour. Assigning a skill to Claude Code and then asking OpenCode to use it produces the same result whether or not the OpenCode toggle is on, because OpenCode falls back to ~/.claude/skills/ anyway.

Detection is the other half of the table, and it is per agent rather than uniform. Some are detected by a binary alone, such as the codex binary, gh binary, opencode binary, antigravity binary, cursor binary, kiro binary, codebuddy binary, openclaw binary, trae binary and qoder binary. Claude Code and Gemini CLI additionally require their directory to exist, ~/.claude/ and ~/.gemini/, so those two only appear in the app once you have used the agent at least once.

The filesystem is the database, and symlinks are the write path

The architecture section is two sentences and a diagram, and both sentences matter.

The first is that the architecture is MVVM with @Observable on macOS 14 and later. The second is that the filesystem is the database: skills are directories containing SKILL.md files. There is no server, no database file, and no index that has to be kept in step with reality, because a skill exists if and only if its directory exists with a SKILL.md in it. The repository layout agrees, with a Sources directory, a Tests directory, a docs directory and a scripts directory.

The write path is symlinks. A skill lives once, in a canonical location, and each agent that should see it gets a symlink pointing at that location. The Flexible Imports feature describes the sequence: install from GitHub or import from a local folder, then auto-create symlinks and update the lock file. Update Checker detects remote changes and pulls updates with one click, and because the canonical copy is the only real copy, an update reaches every agent at once instead of N copies that each need patching.

The lock file is the one piece of state the app maintains outside the skill directories themselves, and it is what lets the app answer what is installed and from where. For a team that tracks these files in version control, that lock file is the thing to look at first, because it is where a symlink layout becomes reproducible for other machines.

File system monitoring is what makes the app feel current. The Auto-Refresh feature watches the filesystem and picks up CLI-side changes instantly, which addresses a real annoyance: an agent's own tooling can add or modify a skill, and without watching, the GUI would show stale state until you relaunched it.

Installing: a signed universal binary, a Homebrew cask, or a Swift build

There are three routes, and the release route has a step that surprises people the first time.

The recommended path is downloading the latest universal binary from GitHub Releases. You download SkillDeck-vX.Y.Z-universal.zip, unzip it, move SkillDeck.app to /Applications/, and on first launch macOS will block the unsigned app. The documented fix is to strip the quarantine attribute:

   xattr -cr /Applications/SkillDeck.app

The README also gives a non-terminal alternative: right-click, choose Open, then Open again in the dialog.

The Homebrew route is a cask, which installs into the same Applications folder:

brew tap crossoverJie/skilldeck && brew install --cask skilldeck

Building from source needs macOS 14.0 or later (Sonoma), Xcode 15.0 or later and Swift 5.9 or later, and the package is a Swift Package Manager manifest, Package.swift, at the repository root:

git clone https://github.com/crossoverJie/SkillDeck.git
cd SkillDeck
swift run SkillDeck

The same build can be opened in Xcode instead:

open Package.swift    # then press Cmd+R

And the test suite is a single command:

swift test

Contributing follows the same shape: fork the repository, create a feature branch with git checkout -b feat/my-feature, run the tests, and open a pull request. The project points at docs/DEVELOPMENT.md for environment setup and coding conventions, and at docs/FEATURES.md for the full feature list and roadmap.

One dependency worth knowing about before you start: the Inline Translation feature, which automatically translates Chinese documentation paragraphs when the interface language is set to Chinese, requires macOS 26 or later, so it is unavailable on the stated minimum of macOS 14.

The dashboard, the two catalogs, and the SKILL.md editor

The Unified Dashboard is described as a three-pane macOS-native view, with all skills in one place. The screenshots referenced in the README show a Dashboard Overview and a Dashboard Registry, plus a skill detail view and an install flow.

The registry side browses two sources. It reads the skills.sh leaderboard and the ClawHub catalog for OpenClaw, with search, sorting and filters. The distinction matters: a leaderboard is a ranking, so popularity and recency are part of what you are sorting over, while a catalog is an index. Neither is a trusted source, which is exactly why the update mechanism exists as a separate feature.

The SKILL.md editor is a split-pane form and markdown editor with live preview. The split between form and raw markdown is the interesting design choice. A skill file has structure, a name, a description, and instructions, and a form exposes that structure while a raw editor exposes the text, so you can use whichever matches the edit you are making instead of hand-editing YAML front matter in a text editor and hoping the parser accepts it.

App settings cover global app fonts and proxy networking, with HTTPS and SOCKS5 options, Keychain-backed credentials and a bypass list. The Keychain part is the detail with a security dimension: a proxy configuration with credentials that live in a plain text file on disk is a file you have to exclude from backups and screen shares, so storing them in the system Keychain removes a class of problem rather than adding a feature.

There is also a built-in skilldeck skill. The README describes it as letting you manage skills via natural language in any AI agent, installing, updating, deleting and assigning skills to agents without leaving your terminal, with its definition at skills/skilldeck/SKILL.md. That is an interesting shape: the desktop app manages the agents, and a skill gives the agents the ability to manage the skills, which closes a loop that would otherwise need you to switch to the GUI mid-task.

Where SkillDeck is the wrong tool

Three limits, and the first one decides the audience immediately.

The first is platform. This is a native macOS SwiftUI application. The universal binary is a macOS app, the build requires Xcode, and there is no Linux or Windows version described anywhere in the README. The underlying problem SkillDeck solves, namely keeping the same skill in several agent directories, is not a macOS problem, and on Linux or Windows the answer is still a handful of symlinks made by hand or by a shell script.

The second is that the duplicate-directory problem only half goes away. Symlinks remove the copy divergence, but they do not remove the ambiguity created by the fallback chains. OpenCode reading ~/.claude/skills/ means a skill can be visible to an agent you never assigned it to, and the Skills Reading Priority column documents this rather than hiding it. If your expectation is that assignment toggles fully determine which agents see a skill, the fallback directories work against that, and the app's UI is where you would notice it.

The third is trust in a marketplace. The registry browser surfaces skills from skills.sh and ClawHub, and skills are instructions that an agent reads and follows, often with the ability to run commands. The app can install from GitHub or import from a local folder and can detect remote changes and pull updates with one click, but the README does not describe any signature check, content review, or permission model for what a fetched skill is allowed to do. For a team, that makes the update path something to think about rather than something to enable for everything.

The alternative approach is to treat the shared directories as the source of truth and skip the GUI: keep skills in ~/.claude/skills/ or ~/.agents/skills/, let the fallback chains do the distribution to Codex, Cursor and OpenCode, and use the per-agent directories only for the agents that read nothing else. The difference in approach is that this gives one canonical location with no symlinks and no lock file to maintain, at the cost of losing the marketplace browser, the editor, the update checker and the assignment view, and of giving up the ability to keep a skill out of an agent that inherits it by fallback.

Editorial conclusion

Adopt SkillDeck if you use two or more of the twelve agents it covers and you keep the same skills in more than one of their directories, because the symlink assignment and the shared fallback directories remove the manual copying that otherwise drifts. Do not adopt it if you work on Linux or Windows, since the app is a macOS SwiftUI binary requiring macOS 14, and do not expect it to replace the agents themselves, since it only manages the files those agents read. Verify first that the skills directory and detection rules for your agent match what SkillDeck expects, since a wrong path means skills are installed somewhere the agent never looks, that the lock file the app maintains is compatible with how you track skills in version control, and that the release you download is signed, since the documented workaround for the Gatekeeper block is to strip the quarantine attribute with xattr.

Frequently asked questions

Official sources

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