loadout

Features

• A full inventory — personal and project skills, everything from plugins, slash commands, subagents and MCP servers, across every assistant on the machine
• Real usage — how many times each thing fired, when it last did, and in how many projects, read from the assistants' own session logs
• Honest counts — a history format that cannot prove an activation is marked unsupported, rather than reporting a zero that looks like disuse
• Project scope — answers "what does an assistant see if I open this folder?" — and an Everything list that puts yours and every project's side by side, each row saying where it lives, for when the question is "where did I put that one?"
• A switch on everything — turn one skill, command, subagent or MCP server off without deleting it, including a single skill out of a 38-item plugin, and Loadout re-applies that choice when the plugin updates
• Codex plugins — installed plugins and their skills appear alongside Claude's, with separate controls. Turning off a plugin shows all its skills as off; turning it back on restores your individual choices. Codex's local plugin controls require an installed Codex version that supports its plugin inventory protocol. Workspace-managed plugin switches stay in Codex.
• An editor — create skills, commands and subagents, edit and delete them, with syntax highlighting and live validation against the documented limits
• A conversation, beside the editor — ask claude, codex or opencode to change a skill; it proposes, you accept change by change
• Out of a repository, into your own — a skill, command or subagent that lives in a project becomes yours everywhere with one click. It is a copy: the project keeps its own, so nobody else loses anything at their next pull
• Help where the question is — Settings › Help says in plain words what switching something off does to your files, where Loadout keeps its own, and reports a bug with the version and system already filled in
• A backup before every write — if the copy fails, nothing is written. Deleting goes to the Trash, never rm
• One skill, every assistant — share a skill across assistants as symlinks to a single copy, so one edit reaches all of them. Switching it off asks which assistants it should return to, and a skill never changes hands behind your back

Install

brew install --cask migsilva89/loadout/loadout

Or download the latest release — the website points at the same file — and drag Loadout.app into /Applications. The disk image is signed and notarised, so it opens without a Gatekeeper warning and without a trip through System Settings.

macOS 15 or later, on Apple silicon or Intel.

Or build it yourself, which needs Xcode:

git clone https://github.com/migsilva89/loadout.git
cd loadout
./Scripts/build-app.sh
open dist/Loadout.app

Chat about your setup

Open Chat beside New skill from any tab. It uses an assistant CLI already installed and its existing subscription — there is no API key. Choose the assistant and model in the chat panel.

Press Ask on a skill to attach it to the current conversation. You can attach several skills and remove them above the message box. Selecting another row does not change the attachments or switch conversations. Removing an attachment excludes its files from future messages; earlier messages stay in the conversation. New starts a chat with no attachments, and History includes earlier conversations, including those started before global chat.

The assistant runs in disposable copies of the attached folders. Review each proposed change in the chat panel with Accept or Reject, then choose Save accepted changes. Only accepted changes reach their original files, with a backup first. If a file changed elsewhere, review the updated proposal before saving. Plugin files remain read-only references.

In the New skill sheet, Create and ask makes the skeleton and hands it to an assistant with what you typed as the brief, so the description and body come back as proposals.

Sharing a skill across assistants

Each assistant reads its skills from ~/.<name>/skills — ~/.claude/skills, ~/.codex/skills, and so on. Loadout finds them by itself: any such folder that exists is included, and an assistant installed tomorrow shows up without a code change.

Clicking an assistant that does not have the skill puts it there. On disk, the folder is promoted to ~/.agents/skills/<name> and each assistant gets a symlink to it — one copy, one edit, both sides always the same. Clicking a lit mark removes only that link, never the one real copy. The Loadout menu has Sync all with … to close the gaps at once.

If two assistants have their own, possibly different, copies of the same skill, the app refuses to merge them on its own and says why.

What it touches

Loadout keeps its own files out of ~/.claude: that directory belongs to Claude, and an app that keeps its database in someone else's folder is a surprise waiting for whoever wipes .claude to fix something.

The app itself makes no network calls. The assistant CLI it runs on your behalf talks to its own provider, with the credentials already on your machine; Loadout never sees them.

The test suite never touches any of this: every test runs against a temporary tree, which is why Paths takes its root by injection.

Codex plugin discovery and configuration edits use its local app-server protocol. Loadout does not start an AI conversation for these operations. To check this integration with an installed Codex, run .build/debug/LoadoutApp --self-check-codex after building. It creates a temporary marketplace and tests individual switches, parent restoration, updates, backups and configuration preservation.

Security

See SECURITY.md. The areas that matter here: writes outside the expected directories, command execution driven by file contents, and any path where a backup fails without stopping the write.

Contributing

See CONTRIBUTING.md for the scope, how to run the tests, and what a pull request needs. A feature outside that scope will be declined however well it is written, so open an issue first. The specification, with the acceptance criteria one by one, is in docs/SPEC.md.

Status

A personal project, maintained when it suits. It works and is used every day, but it does not come with a product's promise of support.

Releases are built by ./Scripts/release.sh, which refuses to run from a dirty tree, an untagged commit or a branch other than main, and runs the tests before signing anything.

Loadout updates itself. A release publishes three files together — the disk image, an identical copy named Loadout-<version>-update.dmg, and a signed appcast.xml that points installed copies at it. The app only accepts an update signed with the key it was built with. release.sh will not print the publish command unless that signed feed exists.

License

MIT.