Setup pstack

Read the pstack-t3 runtime before spawning workers, choosing models, scheduling, or isolating work. It maps those steps onto T3's orchestrator tools.

Write ~/.config/pstack-t3/roles.json, the per-role seat table that every pstack-t3 skill reads through the runtime. A project can override roles in .pstack/t3-roles.json.

<runtime> below is the pstack-runtime skill directory next to this one.

Steps

1. Check the host and read the catalog

Check the host's tool list for watch_pull_request. Accept the T3 harness prefixes described in the runtime. A tool listed by name counts as present, including a harness prefix. A deferred watch_pull_request counts as present and does not fail this gate. If tools load lazily, use the host's tool discovery and make one bounded orchestrator_capabilities call before checking again. A provider catalog does not prove that the watch tool exists. Do not call watch_pull_request with a dummy PR to test it.

If watch_pull_request is absent, stop setup before writing roles or a saved catalog. Say "Setup cannot finish. This host does not expose watch_pull_request, and pstack-t3 requires T3 Code 0.1.2 or later." Ask the user to update T3 Code and rerun setup. Do not report setup complete.

The runtime host notes state the T3 Code version floor. See host notes.

When an expected model is missing, enable Provider update checks in T3's Maintenance settings and refresh provider status. This setting also controls model catalog updates. Read orchestrator_capabilities again after the refresh before replacing a seat. Call orchestrator_capabilities. Save its JSON result verbatim to a temporary file, for example /tmp/pstack-t3-catalog.json. That file is the only source of valid providers, models, and options. Never write a seat that is not in it. Keep the file for the commands in this skill. show and write both read it, and a user-level write saves a copy as the snapshot. A skill that only resolves a role from a tool result uses the quoted heredoc in Where roles live instead of a file.