Quartermaster vs. alternatives

Quartermaster is a free, open-source, local-first registry, converter, and lifecycle manager for AI-agent context — the skills, agents, rules, memories, slash commands, MCP server configs, hooks, and settings scattered across 11 AI coding tools. This page compares it to the tools people usually reach for instead: rulesync and Ruler (cross-tool config-sync CLIs), MCP registries (Smithery and the official MCP Registry), and manual syncing with dotfile managers like chezmoi. Each solves a real slice of the problem; none combines machine-wide discovery, cross-tool conversion, and a governed lifecycle (risk scanning, provenance, drift, reversible installs) the way Quartermaster does — and each is the better choice for some situations, listed honestly below.

Last reviewed: July 2026. Competitor facts age; versions, star counts, and feature flags below were checked against each project’s repo or docs in July 2026.

Capability comparison

Capability	Quartermaster	rulesync	Ruler	MCP registries (Smithery, official)	Manual dotfile sync (chezmoi, git)
Discovery / inventory	Machine-wide background crawl; census; duplicates collapsed across tools	Per-project, explicit rulesync import	None — you author into .ruler/ by hand	None — catalogs of public servers, not your machines	None — manages only files you explicitly add
Cross-tool conversion	Yes — tool ↔ tool, with explicit lossiness and blocker reporting	Yes — via its own unified format (author in .rulesync/, generate per-tool files)	Rules concatenation into each agent’s rules file; MCP config propagation	No	No — copies bytes, format-blind
Install / rollback	Dry-run plans, approval-gated apply, one-shot rollback	Writes generated files directly	One-way overwrite; no revert for subagents	Out of scope (metadata/marketplace; install happens in your tool)	cp / chezmoi apply; no artifact-level undo
Improvement	Yes — skill-improvement pipelines (SkillOpt, SkillOpt-Sleep, darwin-skill): dry-run plans with prereq checks, audited apply, rollback	No	No	No	No
Risk scanning	Deterministic risk scan; imports untrusted by default; policy gates block high-risk applies	No	No	Official registry explicitly delegates security scanning downstream; Smithery is platform-level	No
Provenance / drift	Auto-links git origins; baseline vs. upstream drift; version pinning; update previews	No	No	Official registry verifies publisher namespaces (DNS/GitHub) — nothing tracks installed copies	Git history of managed files; no upstream drift awareness
Offline / local-first	Fully offline — embeddings baked in, no API keys, no telemetry	Local CLI	Local CLI	Cloud services	Local + git remote
Artifact coverage	8 types (skills, agents, rules, memories, commands, MCP configs, hooks, settings) × 11 tools	8 artifact kinds across 40+ agents	Rules + MCP configs; skills and subagents are experimental	MCP servers (official registry: metadata only)	Any file, but format-blind

rulesync

rulesync is the closest project in spirit: it covers a nearly identical eight-kind artifact taxonomy (rules, commands, MCP configs, subagents, skills, ignore files, hooks, permissions) across the broadest tool matrix in this category — 40+ agents versus Quartermaster’s 11. It is MIT-licensed, very actively maintained (v9.x, 260 releases, ~1.2k stars as of July 2026), and its mental model is simple: author unified config in .rulesync/, run rulesync generate, and it writes each tool’s native files. rulesync import pulls existing per-tool configs into that format — per project and explicit, not a machine-wide crawl.

The philosophical difference: rulesync is authoring-time — it assumes you adopt its format as the source of truth and generate outward. Quartermaster is runtime — it starts from whatever already exists on your disk, indexes it, and layers search, conversion, and governance on top. rulesync has no inventory, no search, no risk scanning, no provenance or drift tracking, and no MCP server surface an agent can query mid-session; once someone edits a generated file directly, the source of truth forks silently.

Choose rulesync when: you’re starting fresh, you’re happy to author all agent config in one unified format per repo, you need one of the 30-odd tools Quartermaster doesn’t cover, or you want a tiny zero-daemon CLI that regenerates configs in CI. The two also coexist fine — Quartermaster’s crawl indexes both the .rulesync/ sources and the generated outputs.

Ruler

Ruler (“apply the same rules to all coding agents”) has the largest community of the sync CLIs (~2.8k stars) and the narrowest, most reliable job: concatenate the markdown in .ruler/ into each agent’s native rules file, across 30+ agents, and propagate MCP server settings from ruler.toml. It is MIT-licensed and free, with clean docs and very low adoption friction.

