Setup pstack for Codex

Use the standing model-capability-router as the sole authority for model, effort, delegation and total-cost decisions. This skill maps pstack roles onto native Codex capabilities when the operator asks for setup; it does not create a second routing policy, switch the active task model, write a Cursor rule, or start agents merely to configure them.

Steps

1. Establish scope and capability

Identify whether the request is for this task, a particular project, or a persistent shared policy. Read the installed router and, for a persistent source change, the canonical TheAngryPit/TheAngrySkills source. Respect the operator's selected main model, effort, role bindings and workflow. Check the models, efforts and inheritance exposed by each exact channel that would execute a choice; current task, native subagent, user-owned task and Work cloud can differ. Do not present the router's recommended profiles as detected runtime configuration.

2. Choose execution before compute

Keep small or tightly coupled work with the agent that has context. Use bounded delegation or parallel workers only when authorized and useful after briefing, startup, integration and verification costs. Preserve a requested delegation workflow for suitable work. There is no required Astra → Sol → Luna ladder, coordinator stage, automatic planning or review delegate, failed-attempt escalation, fixed fan-out or model race. Create a separate user-owned task only under the router's explicit-request and task-boundary rules. A full-history subagent fork inherits the parent model; request a differently modelled native worker with bounded or fresh context only when that channel supports it.

3. Budget, map and review every pstack role

For a full pstack setup, load existing project/task choices first; on a re-run preserve changed model families, panel lists, role ownership, named specialists and inherit-parent/auto aliases. Show all upstream role labels, even when a workflow is not being invoked now: feature/refactoring, bug-fix, perf-issue, hillclimb, judgment/prose, hardest tasks, how explorer/explainer, why investigators/synthesizer, reflect tooling/judgment/divergent/synthesizer, arena runners/cross-judge pool, swarm workers, architect runners and interrogate reviewers. A scoped change to one role changes only that role and keeps the rest of the established mapping. Showing roles does not dispatch them.

Offer the upstream budget options with their exact labels and show the current selection when known: unlimited — keep max, large — xhigh reasoning, medium — high reasoning, small — medium reasoning. For a proposed mapping, unlimited retains current efforts; the other options propose xhigh, high or medium for every real role and panel entry. Choose a detected same-family variant at or below the proposed target only when it is actually available on that execution channel; otherwise mark the entry as needing a choice. Leave aliases untouched. This is a pstack configuration proposal, not a command to run every worker at the same effort. Review the proposal against the router's task-specific judgment, explicit bindings and proof needs before applying it. Do not invent Cursor slugs or silently substitute an unavailable native model.