| name | setup-pstack |
| description | Configure which models pstack uses per role. Detects your available models and writes an always-loaded rule file that overrides the skill defaults. Use for /pstack:setup-pstack, "configure pstack models", or changing pstack's model choices. |
Setup pstack
Write ~/.claude/rules/pstack-models.md, an always-loaded rule file that sets pstack's model per role. The skills read it and fall back to their inline defaults when a line is absent, so this is an override layer, not a requirement.
A value is written <model>/<effort>: the model you pass as model on an Agent call, then the reasoning effort you pass as effort. opus/max means model: opus, effort: max. A bare model name with no slash means the role takes that model at its default effort.
Steps
1. Detect available models
Enumerate the models you can pass to an Agent subagent in this session; that is the dependable source. Claude Code's model names are opus, sonnet, and haiku, each pairable with an effort level of low, medium, high, xhigh, or max. If the session or the user's config exposes a narrower entitled set, prefer it. If you cannot detect any, ask the user which models they have access to. Never write a model you have not confirmed is available. The aliases inherit-parent and auto are always valid even though they are not detected models.
2. Load current state
The default role-to-model mapping is the rule shape shown in step 5 below. If ~/.claude/rules/pstack-models.md already exists, read it and treat its values as the current choices. Otherwise start from those defaults.
3. Map and confirm
Show every role with its current model, marking any value not in the detected set 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) as the options. Prefer AskUserQuestion 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. A panel earns its fan-out from distinct model and effort tiers, so keep the entries distinct rather than repeating one value. arena cross-judge pool is also a list, but Arena selects one value from it whose model or effort 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.
4. Validate
Every model written must be in the detected set and every effort suffix must be one of low, medium, high, xhigh, max; inherit-parent and auto always pass. If a chosen model is not available, stop and ask again. A rule pointing at a model the user cannot use breaks every delegation that reads it.
5. Write the rule
Write ~/.claude/rules/pstack-models.md with one line per role, using the same labels poteto-mode uses. Overwrite the whole file so re-runs stay idempotent. Files under ~/.claude/rules/ load into every session, which is what makes this an override layer. Shape:
# pstack model configuration
One line per role, written `<role>: <model>/<effort>`. Delete a line to fall back to the skill default.
`inherit-parent` or `auto` as a value: the role runs on the parent chat model (omit the Agent `model`). Alias entries in a panel list still count toward its fan-out.
feature, refactoring: sonnet/high
bug-fix: opus/max
perf-issue: opus/max
hillclimb: opus/max
judgment and prose: opus/max
hardest tasks: opus/max
how explorer: sonnet/high
how explainer: opus/max
how critics: opus/max, opus/high, sonnet/high, opus/xhigh
why investigators: sonnet/high
why synthesizer: opus/max
reflect tooling: opus/high
reflect judgment, divergent, synthesizer: opus/max
arena runners: opus/max, opus/high, sonnet/high, opus/xhigh
arena cross-judge pool: opus/max, opus/high, sonnet/high, opus/xhigh
swarm workers: sonnet/high
architect runners: opus/max, opus/high, sonnet/high, opus/xhigh
interrogate reviewers: opus/max, opus/high, sonnet/high, opus/xhigh
6. Confirm
Tell the user the rule file was written and that it applies to new sessions. Re-running this skill updates it.
7. Offer a verification skill (optional)
Check whether the project has a way to drive the real app for proof (a verify-* skill, or an existing harness). If not, offer once: "want a project-local verification skill, so agents can drive the app the way a user does and prove changes work? I can generate one with /pstack:create-verification-skill." On yes, invoke /pstack:create-verification-skill (resolves wherever pstack is installed — workspace, user, or plugin). On no, move on without pushing.
