Setup pstack

Write the pstack models config, a file that sets pstack's model and reasoning effort per role. The skills read it on demand, layered workspace-first: a role line in .agents/pstack-models.md (workspace) overrides the same role in ~/.agents/pstack-models.md (user), and roles absent from both fall back to each skill's inline default — so this is an override layer, not a requirement.

The inline defaults are written as short model aliases (fable, opus, sonnet, haiku); on Codex they translate to the GPT-5.6 tiers per the pstack-harness skill. Any other value your harness does not accept for subagents means inherit-parent: the role runs on the session model, and multi-model panels become same-model panels with differentiated briefs. An entry may pin a reasoning effort as model@effort, and ## codex, ## claude-code, or ## hermes sections hold lines that apply to one harness only. The grammar, precedence, and effort policy are defined once, in the pstack-harness skill.

Steps

1. Detect available models and efforts

Enumerate the model values your session's spawn mechanism accepts, and the reasoning-effort values it accepts per spawn (none where it has no such field, which is the Claude Code case) (find the mechanism per the pstack-harness skill); that is the dependable source. If your CLI also exposes a models API or command that lists the user's entitled models, prefer it for completeness. If you cannot detect any, ask the user to paste the slugs they have access to. Never write a real slug you have not confirmed is available. The aliases inherit-parent and auto are always valid even though they are not detected slugs.

2. Load current state

The default mapping is examples/pstack-models.md next to this skill. Read both config layers when they exist — workspace .agents/pstack-models.md, then ~/.agents/pstack-models.md — including their harness sections, and treat the merged values (workspace winning per role, a harness section winning over flat lines within a file) as the current choices. Otherwise start from those defaults. Unless the user asked for a per-repo override, the user-level file is the one being configured.

3. Map and confirm

The file is shared across CLIs, so a value this harness cannot validate is not wrong — it is another harness's choice (it reads as inherit-parent here). Show every role with its current model and effort for this harness, marking values outside the detected set as "(set for another harness — kept unless you change it)" rather than as needing a choice. Ask whether to accept as-is or change specific roles, offering the detected models plus inherit-parent and auto (both mean: this role runs on the parent chat model, which is how Auto users stay on Auto) as the options. Prefer AskQuestion over free text. For panel roles (how critics, arena runners, architect runners, interrogate reviewers) the value is a list, and one subagent runs per entry, alias entries included, so the list length sets the count. arena cross-judge pool is also a list, but Arena selects one value from it whose model family or capability tier differs from the parent's when possible. swarm workers is the default model for every worker unless a race or comparison assigns another model per arm. trail reviewer is the show-me-your-work reviewer; the skill steps it down one tier whenever it resolves to the model doing the work, so a value that matches the model of another role is fine. default is the entry for any spawn whose skill names no role; keep it inherit-parent unless the user wants unmapped spawns on a specific model.