Different work needs different context. Stop handing your agent the same one every time.

Loadout is the adaptive context engine for AI coding agents. The premise is simple: install it, create loadouts for the situations you work in, and your context and workflow are injected dynamically when you launch your agent — load claude.

A loadout is the kit you equip before a job — your conventions, your tooling, your voice. Loadout picks the right one automatically, whether you're in a Rust repo, a Next.js app, or on a bare server with no repo at all.

• Your project's AGENTS.md describes the repo.
• Loadout carries what you bring to it — across every project, machine, and agent.

Works with Claude, Codex, Cursor, opencode, and Copilot — in the CLI and in VS Code. Your context arrives as a local, gitignored file each agent reads — committed project instruction files are never touched.

If you have Node, one command installs the CLI (it asks first) and opens the studio:

npx @ellery/loadout studio

Or install the prebuilt binary directly — no Rust toolchain needed:

curl -LsSf https://github.com/elleryfamilia/loadout/releases/latest/download/loadout-installer.sh | sh

In the studio, equip a starter pack — it detects your stack and recommends one, so you have a working loadout before you've written a word. Reopen it anytime:

load studio

Then launch your agent with your context equipped:

load claude

More install options — source builds, self-updating — under Install.

Loadout detects what you're working in, picks the loadout whose targets match, renders its fragments into a local gitignored file — the overlay — and wires that into your agent.

$ load explain

Project
  base   : ~/code/my-rust-app
  branch : main

Detected targets: [rust]

Loadout selection → rust

Active fragments
  • rust-conventions
  • terse-comms

Write plan
  claude:
    created  .loadout/generated/claude.md
    updated  CLAUDE.local.md

Selection is deterministic and inspectable — no LLM decides it. The agent only ever sees the finished overlay. Then launch:

load claude

Loadout re-renders the overlay, wires it into Claude, and starts claude. The repo gains no committed Loadout content: overlays, bindings, logs, and managed local files are all gitignored.

Three things you author, one rule for putting them together. Full detail in docs/concepts.md.

Fragments — reusable units of guidance or context. Static text, or dynamic output from a built-in provider or shell command.

[[fragments]]
id = "rust-conventions"
guidance = "Build with cargo, lint with clippy; prefer ?/Result over unwrap()."

[[fragments]]
id = "terse-comms"
guidance = "Be terse: lead with the result and what changed; skip preamble."

Loadouts — named kits of fragments, tied to one or more targets. A loadout is the unit of selection: when its targets match, its fragment list is what gets rendered.

[[loadouts]]
name = "rust"
targets = ["rust"]
fragments = ["rust-conventions", "terse-comms"]

