# Set up pstack In this page you install the package, pick which models pstack uses, and run your first task. Setup is one command plus a short conversation. ## Install the package Clone the repository and install pi-pstack from the checkout, as the [package README](../../README.md#get-set-up) describes: ```sh git clone https://github.com/just-joshn/pi-customizations.git cd pi-customizations bun install pi install ./extensions/pi-pstack ``` `pi install ` loads the package in place, so keep the checkout where it is. To install the published package instead, run `pi install npm:@justjoshn/pi-pstack`. On Linux, the read-only shell also needs `bubblewrap`, `socat`, and `ripgrep`, as the package README explains. Start Pi, and the pstack commands appear in the `/` menu. ## Pick your models Run: ```text /setup-pstack ``` [`/setup-pstack`](../../skills/setup-pstack/SKILL.md) detects the models you have access to, asks for a reasoning budget, shows you each role (code delegates, judgment, the review panels), and asks what you want. Answer the questions. It writes `~/.pi/agent/pstack/pstack-models.md` (`$PI_CODING_AGENT_DIR/pstack/pstack-models.md` when that variable is set), the model rule. pi-pstack adds it to every request, so every pstack skill reads it. The defaults run at `xhigh` reasoning, the same as the `large` budget. `unlimited` lifts each model to its highest tier, up to `max`. Opus goes to `max`. Grok tops out at `xhigh`, so it stays there. `medium` and `small` lower the reasoning and spend fewer tokens. You only override what you care about. A role with no line in the rule keeps the skill's default. To restore a default, delete that role's line. A rerun of `/setup-pstack` keeps any role whose model differs from the default. When a default changes, a rule written before the change still pins the old default, so delete those role lines, or delete the file, then run `/setup-pstack` again. You might be wondering how to run a role on whatever model your chat uses. Set a role to `inherit-parent` or `auto` and pstack omits the subagent `model` field, so the subagent inherits your parent chat model. Both values mean the same thing, and neither is a model. For a panel role the value is a list, and one subagent runs per entry, so the list length sets the panel size. Setup also configures `swarm workers`, the default model for every `/swarm` worker unless a race names a model for each arm. ## Accept the verification offers, or don't At the end of setup, `/setup-pstack` looks for a way to prove app behavior in your project, either a `verify-*` skill or an existing harness. If it finds neither, it offers once to generate one with [`/create-verification-skill`](../../skills/create-verification-skill/SKILL.md). Say yes and it writes `.pi/skills/verify-/`, a project-local skill that teaches agents to drive your app the way a user does. It proves the skill works once before handing it over. Say no and setup moves on. You can run `/create-verification-skill` yourself any time. [Verify and ship](./06-verify-and-ship.md#create-a-project-verification-skill) covers it in depth. If you're new to pstack, say yes. An agent that can check its own work keeps going until the check passes. An agent that can't hands every result back to you to check by hand. Of everything in this guide, the verification skill pays off the most. Then setup offers once to generate a formal verification skill with [`/create-formal-verification-skill`](../../skills/create-formal-verification-skill/SKILL.md), unless the project already has one. Tests check the cases someone thought to write. A formal verification skill checks one key property of your code, such as "a job never runs twice at once", in every case within a stated scope. Say yes when your code has concurrency, retries, a state machine, or a parser, where a bug is costly and tests rarely reach the case that breaks. Otherwise say no, and run it later if that changes. [Verify and ship](./06-verify-and-ship.md#prove-a-property-with-a-formal-verification-skill) covers it. After setup, keep going in the same chat. pi-pstack reads the model rule on every request, so it applies from your next message. ## Keep the cost in check pstack spends extra tokens on subagents and review panels. That's the price of the rigor. To spend fewer: - Rerun `/setup-pstack` and pick a smaller reasoning budget or cheaper models. A strong model in the main chat with cheaper, faster models in the code roles is a good split. - Set a role to `auto` or `inherit-parent` so it runs on the chat's own model. - Shorten a panel list. Each entry runs one subagent. - Save `/poteto-mode` for work that needs rigor. A small, obvious edit doesn't. ## Run your first task Pick something real but small, and describe it the way you'd describe it to a colleague: ```text /poteto-mode add a --json flag to this command. text output stays byte-identical. verify both. ``` Watch the todo list. Its first items are the matched playbook's steps copied in, the Feature playbook for this prompt. If `/poteto-mode` skips a step, the step stays in the list with `skip: `, so you can see what it chose not to do. From here you can type normal follow-ups. To keep `/poteto-mode` on for the whole chat, run `/mode poteto-mode` instead. That makes it a mode, which stays in context on every turn until you exit it with `/mode off`. The footer shows a `mode: poteto-mode` badge while it's on. The [package README](../../README.md#use-it) covers `/mode`. Plain `/poteto-mode` attaches the skill to one message, and it fades as the chat moves on. Next: [Route work through `/poteto-mode`](./02-poteto-mode.md).