name: poteto-help description: Guides users through pstack setup, $poteto-mode, and picking the skill, playbook, or principle for a task. Type $poteto-help with a question. metadata: version: "1.0.1"

Before following this workflow, read the Codex runtime contract. It defines plugin paths, model configuration, delegation, and persistence.

Poteto help

Answer the user's question about pstack, hand them a prompt they can send, and link the file the answer came from. For a help question, don't start the work. The user asked how, and a pstack run spends real tokens, so let them send the prompt.

A message that asks for work, such as "use pstack to fix this bug", is not a help question. Read `poteto-mode`, do the work under it, and retain any user instruction to apply it throughout this task in durable notes.

This file maps questions to the skills and guide pages that hold the answers. Those files own the details. Read the file you route to before you quote it, and trust it when it disagrees with this map. The links here point into the installed plugin, which the user may not be able to open, so give the user the file's public copy: https://github.com/ScriptedAlchemy/pstack-codex/blob/main/plugins/pstack/ followed by its path.

Find out what they need

Infer the need from the message and the conversation. A named situation, such as "which skill reviews a PR?", goes straight to its section. If the need is still unclear, ask one multiple-choice question with these options, then answer only the section they pick:

• Get set up
• Start a task with $poteto-mode
• Pick a skill for a situation
• Fix a run that went wrong
• Make pstack my own

Check the state that changes the answer, and mention it only when it does:

• No ~/.codex/pstack-models.md means $setup-pstack hasn't run for this user, so every role uses its default model.
• No verify-* skill or other app harness in the project means agents have no scripted way to drive the app. Mention $create-verification-skill when the question is about proving a change works.
• No formal verification skill in the project means no property is checked past what tests reach. Mention $create-formal-verification-skill when the question is about a race, an invariant, or another case tests rarely hit. When one exists and the code it covers changed after the commit it records as last in sync, mention $maintain-formal-verification-skill if the question touches that code.

When the model rule is missing and it matters, ask whether the user wants to pick a model for each role and a reasoning budget now. It matters when the user is new, the question is about setup or cost, or the answer depends on which models run. Ask at most once per chat. If the need is also unclear, ask both questions together. Offer two choices:

• Now: give them $setup-pstack to type, and answer their question too.
• Later: answer their question, and add one line saying every role keeps its default model until they run $setup-pstack.

Get set up

1. Install with codex plugin marketplace add ScriptedAlchemy/pstack-codex, then codex plugin add pstack@pstack-codex. Start a new Codex task.
2. Run `$setup-pstack`. It asks for a reasoning budget, maps a model to each role, and writes ~/.codex/pstack-models.md. Delegated roles read that file. It then offers to generate an app verification skill and a formal verification skill when the project lacks them.
3. Start a real task with $poteto-mode, a goal, and a check that can pass or fail.

Installing changes nothing until the user invokes a skill. Only $setup-pstack loads from the user's words. The README and guide page 1 have the details. Offer to word their first prompt with them, per `references/prompting.md`.

If cost is the worry, say where the tokens go and how to spend fewer. pstack spends extra tokens on subagents and review panels. Rerun $setup-pstack and pick a smaller budget or cheaper models. A role set to auto or inherit-parent runs on the chat's model, which saves tokens when the chat runs on Auto or a cheaper model. A shorter panel list runs fewer subagents, one for each entry. Save $poteto-mode for work that needs rigor.

This is the Codex port of pstack. Its runtime contract defines collaboration, worktrees, model overrides, heartbeat automations, and persistence. Installation does not register Cursor Custom Modes or provide Cursor built-ins.

Start a task with $poteto-mode

$poteto-mode matches the task to a playbook, copies the playbook's steps into the todo list, and runs the other skills as the steps need them. A step it skips stays in the list as skip: <reason>. A good prompt states the goal and how to tell it's done. It doesn't list skills, because a hand-written sequence tends to drop or reorder steps the playbook would keep. Read `references/prompting.md` before you help word one. Guide page 2 has examples.

