Config: the dev-lead leg roster

The roster says which model and effort each CLI adapter runs, per role (implement / review) and per round (r1, fix). It is a declaration the lead reads. scripts/leg-cmd.sh still requires an explicit --model — there is no safe default, because the model is the cross-family accounting decision. Nothing in the roster is a launcher default.

Where it lives

The first source that is SET wins — an explicit path that does not exist is reported, never swapped for another file:

1. DEV_LEAD_ROSTER
2. $CLAUDE_PLUGIN_DATA/roster.json — Claude Code's per-plugin directory, used only when it is dev-lead's own (dev-lead-<marketplace>): a lead's shell can inherit ANOTHER plugin's value (measured: codex's). A codex or agy lead will not have the variable at all.
3. ~/.claude/plugins/data/dev-lead-dev-lead/roster.json

A missing file is normal on a new machine: roster.py init (run as in the Procedure below) copies templates/roster.example.json there, never over an existing file or symlink without --force. Its model ids are examples; take each slot through steps 2-3 below before relying on it. Keys that start with _ are comments and are kept across writes.

Procedure

Resolve the suite root the same way the other skills do. The helper has to come from that tree: cwd is the target repo, and a bare scripts path would miss.

DEV_LEAD=${DEV_LEAD_ROOT:-$(ls -d "$HOME"/.claude/plugins/cache/dev-lead/dev-lead/* 2>/dev/null | sort -V | tail -1)}
[ -x "$DEV_LEAD/scripts/roster.py" ] || { echo "dev-lead root unresolved — set DEV_LEAD_ROOT to your checkout"; exit 1; }
"$DEV_LEAD/scripts/roster.py" show

1. Show. Run "$DEV_LEAD/scripts/roster.py" show. A fix round that inherits prints each of r1's legs marked inherited. If the file is missing, the command names the path and how to start one with init (or write one leg with set); that is not an error.

2. Write one leg per call. If the user named assignments, apply each with set and a --why that quotes the user. Do not invent a reason they did not give.

   "$DEV_LEAD/scripts/roster.py" set <round> <role> <adapter> --model M [--effort E] [--family F] [--lens L] --why "<the user's words>"

   An opencode review leg routed by lens is the by_lens entry: pass --lens. set fix --inherit r1 --why "<the user's words>" makes the fix round match r1.

   If the user did not name assignments, ask per slot. Use the host's multiple-choice question tool when it has one. Offer the current value, that adapter's effort.examples spellings from data/launch.json, and free text -- except where the effort block says closed: true (claude, both roles, since 0.6.56): there the examples are the whole vocabulary and set refuses any other word, because that CLI ignores an unknown effort and runs at its default. Ask whether the fix round inherits r1 or differs.

   No config file to align (since 0.6.28). codex review runs codex exec -c model_reasoning_effort=<e>, so the roster's effort is the effort that runs; no shipped leg reads its effort from a file on the machine. roster.py config-effort still exists for a config_only adapter should one return, and answers "nothing to write" for codex. Do not offer to edit ~/.codex/config.toml: it only decides the companion fallback's depth, and changing it is the user's own act.

3. Probe a new model once, with a real call. A model that has never been dispatched on this machine gets one cheap real call before it is written. A row in a CLI's model listing is not evidence the model can be called.
4. The merge gate. roster.py show prints it first. If the user named it, apply "$DEV_LEAD/scripts/roster.py" gate <user|lead> --why "<the user's words>". Otherwise ask once, in their words: does dev-lead land a fully green verdict itself (lead), or does the person approve the verdict and diff first (user, the default)? Say what it does NOT change: anything not fully green — an unanswered review round, a failing test, an open blocker, an unverified finding — still goes to the person either way, and a stricter repo contract still wins.
5. Check. "$DEV_LEAD/scripts/roster.py" check. A family that cannot be the accounting leg is a warning: it prints and does not fail. Any error does. set refuses to write a roster that fails, so a failure here means the file was changed outside this skill. A model id that names another family than the leg declares (is Gemini by its id, not North), or a vendor listed in families.json unregistered, is an error: the markers are each family's models in data/families.json, and a marker inside another family's longer marker yields to it (composer-2.5-fast is Kimi, not Composer). An id that names no family passes with a warning that its family is the roster's word (none when the declared family cannot be the accounting leg anyway).
6. Report. For each slot this session changed, say old → new: model, effort, family, whether the fix round inherits, or the merge gate.

unset <round> <role> <adapter> stores null for that leg. An unset leg is not a default model. The next dispatch has to name one.