It is rules-centric by design: skills and subagents distribution exist but are explicitly experimental, and there is no coverage of memories, hooks, settings/permissions, or commands. Like rulesync, it has no discovery, no search, no governance layer, and no rollback — the apply model is a one-way overwrite, so local edits to generated files are clobbered or fork silently.

Choose Ruler when: the job is exactly “same rules and MCP configs everywhere, in every repo, for a team” and you want the most battle-tested CLI for that one job. Everything in the rulesync trade-off above applies here too.

MCP registries: Smithery and the official MCP Registry

These are a different category, and mostly complementary. Smithery (smithery.ai) is a commercial marketplace and hosting platform for MCP servers — 3,300+ listed as of July 2026 — whose standout feature is managed credentials (hosted servers with OAuth handling and token refresh), something a local-first tool deliberately doesn’t do. The official MCP Registry (registry.modelcontextprotocol.io, backed by Anthropic, GitHub, PulseMCP, and Microsoft) is a standards-track metadata catalog in preview: publishers register verified server.json metadata, and downstream aggregators consume its API. It explicitly does not support private servers and explicitly delegates curation and security scanning to others.

Registries answer “what MCP servers exist in the world?” Quartermaster answers “what do I already have configured across my tools and machines — and is it safe, current, and where I need it?” A registry doesn’t know which of your tools ended up with a server configured, that three tools carry near-duplicate configs of the same server, or whether an installed copy drifted from its upstream. MCP servers are also just one of Quartermaster’s eight artifact types — registries have nothing for skills, rules, agents, memories, commands, hooks, or settings. The natural pipeline is discover on a registry → install into a tool → inventory, convert, and track with Quartermaster (whose public-catalog layer already includes an MCP-registry resolver).

Choose a registry when: you’re looking for new public MCP servers — the official registry for authoritative metadata, Smithery when you also want hosted servers with managed auth.

Manual syncing: dotfiles, chezmoi, copy-paste

The real incumbent. Dotfile managers like chezmoi are mature, battle-tested, free, and require zero new concepts; plenty of developers version ~/.claude, CLAUDE.md, and friends in a dotfiles repo today, and current community guides cover exactly that. For one developer with one tool, two machines, and a small config surface, this is honestly often good enough — and it handles your non-agent dotfiles too, which Quartermaster doesn’t touch.

The failure mode isn’t syncing — it’s knowing what to sync. A dotfile manager manages only what you explicitly enumerated, as opaque bytes, in the exact format one tool reads. It can’t discover the skill a plugin dropped into a cache directory, convert a Claude skill for Codex, notice that .cursorrules duplicates half your CLAUDE.md, search anything, or scan an imported artifact for risk. And agent config files routinely sit next to credentials (MCP server env vars in ~/.claude.json); adding those trees to a dotfiles repo verbatim is how tokens end up on GitHub. Quartermaster reads those configs surgically — key names kept, secret values dropped, credential stores hard-skipped — so its index is safe by construction.

Choose manual syncing when: you run one tool on a couple of machines and want one system for all your dotfiles. And keep it either way: Quartermaster indexes a dotfiles repo, auto-links its git origin as provenance, and flags when a deployed copy drifts from it.

Where Quartermaster stands alone

Each alternative owns a slice: rulesync and Ruler own authoring-time generation, registries own discovery of public supply, dotfile managers own byte-level sync. Quartermaster is the only tool in this comparison that combines machine-wide discovery of what already exists, cross-tool conversion with explicit lossiness, and a governed lifecycle — risk scanning, untrusted-by-default imports, provenance links, drift detection, and approval-gated, reversible installs — behind an MCP server any agent can query mid-session. No competitor in this comparison does risk scanning, trust states, or drift tracking on installed artifacts at all — and none can improve an artifact in place: Quartermaster’s skill-improvement pipelines (SkillOpt, SkillOpt-Sleep, darwin-skill) plan, apply with an audit trail, and roll back, through the same approval gates as installs.

It’s early software (v0.2.0 — the sync CLIs above are more battle-tested as projects), and everything that writes to your filesystem is dry-run by default. Free, open source, fully offline: GitHub · Quickstart.