Targets — the coarse project or environment types Loadout detects: rust, node, bun, nextjs, go, python, java, ruby, php, swift, dotnet, and machine (used when you're not inside a repo — handy for sysadmin and DevOps work).

Loadout equips exactly one loadout per context. Loadouts don't merge or stack — composition happens inside the chosen one, through its fragment list.

no loadout's targets match  →  a no-targets default applies, else empty
exactly one loadout matches →  use it automatically
multiple loadouts match     →  ask once, then remember the choice for this project

A loadout carries your context. A workflow carries your process — the way you like to work, across every agent. Loadout exposes one fixed set of six slash commands — /loadout:explore, brainstorm, plan, implement, verify, ship — and the workflow your loadout equips decides what each step means. "Plan like spec-kit" and "plan compound-style" are the same /loadout:plan, carrying different instructions.

_{load studio — pick a house process, or build your own; each fills the same six-command spine.}

Three ship — Superpowers (obra/superpowers), spec-driven (Spec Kit / Kiro), and Every's compound engineering — each modeled on a real framework whose actual skill files are vendored verbatim. Or build your own in load studio. A stage can hand a file to the next step (plan writes plan.md, implement reads it), which is what makes a workflow more than headings. Equip one on a loadout — in studio's Workflow slot, or by hand:

[[loadouts]]
name = "machine"      # the default (no-targets) loadout → applies everywhere
workflow = "superpowers"

Workflows are global-only and never enforced — guidance rendered into each agent, not a runtime. (Two naming nuances: Cursor delivers the spine as Skills and VS Code as prompt files, so in both the commands are invoked /loadout-plan — dash, not colon — because each names the command after its file or folder.) Full detail in docs/concepts.md.

load plan turns an agent-written development plan into a reviewable page instead of a wall of chat text. The loop: the agent (with the embedded loadout-plan-preview skill) writes a structured plan.json; load plan check validates it; load plan render renders a self-contained plan.html and opens it in your browser; you leave comments on individual tasks, phases, risks, and open questions right on the page; a Copy feedback button assembles them into a structured document you paste back to the agent, which revises the plan and re-renders.

_{load plan render — an agent's plan, rendered for review with element-anchored comments.}

Rendering is deterministic (the same plan.json and loadout version always produce byte-identical HTML) and self-contained — no CDN, no external fetches, everything inlined into one file. Full detail, including the schema and the feedback contract, in docs/concepts.md.

Loadout produces one overlay and delivers it the way each agent expects.

It never edits committed shared files like AGENTS.md, CLAUDE.md, or .github/copilot-instructions.md — only local, gitignored paths.

load studio opens a localhost-only web UI for your fragment and loadout library. It's a visual editor over your TOML config — not a hidden database. Nothing touches disk until you review and apply the staged diff.

load studio

_{load studio — a loadout is targets + fragments + an optional workflow, composed visually.}

Use it to create and edit fragments, compose loadouts, assign them to targets, browse and build workflows, preview generated overlays, run dynamic fragment previews, and review diffs before applying.

It also carries a starter pack gallery: ready-made loadouts — everyday essentials plus per-stack kits — with the pack matching your detected stack flagged as recommended. Applying one stages the same edits you'd make by hand: fragments are duplicated into your library as your own, so there's nothing auto-active or magic to un-learn later.

Fragments and loadouts are global-only, so sharing them is just syncing your global config.

load sync init                                          # start a config repo
load sync init git@github.com:you/loadout-config.git    # or wire an existing one
load sync clone https://github.com/you/loadout-config.git   # on another machine

After that, launching an agent (load claude) pulls the latest config before rendering. Your private local.toml (hostnames, host classes, machine-specific values) stays local and never syncs.

Sync needs git on the machine — minimal images (Proxmox, slim containers) often don't ship it, so apt install git first.

Don't hand-translate it. Loadout ships an agent skill, loadout-migrate, that reads your existing global agent instructions and turns them into Loadout fragments plus the loadouts you need. Your originals are left untouched.

load skill install

Then, in an agent session, run /loadout-migrate or just ask "Import my CLAUDE.md into Loadout."

Three more ship: loadout-remember saves a durable cross-project preference as a fragment when you mention one mid-session (instead of leaving it stranded in one agent's memory), loadout-import-workflow turns another repo's command/skill suite into a loadout workflow, and loadout-plan-preview drives the plan preview loop above. The skills follow the cross-agent SKILL.md format, so the same install works in Claude Code, Codex, opencode, and Cursor.

You author fragments and loadouts once, globally. A repo never stores them — it only remembers which loadout to use.

~/.config/loadout/config.toml   # your library — public/shareable
~/.config/loadout/local.toml    # private, gitignored: hostnames, host classes, machine values
.loadout/                       # per-repo, gitignored: overlays, binding, logs, cache

A read-only palette of starter fragments also ships inside the binary; duplicate one into your library to own and edit it, or let a starter pack compose them into a ready-made loadout for you. Repos don't store global fragments or loadouts — if one does, load doctor flags it. More in docs/configuration.md.

Run load --help for the full set and global flags (--cwd, --verbose, --dry-run).

Generated overlays are agent guidance, not enforced policy — they're regular files an agent reads. Loadout keeps them clean and local: allowlisted env vars only, secret-name denylisting and token redaction, atomic writes, gitignored artifacts, managed marker blocks, context hashes, and --dry-run previews. Run load doctor to check your setup. Full threat model in docs/security.md.

Prebuilt binary — no Rust toolchain needed (macOS and Linux; on Windows use WSL):

curl -LsSf https://github.com/elleryfamilia/loadout/releases/latest/download/loadout-installer.sh | sh

Via npm — @ellery/loadout is a thin bootstrapper that runs the same installer after showing you what it will do and asking for consent, then hands off to the load CLI. On a machine that already has loadout it checks for a newer release and offers to update (again asking first), then runs your command:

npx @ellery/loadout studio

Installer-based installs update in place with load update. From source:

cargo install --git https://github.com/elleryfamilia/loadout

Verified install channels. These are the only official sources — treat a binary from anywhere else as untrusted:

• GitHub releases — https://github.com/elleryfamilia/loadout/releases: the prebuilt binaries and the installer script above, built by cargo-dist from tagged commits of this repo.
• This repo, from source — the cargo install --git … line above, or a clone and cargo build.
• npm — @ellery/loadout: contains no binaries; with your consent it runs the installer script from the GitHub releases above, then delegates to the installed load.

There is no official Homebrew tap or other third-party package today.

Full docs live in docs/:

• Concepts — the model, selection, providers, freshness
• Configuration — config layers, templates, dynamic fragments
• Security & trust
• Architecture · Extending · Testing

Licensed under the MIT License. Unless you state otherwise, any contribution you submit shall be licensed as above, without additional terms.