Set up a project or team¶
Every new laptop and every CI job has to get the same skills into the same agents. Doing that by hand, or with a per-agent setup script, drifts quickly.
With Repertoire the whole setup is one file and one command: commit a
repertoire.yaml that lists the skills the project needs, and each contributor
runs repertoire bootstrap.
- One manifest configures every agent your team uses.
- Public, private, and local catalogs all work the same way.
- Installed copies are tracked by digest, so nobody's local edits are silently overwritten.
If you only want to install a skill for yourself, skip to Install one skill across agents.
Step 1: write repertoire.yaml¶
From the Git repository root, start a project manifest without installing anything:
repertoire init
init writes a starter repertoire.yaml that lists every built-in
phillarmonic skill with source-qualified IDs and scope: global. Edit it
down to what the project needs, then run repertoire bootstrap. If the file
already has a skills section, init refuses unless you pass --force.
A filled-in example after editing:
schema: 1
tool: https://github.com/phillarmonic/repertoire-ai
catalogs:
company:
source: git@github.com:example/company-skills.git
ref: main
skills:
github.com/phillarmonic/ai-skills/zensical:
scope: global
targets: [codex, claude, cursor]
code-reviewer:
catalog: company
scope: global
targets: [codex, claude, cursor, gemini, copilot]
shared-helpers:
catalog: company
scope: project
targets: [agents]
hooks: true
What each part means:
catalogsregisters any catalog beyond the built-inphillarmonicone. The key is the name you will refer to it by;sourceis anythinggit cloneaccepts (or a local path);refoptionally pins a branch, tag, or commit. See Private and company catalogs for how to build one.skillslists what to install. Each key is either a short skill name (code-reviewer) or a source-qualified ID (github.com/phillarmonic/ai-skills/zensical) that names the catalog and the skill together. Use the qualified form when two catalogs could define the same short name.catalognames which catalog a short name comes from. Omit it for skills in the built-in catalog or when only one catalog defines the name.scopeisglobal(default; installs under each contributor's home directory) orproject(installs inside this repository).targetslists the agents to install into by name. Omit it to let Repertoire detect the agents present on each machine. The manifest does not accept theallshorthand; list the targets you want. The full list is in Targets and security.hooks: truealso installs any optional hooks or integrations the skill ships (for example an agent hook configuration file). Without it, only the skill and any always-on project instructions are installed.
The tool line is informational; it tells people who find the file which
program reads it.
Step 2: run repertoire bootstrap¶
repertoire bootstrap
bootstrap reads the skills section and installs each entry into its
declared scope and targets. It:
- installs anything that is missing and repairs managed copies that are broken;
- skips skills that are already intact, so repeated runs are cheap;
- never removes a skill you deleted from the file (run
repertoire removefor that); - never fetches from the network; it uses local catalogs and whatever catalog state is already cached.
Put it in your onboarding docs and in CI. It exits non-zero on the first error, and work completed before that error stays installed.
Running bootstrap in a repository with no skills declared
If repertoire.yaml has no skills section, bootstrap writes a starter
one that lists every skill from the built-in phillarmonic catalog with
source-qualified IDs and scope: global, then installs them. Edit the file
down to what you actually need and commit it.
Step 3: keep it fresh with repertoire sync¶
repertoire sync
sync does the same work as bootstrap but refreshes the tracking catalogs
first, so it picks up skills that were updated upstream. Use bootstrap when
you want a deterministic install from current state (onboarding, CI) and sync
when you want the newest versions (a weekly job, or whenever a catalog
maintainer announces a change). Skills pinned to a tag or commit stay pinned in
both cases.
Install one skill across agents¶
You do not need a manifest to use Repertoire. add installs a skill for the
current user and remembers it so update keeps it current:
repertoire add code-reviewer --catalog company --target all
--target all installs into every supported agent, whether or not that agent
is set up on the machine yet. Repeat --target to choose a subset, or omit it
to install only into agents Repertoire detects:
repertoire add code-reviewer --target codex --target claude
repertoire add code-reviewer
Skills install under your home directory by default. Add --project when a
skill should live inside the current Git repository instead:
repertoire --project add shared-helpers --target agents
Some catalog skills ship optional hooks or integrations. Interactive add
asks before installing them; in CI or scripts pass --with-hooks to accept or
--no-hooks to skip:
repertoire --project add graphify --target codex --with-hooks
Details¶
Applying every skill to every agent after the fact
install and update accept --target all (or repeated --target) to
override the targets stored in the manifest and lock for every skill they
touch:
repertoire install --target all
repertoire update --target all
The expanded target names, not the word all, are what gets saved.
Global-scope skills and files in the repository
A scope: global declaration keeps the skill under the contributor's home
directory. If the catalog declares always-on project instructions for that
skill (for example a short pointer section in AGENTS.md), bootstrap
still writes those into the repository. Their state is stored in the
global lock, so the repository does not gain a repertoire.lock.json just
for a pointer. hooks: true additionally manages the skill's optional
hooks in the repository.
Why bootstrap and sync reject --global and --project
Scope belongs to each declaration in the skills section, so a
command-wide scope flag would be ambiguous. Both commands still honor
--force. Replacing a home-directory skill that is already managed from a
different catalog source or ref requires --force; this stops one project
from silently changing an installation shared across projects.
Migrating from a legacy .repertoire.yaml
Earlier versions read project declarations from a standalone
.repertoire.yaml. When bootstrap or sync finds that file and
repertoire.yaml declares no skills, it merges the legacy catalogs and
skills sections into repertoire.yaml and deletes the old file. If both
files declare skills, repertoire.yaml wins and a warning asks you to
merge and remove the legacy file by hand.
See the command reference, Manifests and state, and Targets and security for more.