Helps users set up pstack, understand model settings, and choose skills or task procedures. It answers questions with a usable example prompt and a source link, leaving the user to start the actual work.
Guides users through pstack setup, /poteto-mode, and picking the skill, playbook, or principle for a task. Type /poteto-help with a question.
Run score Not tested
See how to installReview the instructions the agent will receive before you install.
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 and do the work under it.
This file maps questions to the installed skills, playbooks, and platform mappings that own the answers. Read the matching source before answering. Its instructions take precedence over this map and any upstream guide, which describes Cursor and may differ from this port. The local links point into the installed plugin, so give the user the file's public copy: https://github.com/michael-denyer/pstack-claude/blob/main/plugins/pstack/ followed by its path relative to the plugin root.
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:
/poteto-modeCheck the state that changes the answer, and mention it only when it does:
setup-pstack for the sheet's location and how that runtime loads it. Check that configuration before saying whether defaults or overrides apply.verify or verify-* skill or other app harness means agents have no scripted way to drive the app. Mention /create-verification-skill when the question is about proving a change works./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 sheet is missing and it matters, ask whether the user wants to pick a model for each role and a default effort 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:
/setup-pstack to type, and answer their question too./setup-pstack./setup-pstack, including its Other runtimes table, before explaining model choices, effort, sheet loading, or automatic routing. For a bundled routing hook or extension, use its persistent session hook: off setting in the current runtime's sheet to turn routing off. After the model sheet, it offers once each to generate a verification skill and a formal verification skill for the project, unless the project already has one.references/prompting.md. Use the current runtime's invocation syntax from the slash-command reference.Before giving runtime-specific instructions or adapting a recipe, read the Codex mapping or Pi mapping when applicable. Their routing sections cover hook trust, extension loading, and skills-only installs. For other runtimes, use the runtime support reference.
If cost is the worry, say where the tokens go and how to spend less. pstack spends extra tokens on subagents and review panels. Rerun /setup-pstack and pick a lower effort or cheaper models. A role set to auto or inherit-parent runs on the chat's model, which costs less when the chat runs on a cheaper model. A shorter panel list runs fewer subagents, one for each entry. Save /poteto-mode for work that needs rigor.
/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.
For whether later tasks route automatically, use the setup and runtime sources under Get set up. Check that routing is enabled for this installation before promising it. Without automatic routing, invoke poteto-mode for each new task. Mid-chat, "new task" makes the mode match a fresh playbook. For subagent defaults, read poteto-mode's Subagents section and the current runtime's mapping.
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.
| The user wants to | Skill |
|---|---|
| Do any non-trivial task with rigor | /poteto-mode |
| Check that the agent understood their goal and the problem before it starts | /in-your-own-words |
| Aim a task higher before starting: more expert, more outcome-focused, not overspecified | /sharpen |
| Know how code works now, or where new code should live | /how |
| Know why code is shaped this way, or where a number came from | /why |
| Understand a change or subsystem, explained plainly | /teach |
| Catch up on their own recent work on a topic | /recall |
| Catch up on what changed in this chat since their last message, in plain words and small visuals, with every item waiting on them listed and decidable from the reply alone | /ketchup |
| Know what a small diff could break outside itself | /blast-radius |
| Settle types and module shape before code that crosses a function boundary | /architect |
| Get several attempts at one brief, merged into the best one | /arena |
| Run parallel checks over slices, or race workers | /swarm |
| Have different models review a diff and try to break it | /interrogate |
| Fix a bug test-first when a cheap local test exists | /tdd |
Apply TypeScript rules to .ts or .tsx work | /typescript-best-practices |
| Strip comments before review, using a reviewer that didn't write them | /no-comments |
| Clean AI tells out of prose | /unslop |
| Write docs, an RFC, a README, a PR description, or a commit message to a standard | /technical-writing |
| Hear the last reply again in plain words | /bro |
| Give agents a scripted way to drive the app and prove behavior | /create-verification-skill |
| Bring a verification skill and its feature map back in line with the app | /maintain-verification-skill |
| Formally verify a race, invariant, or other property that tests rarely reach | /create-formal-verification-skill |
| Bring a formal verification back in line after the code it covers changed, and learn whether a failure is drift or a bug | /maintain-formal-verification-skill |
| Vet a performance number before reporting or acting on it | /benchmark-checklist |
| Run a large or cross-cutting change, or one to review after stepping away | /figure-it-out |
| Keep a decision log during a run, and review it afterward | /show-me-your-work |
| Pick a model for each role and a default effort | /setup-pstack |
| Turn their own working habits into a personal mode skill | /automate-me |
| Turn what a finished task taught into skill edits | /reflect |
| Stop agents from repeating the same mistakes in this repo | /correct |
| Find their way around pstack | /poteto-help |
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.Not in pstack:
run skill and a project verify skill./loop is a Claude Code bundled skill, and the plugin-dev:skill-development skill is Claude Code's skill-authoring guidance./poteto-mode playbook. If the slash menu shows an orchestrate command, another plugin provides it.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:
Without /poteto-mode, a phrase such as "babysit this pr" can start pstack's standalone /babysit skill instead. The Playbooks section lists every playbook and when it applies. Read Babysit or Shipping for the port's PR workflow.
pstack has no planning skill. Claude Code's plan mode works alongside it. 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." On Claude Code the principle-* leaves are hidden from the slash menu and /poteto-mode reads them by path; other runtimes may list them in their skill picker. The Principles index lists them.
| Symptom | Fix |
|---|---|
| The mode stopped applying after a few turns | Check the current runtime's routing configuration through the sources under Get set up. Without automatic routing, invoke poteto-mode for each task. |
| A question got treated as the next step of the last task | Say "new task", or say the turn doesn't need the mode. |
| A new model choice had no effect | Read setup-pstack and the current runtime's mapping, then check its sheet location and loading method. |
| Runs cost more than expected | See the cost paragraph under Get set up. |
| A skill didn't load on its own | Read its description and the current runtime's skill-loading instructions. Invoke it explicitly when needed; /poteto-mode doesn't run every skill. |
| Parallel agents overwrote each other | Give each agent its own worktree. |
| An overnight run moved but finished nothing | Read Autonomous run and the current runtime's wake mechanism. For a queue, read the selected Autopilot playbook above. Give the run a check that can pass or fail. |
| The reply claims success from a green build | Ask for the real command, flow, stored value, or profile. That's the prove-it-works principle. |
For a run that drifts, references/prompting.md has one-line steers, and references/recipes.md has prompts to adapt.
/automate-me drafts a personal mode skill from the user's own history, to use alongside /poteto-mode./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.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.
No reviews yet. Tell others what you thought.
No login needed. Share how it worked for you, ask a question, or note where it did not run.
No comments yet. Be the first to write one.
Plan types, function inputs and outputs, and module boundaries before implementation. Compare structurally different designs from multiple AI models, document the chosen approach, and guide coding while tracking changes to the agreed design.
Generate several candidate solutions in parallel, compare them against concrete criteria, and choose a base. Combine useful parts from other candidates, then verify the final artifact and document why each major choice was made.
Turn recurring work habits and communication preferences into a personal agent skill. It combines evidence from workspace conversations with direct questions, then drafts or updates instructions for how agents should work with you.
Monitor an open pull request, fix failing automated checks and merge conflicts, and address straightforward review feedback. Recheck after updates, report the resulting status, and hand decisions requiring design judgment back to the user.
Checks whether performance measurements support a speedup, slowdown, or technology choice. It examines bottlenecks, production settings, errors, repeatability, and completed work, then guides reporting with run counts, ranges, and a clear verdict.
Investigate what a code change could break beyond the edited files. Trace downstream effects, identify the key assumption behind its safety, and test that assumption with real code while clearly reporting unresolved risks.