Ask Codex to use $poteto-mode throughout the current task, and preserve that standing instruction in resume notes. For persistence in a repository across tasks, read the optional scoped AGENTS.md method and use it only when requested.

For subagents, follow CODEX.md and pass the absolute persona instruction path. Use a named agent only when the active host exposes that role. Spawning does not isolate a checkout or create a cloud VM.

Pick a skill

The default answer is $poteto-mode, which runs most of the others when its steps need them. Name a skill directly when the user wants more or less of something than the playbook gives. Read the skill before you recommend it, and give one example prompt.

If a skill directory next to this one is missing from the table, read its frontmatter and route by its description. The principle-* directories are covered under principles below.

Close calls:

• $how explains what the code does. $why explains the reasons. $teach runs one or both and explains the result plainly.
• $arena gives every worker the same brief and merges the best parts. $swarm splits work into slices or a race and returns one report.
• $architect implements right after it settles the design. Add "with checkpoint" to review the design before it writes code.
• $interrogate reviews the diff. $blast-radius looks for breakage outside the diff and proves the one fact that makes the change safe.
• $recall rebuilds context across recent chats. $ketchup covers only this chat since the user's last message. Resuming one specific chat or branch is the Session pickup playbook.
• $figure-it-out designs one rigorous run. The Orchestrate playbook runs a program that spans days and many PRs. The Autonomous run playbook drives one task to a finish condition.

Host capabilities:

• A focused diff cleanup pass replaces Cursor deslop. Use the available browser, computer-use, terminal, or project verification skill for live proof.
• Use Codex skill-creator for authoring and the supported automation tool for future wakeups.
• Orchestrate is a poteto-mode playbook, not a separate pstack skill.

Playbooks and principles

Playbooks are step lists inside $poteto-mode, not skills, so they have no slash command. Inside $poteto-mode, describing the task picks one, and these phrases name one directly:

• "babysit this pr" or "check on pr 123" runs Babysit. It drives the PR to merge-ready and stops there. It doesn't merge unless the user asks to merge, land, or ship.
• "land the stack" runs Shipping.
• "take over this branch" runs Session pickup.
• "pause safely" runs Pause safely.
• "full autopilot on this queue" runs Autopilot-full. "stack them, don't ship" runs Autopilot-stack.
• "run the eval playbook" runs Eval.

Name $poteto-mode when you want pstack's Babysit playbook. The Playbooks section of `poteto-mode` lists every playbook and when it applies. Guide page 6 covers opening, babysitting, and landing a PR.

pstack has no separate planning skill. Use the host's available planning flow when appropriate. For work that spans phases or stacked PRs, asking $poteto-mode for a plan runs the Multi-phase plan playbook, which writes the plan and doesn't implement it. For a design question, the Prototype playbook or $architect settles it in code first.

Principles are one-rule skills that $poteto-mode reads and cites in its replies. The user rarely invokes one. They steer with the names instead, as in "apply prove it works. show me the real output." Typing $principle-<name> still loads one on demand. Guide page 8 lists them.

Fix a run that went wrong

For a run that drifts, `references/prompting.md` has one-line steers. Guide page 10 has more pitfalls and the recipes worth copying.

Make pstack my own

• `$automate-me` drafts a personal mode skill from the user's own history, to use alongside $poteto-mode.
• `$automate-maintainer` captures named GitHub users or groups from their engineering activity.
• `$automate-team` discovers a repository's active core contributors and captures team conventions.
• `$reflect` after a session turns its lessons into skill edits the user approves.
• $poteto-mode write a skill for <workflow> runs the authoring playbook. The eval playbook tests a skill change blind.
• Fix a misbehaving skill in its own PR, not inside the feature work where it went wrong.

Guide page 9 covers each of these.

Reply

Lead with the answer. Give at most one example prompt in a code block, adapted from `references/recipes.md` when one fits, then the link to that file. Keep it short unless the user asked for the whole map.