Chops: a macOS browser for skills and agents scattered across five coding tools
Your AI agent skills, finally organized. A macOS app to browse, edit, and manage skills across Claude Code, Cursor, Codex, Windsurf, and Amp.
At a glance
- What is it?
- Chops is a SwiftUI and SwiftData desktop app that scans the dotfile directories of Claude Code, Cursor, Codex, Windsurf and Amp, then lets you edit what it finds in one window. It is a convenience layer over files you already own, not a runtime for the agents themselves.
- Who is it for?
- Adopt Chops if you already keep skills in more than two of the supported tool directories and you edit them by hand often enough that hunting through hidden folders has become a chore. Skip it if you work in one tool only, if you need a Linux or Windows client, or if you expect the app to validate that your frontmatter is correct.
- Can I use it commercially?
- Check first. The repository uses a licence we do not classify automatically, so read its LICENSE file before any commercial use.
- Is it still maintained?
- Yes. The repository last received commits 23 days ago.
- What is it written in?
- Mainly Swift, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The dotfile sprawl Chops was built to flatten
Skills and agent definitions in current coding tools are just markdown files sitting in hidden directories under your home folder. Claude Code reads from ~/.claude/skills/ and ~/.claude/agents/. Cursor uses ~/.cursor/skills/ plus ~/.cursor/rules, and ~/.cursor/agents/ for agents. Codex keeps its own pair at ~/.codex/skills/ and ~/.codex/agents/. Windsurf stores memories under ~/.codeium/windsurf/memories/ with rules in ~/.windsurf/rules. Amp reads ~/.config/amp/skills/. There is also a shared global location at ~/.agents/skills/ that the README lists as applying across tools. If you use two or three of these, your working set is spread over half a dozen paths, several of which your editor's file tree hides by default. Chops targets that specific friction. It is for people who already maintain a personal library of skills and have started to lose track of which copy lives where. It is not for someone who has never written a skill file, and it is not a way to author skills for a tool you have not installed.
Scanner, parser, watcher: what actually runs when the window opens
The README describes a four step startup. ChopsApp builds a SwiftData ModelContainer that persists two model types, Skill and SkillCollection. The Sparkle updater starts in the background. An AppState object is created and injected into the SwiftUI environment, and ContentView calls startScanning(). From there SkillScanner probes every directory listed in the ToolSource enum and upserts what it finds into SwiftData. SkillParser then dispatches each file to either FrontmatterParser, which extracts YAML frontmatter from .md files, or MDCParser, which handles Cursor's .mdc format. FileWatcher attaches FSEvents listeners, and per the README any change on disk causes the scanner to re-run automatically. Two details in that pipeline matter more than the rest. First, deduplication is done by resolved symlink path. If the same skill file is symlinked into three tool directories, Chops shows one entry carrying three tool badges rather than three rows. That is the right call for anyone who shares skills across tools, and it means the app is doing real path resolution rather than string matching on filenames. Second, search is in-memory through SearchService and covers name, description and content, so it works against the loaded SwiftData store rather than re-reading the filesystem on each keystroke.
Building it from source, and the one file that controls the scan
Chops ships as a signed DMG from the releases page, but the README documents the source path in enough detail to reproduce. Prerequisites are macOS 15 (Sequoia) or later, Xcode with command line tools, Homebrew, and xcodegen installed via brew install xcodegen. The quick start is git clone https://github.com/Shpigford/chops.git, then cd chops, then xcodegen generate, then open Chops.xcodeproj, then Cmd+R. The README is explicit that the Xcode project is generated from project.yml and that editing the .xcodeproj directly is the wrong move; if you change project.yml you re-run xcodegen generate. A headless build is available as xcodebuild -scheme Chops -configuration Debug build. Sparkle is the only external dependency and Xcode pulls it through Swift Package Manager. Adding a tool means editing Chops/Models/ToolSource.swift: add an enum case, fill in displayName, iconName, color and globalPaths, optionally add a logo to the asset catalog and return it from logoAssetName. Because the README says each enum case owns its filesystem paths, that single file is where you would go if your skills live somewhere nonstandard. The README also mentions custom scan paths can be added for any tool, though it does not spell out the config key or UI for that.
No sandbox, no tests, and what that costs you
The design decisions section is unusually candid. Chops disables the macOS app sandbox on purpose, because reading dotfiles across ~/ requires unrestricted filesystem access, and the entitlements file says so explicitly. That is defensible for a local file browser, but it means the app has broader reach than a sandboxed one, and anyone evaluating it should weigh that against the convenience. More consequential for contributors: the README states there is no test suite, and that changes are validated manually by building, running, triggering the feature you changed, and observing the result. For a tool whose whole job is reading and writing files in directories other applications depend on, that is a real gap. A parser regression in FrontmatterParser or MDCParser will not be caught by CI. The other limitation is scope. Copilot and Aider are listed as supported, but only for project-level skills and agents, with no global paths, so a Chops install will show nothing for those two until you are inside a project that defines them. And the app is macOS only, which rules it out entirely for Linux or Windows users. The README does not describe any validation of frontmatter against a schema, so a malformed skill file will be discovered and displayed but not flagged as broken.
How this differs from editing the directories yourself or scripting it
The obvious alternative is a shell script or a symlink farm. A find command across the tool directories, or a small script that copies a canonical skill into each tool's path, gets you discovery and sharing without a GUI. Chops does something a script does not: it resolves symlinks so one file appears once with multiple tool badges, it watches for changes with FSEvents so the view stays current without re-running anything, and it gives you a monospaced editor with Cmd+S save that wraps NSTextView, so editing happens in place rather than in a terminal. The trade is that a script is inspectable in twenty lines and versionable in your dotfiles repo, while Chops is a compiled Swift app with an opaque SwiftData store. The README notes that Collections organize skills and agents without modifying source files, which is the closest thing to a metadata layer here. If your workflow is already git-tracked dotfiles and you are comfortable in a terminal, the script approach has a lower ceiling but no install step and no sandbox exception. If you switch between Claude Code and Cursor and Codex daily and want to see the union of your skills in one list, the script stops being pleasant quickly.
Registry browsing, remote servers, and where the documentation thins out
Two features sit outside the local file model. Remote servers let Chops connect to machines running OpenClaw, Hermes, or other layouts to discover, browse and install skills over the network. Skills Discovery lets you browse, search and install from the skills.sh registry. Both are described in a single bullet each, and the README does not cover authentication, transport, what gets written to disk on install, or how conflicts with an existing local skill of the same name are resolved. Treat those as the least specified parts of the app. The same goes for the licensing situation: the repository metadata reports NOASSERTION, which means GitHub could not map the license file to a known SPDX identifier. If you plan to fork, redistribute, or bundle Chops into a commercial workflow, read the LICENSE file in the repository directly rather than assuming a permissive default. Nothing in the supplied material states the license terms, and this is not a question to settle by inference. On maintenance, the release history shows v1.14.0 in April 2026, v1.15.0 later that month, and v1.16.0 in August 2026, so the project is active but not on a fixed cadence. Because the Xcode project is generated, a contributor upgrading their local checkout after a project.yml change must remember to re-run xcodegen generate or the build will not reflect the new settings.
Editorial conclusion
Adopt Chops if you already keep skills in more than two of the supported tool directories and you edit them by hand often enough that hunting through hidden folders has become a chore. Skip it if you work in one tool only, if you need a Linux or Windows client, or if you expect the app to validate that your frontmatter is correct. Before installing, open Chops/Models/ToolSource.swift and confirm the globalPaths entries match where your skills actually live, because that file is the only place the scan targets are defined.
Community notes