Bridle solves the six-directory problem, and copies profiles rather than linking them

The same skill lives in six different places

The table in the README is the entire reason this project exists, and it is worth reading column by column.

A skill written for one coding assistant lives in a hidden directory under that assistant's configuration root. The next assistant expects the same skill in a config subdirectory, named in the singular. A third uses the plural. For agents, one harness nests them inside a plugin directory with a wildcard, another uses a singular config directory, a third has no agent concept at all, and a fourth has one only for skills and MCP servers. Commands are narrower still: two harnesses support them, three do not.

MCP server configuration is the worst of it. Five harnesses, five file names and formats: a dotfile with a leading dot and a JSON extension in one, a plain JSONC file in the next, a YAML file in the third, a hyphenated JSON file in the fourth, and a bare name with a JSON extension in the last.

Four serialization crates in the project's own manifest are the direct consequence. Bridle has to read and write JSON, JSONC, YAML, and TOML, because that is what its targets use, and a translation layer cannot be cleverer than the formats it must emit.

So the tool is a compatibility shim with a user interface, and the interface is the friendly part.

Profiles are copies, which has consequences

A profile is a saved configuration, and a harness can have several, with names like work, personal, and minimal. The activation model is a copy: when you switch, the active profile's configuration is copied into the harness's own configuration directory.

Copy rather than link is the right choice for a tool that writes files other tools own. A symbolic link into Bridle's storage would be one file, and any harness that rewrites its config in place would write through the link and quietly corrupt the profile.

The cost is that the harness directory becomes a derived artifact. Anything a harness writes into its own configuration after you switch is not in any profile, and the next switch overwrites it. The command set is built around that: create a profile from the current configuration, which captures whatever is there right now, and a diff command that compares two profiles.

The diff command is the one to reach for before trusting a switch. The sensible workflow is to create a profile from the current state, make a change, then diff to see exactly what the change did, rather than switching back and forth and guessing.

Installing from a repository, translated on the way in

The feature it markets itself on is installing components from any GitHub repository, and it describes itself as a package manager for your harness.

The flow has four steps and you drive three of them. Bridle scans the repository for the four component kinds it recognises, which are skills, agents, commands, and MCP servers. You select which of them to take. You choose the target harnesses and profiles. Bridle then translates paths and configuration for each harness automatically.

# Install from GitHub
bridle install owner/repo

The word automatically is doing the work in that last step. Installing the same skill into three harnesses is one command and three directory layouts, and the alternative is three copies of the file plus three config edits.

Two details of the interface are worth noting. An install can be forced to overwrite what is already there, which is what you want when a repository updates its skill and you want the new version rather than the old. And uninstalling is per harness and per profile, interactive, and explicitly labelled experimental in the command table, which is an honest flag on the one operation that deletes things.

The dependency list suggests the implementation does not clone. An HTTP client and a zip archive library together mean a repository is fetched as an archive and unpacked, which is faster and leaves no git metadata in your configuration directory.

Output formats are treated as a feature

Every command accepts an output format flag, which is a small decision with a large effect on whether a tool can be used in a script.

Three values are offered. Plain text is the default and is meant for a person. Machine-readable output is the second. The third, automatic, picks text when the output is going to a terminal and switches to machine-readable when it is being piped.

That third mode is the one that matters, because it means a single command can be run by hand and by a shell pipeline without a flag. Most tools pick one and make you choose; this one detects. For a tool whose whole purpose is being the layer between several assistants and your shell, that is the right default.

Configuration is handled the same way, with get and set subcommands over four named keys rather than an open config file interface: a marker-file switch for debugging, the editor command used by the edit subcommand, the harness tab opened on launch, and the view name for the terminal interface.

The config file itself is small enough to read, and one of its keys exists purely to write marker files, which is the kind of thing that tells you the author debugs this by looking at the filesystem.

One harness is experimental, and says so in its own table

The supported-harness table carries a status column, and the statuses are not uniform.

Four harnesses are marked full support. One is marked experimental, with a parenthetical hedge attached that reads more like a note to self than a status. One is marked full support with a scope attached, meaning skills and MCP servers specifically.

The hedge is the most informative cell in the table. It tells you the author knows that harness is thinner than the others and has chosen to say so rather than round up. For anyone deciding whether to trust a config manager, an honest status column is worth more than a uniform one.

The scoped support is equally useful. If a harness has no concept of agents, a tool claiming to install agents into it is either wrong or lying, and the table's second path table already shows the em-dash in the right cells. The two tables agree, which is a small sign of care.

There is a third drift worth knowing. The repository's one-line description names a seventh assistant that the supported list in the README does not include. Descriptions are edited less often than documentation, so treat the supported table as the current answer.

A 2024-edition workspace with two locator crates

The Rust manifest is organised as a workspace whose members are every crate in the directory, which is the shape to expect for a project with an internal library layer rather than a single binary.

Two of those crates are internal and named for what they do: one locates harnesses on the machine, the other locates skills. Splitting discovery out is the right call for this problem, because everything else in the tool needs the answer to where a harness keeps its files.

The dependency list reads like a description of the feature set. A derive-based argument parser and an interactive multiselect library for the terminal and the selection prompts. Four serialization crates, as already noted. A date-time library with serialisation, a text wrapping library, a home-directory resolver, a program locator, a URL type, a regular expression engine, an HTTP client, and a zip library. For the interface itself, a terminal user interface toolkit, a terminal control library, and a colour library.

Two choices stand out. The project targets the 2024 edition of the language, so it requires a recent toolchain to build. And its distribution profile sets thin link-time optimisation, which is a modest size and speed win and suggests the author cares about the installed binary rather than only about build times.

Development dependencies include a command assertion library and a predicate library, which together are the standard way to test a command line tool's output and exit status.

Three names for one binary, and issues in the tree

The install matrix has more moving parts than it needs to, and reading it is the fastest way to understand the project's shape.

There is a try-it-immediately path with no install at all, offered through three JavaScript package runners under one name. There is a global install through those same runners. Then Homebrew through a tap formula named after the repository, a Cargo install under a second name, and a from-source path that clones and installs from the current directory.

So the package on the JavaScript side and the Cargo package carry different names, while every command in the quick start and the reference tables is invoked under a third name. Nothing is wrong with that, and it is common for a project to have a distinct npm package name, but it means a search for the tool has two valid answers and the documentation uses both.

The repository layout has one more curiosity: a directory at the top level whose name is a project management tool, checked into the tree. That is an issue database stored as files, so the backlog lives in the repository rather than only on a forge, and it travels with a clone.

Releases were weekly for a stretch in January 2026, three patch versions in two weeks, and then stopped. The last push is dated 2026-08-15, so the tree has moved since the newest tag, which is 0.2.9. The licence is MIT, and the acknowledgements thank four people by first name, including two who contributed specific harness integrations.

Editorial conclusion

Bridle suits someone who runs more than one coding assistant and keeps re-pasting the same skill into each, since the translation table it ships is the part you would otherwise maintain by hand. It does not suit someone who wants their harness configurations to be the single source of truth, because profiles are copies and a harness's own writes only survive if you capture them into a profile. Before adopting it, diff your existing harness configs into a profile first, and check whether the harness you use is the one marked experimental.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. neiii/bridle on GitHub
4. README
5. Releases