Distribute skills and agents to any AI coding assistant — across provider boundaries — and keep them in sync.
sauron is a spec-driven CLI that delivers skills and agents from a single remote registry (git or HTTP) to the assistant you use (Claude, Zencoder, …). It reconciles your provider to a desired set with a reviewable plan, manually or on a schedule you wire into your OS scheduler. Grouping artifacts into shareable personas is a planned concept, deferred past v1 — see ADR-0003.
Registry management (set / unset / describe registry) ships today;
the remaining commands are specified and being built — see the
feature status index.
sauron is a command-line app — nothing runs in the background unless you schedule it.
┌──────────────────────┐ ┌──────────────────────┐
│ Registry │ │ User │
│ artifact source │ │ a developer using │
│ git · http │ │ an AI assistant │
└──────────┬───────────┘ └──────────┬───────────┘
▲ │
│ fetch artifacts │ runs `sauron`
│ (install · sync · upgrade) │ commands
┌─ User env ──┼──────────────────────────────────────────────────┼───────────┐
│ │ │ │
│ ┌────────────┐ ┌──────────────────┐ │ │
│ │ OS crontab ├──▶ │ SAURON CLI │◀───────────────────────┘ │
│ │ (optional) │ │ │ │
│ └────────────┘ └─────┬────────────┘ │
│ │ installs / removes artifacts │
│ ▼ │
│ ┌─────────────┬──────────────┐ │
│ │ Provider │ │
│ │ claude | zencoder │ │
│ │ (artifact directories) │ │
│ └────────────────────────────┘ │
└─────────────────────────────────────────────────────────────────────────────┘
The registry is an external artifact source; the CLI, the optional crontab entry,
and the provider's artifact directories all live in your environment. You
configure the registry, sauron validates it, and then it installs the skills and
agents you ask for and keeps them current — touching only artifacts it installed,
namespaced sauron-<name> under the provider's directories. State lives in two
files under ~/.sauron/ — track.yaml, which records exactly what sauron
installed and where it came from, and settings.yaml, which holds the configured
registry and provider. The track file is the source of truth that keeps
uninstall, sync, and upgrade safe.
The full model — the registry, providers, the sync plan, and state — is in the domain documentation.
This is a spec-driven project: behavior is specified before it is built, and the documentation is organized so each reader can go straight to what they need.
- New here? Start with the domain model, then the lifecycle walkthrough to see how a change flows from requirement to shipped code.
- Developers / engineers — the architecture contract (layout, wiring, Use Case/Action), the CLI contract, and how to author specs. Day-to-day workflow is in CONTRIBUTING.
- Architects — the Constitution (governing principles) and the architecture / state contracts.
- Security analysts — the security overview: secret handling, TLS, write integrity, file permissions, and the HTTP registry API's auth model, with links to the rules that own them.
License — Apache-2.0.
