---
name: poteto-help
description: Guides users through installing pi-herdr-pstack, /setup-pstack, /poteto-mode, Matt Pocock's idea-to-ship flow, and picking the skill, playbook, flow, or principle for a task. Type /skill:poteto-help with a question.
disable-model-invocation: true
---

# Poteto help

Answer the user's question about pstack, hand them a prompt they can send, and name 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 `../../pstack/poteto-mode/SKILL.md`, do the work under it, and mention once that `/poteto-mode on` keeps the mode on for the session.

This file maps questions to the skills and files 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. Paths here are relative to this skill directory. The package groups its skills in three folders, so a path that starts with `../../pstack/`, `../../mattpocock/` or `../` (this skill's own `merged` folder) names another skill in the same package. Give the user the installed file's path. For anything else, the only public page to link is the package README at https://github.com/giuseppecrj/pi-herdr-pstack. Never build a link to a file inside that repository.

## What this release ships

This release ships 80 skills and all 23 poteto-mode playbooks: pstack's skills in the tables below, and the skills of Matt Pocock's idea-to-ship flow, mapped in `references/flows.md` (see **Matt Pocock's flows** below). Some workflows are scoped down for Pi. Their rows and phrases below give each limit in one line, and the hub (`../../pstack/poteto-mode/SKILL.md`) and the playbook or skill state it in full. Say the limit when it changes the answer.

Pstack ships no named roles. Every delegate it launches is a bare pi-herdr-agents subagent that gets a reference prompt as its `systemPrompt`. `/skill:no-comments` launches its comment reviewer this way. A user who wants a named role installs a role pack and asks for that role by name.

## 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
- Plan, spec and build with Matt Pocock's flow
- Fix a run that went wrong
- Make pstack my own

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

- If the user hasn't run `/setup-pstack` in this session, suggest it first. It refuses with a reason when pi-herdr-agents 3.10.0 or later is not loaded, and otherwise lists the authenticated models and the saved model and thinking of each task category before it asks anything. When the setup question below applies, ask that once instead of a separate suggestion.
- No `verify-*` skill or other app harness in the project means agents have no scripted way to drive the app. Mention the gap when the question is about proving a change works, and offer the **create-verification-skill** skill, which generates one.
- No formal verification skill in the project means no property is checked past what tests reach. Mention the gap when the question is about a race, an invariant, or another case tests rarely hit, and offer the **create-formal-verification-skill** skill. 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 answer depends on the task categories pstack uses (`coding`, `review`, `recon`, `qa`, `architecture`, `docs`) and you cannot see that they are set, ask once whether to run `/setup-pstack` now or leave the categories as they are for now. It depends when the user is new, the question is about setup or cost, or the answer would name which model a category resolves to. Ask at most once per chat. If the need is still unclear, fold this into that one multiple-choice question. Offer two choices:

- Now: tell them to type `/setup-pstack`. It asks for a budget, shows every category with its models and thinking, and lets them change it before anything is saved. pi-herdr-agents writes only after they approve the exact change in its dialog. Answer their question too. This skill writes nothing.
- Later: answer their question, and add one line: Until a category is set, poteto-mode delegations that use it fail. They don't fall back to host defaults, because poteto-mode always passes `task:<category>`. That stays true until an approved write from `/setup-pstack` or `/subagents-init` sets it.

You cannot tell whether those categories are unset on your own. No host tool reads them. `subagents_list` lists roles. Leave `subagents_write_task_models` unused. Leave `$PI_CODING_AGENT_DIR/herdr-agents/config.json` (default `~/.pi/agent/herdr-agents/config.json`) unread and unwritten. The subagent tool's routing text is not a check. The only reliable signal is a setup brief already in this session: the message `/setup-pstack` sent, after the line "/setup-pstack started the setup flow.". Under its "Current choices" heading, each category's line is `- <category>: <models> / <thinking>`.

- Unset, so ask when the answer depends on the categories: one of `coding`, `review`, `recon`, `qa`, `architecture`, `docs` has `null` as its models, the value before ` / `.
- Not unset, so skip the question: none of the six has `null` as its models. If the session also shows a saved write after that brief, its saved `tasks` replace the brief's models.
- No brief in the session: you have not checked. Ask when the answer depends on the categories, and say the check has not been run.

## Get set up

1. Install pi-herdr-agents and pi-herdr-pstack through Pi. pi-herdr-agents is the execution host and an explicit prerequisite: pstack declares it as a peer, and a peer declaration does not activate an extension. Install pstack where pi-herdr-agents children load packages too, normally the same user settings. Both packages are experimental, and the README has the current install steps.
2. Run `/setup-pstack`, optionally with a budget or a request, for example `/setup-pstack large` or `/setup-pstack use <provider>/<model-id> for review`. It asks for a budget (unlimited, large, medium or small, which set every category's thinking to max, xhigh, high or medium, clamped to what each model supports), shows every task category with its models and thinking and the upstream roles it drives, and lets the user change any of them. pi-herdr-agents then shows the exact change and writes it only after the user approves. Reload Pi after a saved change. Setup ends by offering once each to generate a verification skill and a formal verification skill when the project has none.
3. Start a real task with `/poteto-mode <task>`, stating a goal and a check that can pass or fail.

Installing adds two commands, `/poteto-mode` and `/setup-pstack`. Most skills are explicit-only: one loads when the user types `/skill:<name>`, or when poteto-mode or another skill reads it for a step. These can also load from the user's words: `setup-pstack`, and from Matt Pocock's skills `code-review`, `codebase-design`, `diagnosing-bugs`, `domain-modeling`, `grilling`, `pr`, `prototype`, `research`, `wizard` and `writing-for-agents`. Offer to word their first prompt with them, per `references/prompting.md`.

pi-herdr-agents asks the user to approve every task-model write in its own dialog, whichever command or package asks for it, and refuses one in a session without dialogs. `/subagents-init` drafts from the host's registry brief through that same dialog. Task categories are shared pi-herdr-agents preferences, so a change affects every workflow and role pack that uses them, not only pstack.

If cost is the worry, say where the tokens go and how to spend fewer. pstack spends extra tokens on subagents and reviews, and each delegate is one subagent. poteto-mode picks each delegate's model through a task category such as `task:coding` or `task:review`. Pointing a category at a cheaper exact model, or choosing a smaller budget, through `/setup-pstack` makes those delegates cheaper. Asking for fewer delegates spends fewer tokens. Save `/poteto-mode` for work that needs rigor.

pstack in this package is built for Pi and pi-herdr-agents. Its skills use the Agent Skills format, so other tools can read them. But poteto-mode delegates through pi-herdr-agents' `subagent` tool, and the commands come from this package's extension, so those parts work only in Pi with pi-herdr-agents loaded.

## Start a task with `/poteto-mode`

poteto-mode matches the task to a playbook, copies the playbook's steps into the checklist, and reads 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.

Whether the mode stays on depends on how the user starts it:

- `/skill:poteto-mode` loads the methodology for the current request only. It fades as the session moves on, and it never turns the mode on.
- `/poteto-mode` or `/poteto-mode on` turns sticky mode on for the current session branch and starts no work. Each prompt gets a short checklist. The extension supplies the full hub when it is missing from model context, including after compaction, without adding another copy while it is present.
- `/poteto-mode <task>` turns the mode on and starts the task. It includes the full hub only if it is missing from context. It is refused while a turn is running, and nothing is queued.
- `/poteto-mode status` says whether the mode is on and whether the `poteto-mode` skill resolves to this package.
- `/poteto-mode off` stops future reminders and automatic hub loading. Earlier context and running subagents are unchanged.

Mid-session, "new task" makes the mode match a fresh playbook. The mode never grants permission. Pushes, pull requests, merges, deletions, messages and configuration writes still need the user's request or the repository's instructions, per `../../pstack/poteto-mode/references/authorization.md`. To launch a delegate of your own in poteto-mode's style, copy an example from `../../pstack/poteto-mode/references/delegation.md`.

## Pick a skill

The default answer is `/poteto-mode`, which reads 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`, or `/skill:poteto-mode` for one request |
| Know how code works now, or where new code should live | `/skill:how` |
| Know why code is shaped this way, or where a number came from | `/skill:why` |
| Understand a change or subsystem, explained plainly | `/skill:teach` |
| Catch up on their own recent work on a topic | `/skill:recall` |
| Check that the agent understood their goal and the problem before it starts | `/skill:in-your-own-words` |
| Get a prompt rewritten deeper, not bigger, before sending it: what a top professional would add, their raw material and methods, and an outside check. It returns the prompt and doesn't do the task | `/skill:sharpen` |
| 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 | `/skill:ketchup` |
| Know what a small diff could break outside itself | `/skill:blast-radius` |
| Settle types and module shape before code that crosses a function boundary | `/skill:architect` |
| Get several attempts at one brief, merged into the best one | `/skill:arena` |
| Run parallel checks over slices, or race workers | `/skill:swarm` |
| Have adversaries try to break a change, and keep only findings a run proves | `/skill:interrogate` |
| Review a branch, a PR or uncommitted work against the repo's documented standards and the spec, read-only | `/skill:code-review` |
| Answer a design question or an empirical fork with a throwaway prototype, in scratch by default | `/skill:prototype` |
| Turn an idea into a spec, tickets and reviewed code, or triage incoming issues | Matt Pocock's flow: see **Matt Pocock's flows** below |
| Fix a bug test-first when a cheap local test exists | `/skill:tdd` |
| Diagnose a hard bug, a flake or a performance regression, starting from a tight feedback loop | `/skill:diagnosing-bugs` |
| Apply TypeScript rules to `.ts` or `.tsx` work | `/skill:typescript-best-practices` |
| Strip comments before review, using a reviewer that didn't write them | `/skill:no-comments` |
| Clean AI tells out of prose | `/skill:unslop` |
| Write docs, an RFC, a README, a PR description, or a commit message to a standard | `/skill:technical-writing` |
| Write a skill, an `AGENTS.md` or another document agents read | `/skill:writing-for-agents` |
| Hear the last reply again in plain words | `/skill:bro` |
| Give agents a scripted way to drive the app and prove behavior | `/skill:create-verification-skill` |
| Bring a verification skill and its feature map back in line with the app | `/skill:maintain-verification-skill` |
| Formally verify a race, invariant, or other property that tests rarely reach | `/skill: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 | `/skill:maintain-formal-verification-skill` |
| Show a PM or designer what the user sees as a chart checked by a TLA+ model, with the shortest path to each state that breaks a rule | `/skill:statechart` (optional; uses pack `tla-ts`, no Java) |
| Vet a performance number before reporting or acting on it | `/skill:benchmark-checklist` |
| Run a large or cross-cutting change, or one to review after stepping away | `/skill:figure-it-out` |
| Keep a decision log during a run, and review it afterward | `/skill:show-me-your-work` |
| See which models and thinking pstack's delegates use, or change them with approval | `/setup-pstack`, whose steps are in `/skill:setup-pstack` |
| Turn their own working habits into a personal mode skill | `/skill:automate-me` |
| Turn what a finished task taught into skill edits | `/skill:reflect` |
| Turn what a session taught into guardrails for the repo and its environment: checks, coding standards, `AGENTS.md` pointers | `/skill:retro` |
| Stop agents from repeating the same mistakes in this repo | `/skill:correct` |
| Build a local web page that starts a Pi run per request | `/skill:make-bot-ui`. Loopback only, a fresh `pi -p` run per request, and exposure or installs need authorization |
| Find their way around pstack | `/skill:poteto-help` |

If a skill in this package is missing from the table and from `references/flows.md`, read its frontmatter and route by its description. The `principle-*` directories have their own table under principles below.

Close calls:

- `/skill:how` explains what the code does. `/skill:why` explains the reasons. `/skill:teach` runs one or both and explains the result plainly. how and why fan out read-only children, and why's investigators launch without a tools list so they see MCP servers.
- `/skill:arena` gives every worker the same brief and merges the best parts. `/skill:swarm` splits work into slices or a race and returns one report. Arena uses one exact model per family and discloses a same-family fallback. Swarm launches separate bare calls and gives writers worktrees.
- `/skill:architect` implements right after it settles the design. Add "with checkpoint" to review the design before it writes code.
- `/skill:interrogate` fans out adversaries that try to break the change, and keeps only findings a run proves. `/skill:blast-radius` looks for breakage outside the diff and proves the one fact that makes the change safe. `/skill:code-review` reads the diff, committed or not, against the repo's documented standards and the spec, in two separate read-only reports. poteto-mode's own review gates are unchanged by it.
- `/skill:reflect` turns lessons into skill edits. `/skill:retro` turns them into guardrails for the repo and its environment (checks, coding standards, `AGENTS.md` pointers, tooling). Each sends the other kind of lesson to the other skill, and neither changes anything until the user approves.
- `/skill:diagnosing-bugs` is the technique for a hard bug. The Bug fix playbook (`../../pstack/poteto-mode/playbooks/bug-fix.md`) is poteto-mode's route: it uses the skill for technique and keeps its own gates, a repro observed twice through the reported path and verification on the same surface. The skill's feedback loop never replaces that repro.
- `/skill:writing-for-agents` is for documents agents read. `/skill:technical-writing` is for prose humans read. Where they conflict, the reader decides which one wins.
- `/skill:prototype` is the procedure. The Prototype playbook (`../../pstack/poteto-mode/playbooks/prototype.md`) is poteto-mode's route to it, and hands the result to Feature.
- `/skill:recall` rebuilds context across recent sessions in this working directory, never another project's. Resuming one specific session or branch is the Session pickup playbook, `../../pstack/poteto-mode/playbooks/session-pickup.md`.
- `/skill:figure-it-out` designs one rigorous run and keeps its trail via `/skill:show-me-your-work`. The Orchestrate playbook (`../../pstack/poteto-mode/playbooks/orchestrate.md`) runs a program of many PRs as a depth-1 single-session coordinator with a hand-kept store. It is not an unattended or multi-day runner. The Autonomous run playbook, `../../pstack/poteto-mode/playbooks/autonomous-run.md`, drives one task to a finish condition.

Not in pstack:

- pstack has no orchestrate skill. Orchestrate is a poteto-mode playbook. pi-herdr-agents ships its own orchestrate skill for bounded reviews, which is unrelated. Any other orchestrate skill in the command list comes from another package.
- pstack keeps no model configuration, rule file or alias of its own. Models come from pi-herdr-agents.
- `/skill:recall` rebuilds context across recent chats. `/skill:ketchup` covers only this chat since the user's last message. Resuming one specific chat or branch is the Session pickup playbook.

## Playbooks and principles

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

- "babysit this pr" or "check on pr 123" runs Babysit (`../../pstack/poteto-mode/playbooks/babysit.md`). It drives the PR to merge-ready and stops there. It doesn't merge unless the user asks to merge, land, or ship. It uses `gh` only, a watcher child does the waiting, and every push, reply, re-run or merge needs authorization.
- "land the stack" runs Shipping (`../../pstack/poteto-mode/playbooks/shipping.md`). It lands the verified run only on that explicit request, and pushes, retargets and arming need their own grants. It uses `gh` only, waits through one-shot watcher children, and on a merge-queue base it reports and stops without merging.
- "take over this branch" runs Session pickup.
- "pause safely" runs Pause safely.
- "full autopilot on this queue" runs Autopilot-full (`../../pstack/poteto-mode/playbooks/autopilot-full.md`). "autopilot, don't merge" runs Autopilot-stack (`../../pstack/poteto-mode/playbooks/autopilot-stack.md`). Both are root-run, with fresh owner rounds continuing in the retained owner checkout and audits on wake, never a timer. Autopilot-full merges only under a grant that names merging, and Autopilot-stack never merges.
- "run the eval playbook" runs Eval (`../../pstack/poteto-mode/playbooks/eval.md`).
- "clean up worktrees" runs Worktree cleanup (`../../pstack/poteto-mode/playbooks/worktree-cleanup.md`). It inventories with `worktree_list` and removes each path only on its own authorization.

Without poteto-mode, a phrase such as "babysit this pr" is an ordinary request, and another installed skill may answer it instead. The Playbooks section of `../../pstack/poteto-mode/SKILL.md` lists every playbook, when it applies, and any scope limit. `../../pstack/poteto-mode/playbooks/opening-a-pr.md` covers opening a PR, only when the task authorizes one.

pstack has no planning skill. For work that spans phases or stacked PRs, asking poteto-mode for a plan runs the Multi-phase plan playbook (`../../pstack/poteto-mode/playbooks/multi-phase-plan.md`), which writes the plan, checks it with its script, and doesn't implement it. For a design question, the Prototype playbook (`../../pstack/poteto-mode/playbooks/prototype.md`) settles it in code first by following the **prototype** skill.

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 `/skill:principle-<name>` still loads one on demand. The Principles section of `../../pstack/poteto-mode/SKILL.md` lists all 24 with a summary each. To recommend one, read its file first:

| The user wants to | Principle |
| Refactor, size a diff, or resist an extra abstraction | `../../pstack/principle-laziness-protocol/SKILL.md` |
| Settle core types, data structures and shared state before logic | `../../pstack/principle-foundational-thinking/SKILL.md` |
| Fold a new requirement into a design as if it had been there from day one | `../../pstack/principle-redesign-from-first-principles/SKILL.md` |
| Remove dead weight before an addition, refactor or rewrite | `../../pstack/principle-subtract-before-you-add/SKILL.md` |
| Make hard-to-trace code easier to follow | `../../pstack/principle-minimize-reader-load/SKILL.md` |
| Run a planned rewrite or migration straight to the target | `../../pstack/principle-outcome-oriented-execution/SKILL.md` |
| Weigh product, UX or scope tradeoffs for the user | `../../pstack/principle-experience-first/SKILL.md` |
| Compare competing prototypes for a decision with no precedent | `../../pstack/principle-exhaust-the-design-space/SKILL.md` |
| Stop after two fixes that share one premise have failed | `../../pstack/principle-attack-the-premise/SKILL.md` |
| Build the script or codemod that does or proves the work | `../../pstack/principle-build-the-lever/SKILL.md` |
| Replace scattered conditionals with a structure that models the domain | `../../pstack/principle-model-the-domain/SKILL.md` |
| Place validation, error handling and adapters at system boundaries | `../../pstack/principle-boundary-discipline/SKILL.md` |
| Design types that make illegal states unrepresentable | `../../pstack/principle-type-system-discipline/SKILL.md` |
| Make commands and loops safe to rerun after crashes and retries | `../../pstack/principle-make-operations-idempotent/SKILL.md` |
| Replace an internal API and delete the old one in one wave | `../../pstack/principle-migrate-callers-then-delete-legacy-apis/SKILL.md` |
| Stop concurrent actors writing the same file, branch or key | `../../pstack/principle-separate-before-serializing-shared-state/SKILL.md` |
| Prove a task is done on the real artifact | `../../pstack/principle-prove-it-works/SKILL.md` |
| Trace a bug to its root cause instead of patching the symptom | `../../pstack/principle-fix-root-causes/SKILL.md` |
| Break multi-step work into small units that each end in a check | `../../pstack/principle-sequence-verifiable-units/SKILL.md` |
| Write or keep a test that checks behavior, not internals | `../../pstack/principle-test-behavior-not-implementation/SKILL.md` |
| Decide before you measure, and find what limits a measured number before trusting it | `../../pstack/principle-explain-the-number/SKILL.md` |
| Keep bulky output out of the main thread | `../../pstack/principle-guard-the-context-window/SKILL.md` |
| Proceed on reversible work instead of asking first | `../../pstack/principle-never-block-on-the-human/SKILL.md` |
| Turn a repeated instruction into a lint, check or script | `../../pstack/principle-encode-lessons-in-structure/SKILL.md` |

## Matt Pocock's flows

Matt Pocock's skills chain into flows: an idea is grilled, turned into a spec and tickets, built test-first and reviewed, and incoming issues are triaged into that same flow. Read `references/flows.md` before you answer a question about them. It maps the main flow, its on-ramps, codebase upkeep, the vocabulary skills and the standalone skills, each step a `/skill:<name>` command. It lists only flows whose skills ship in this package together with every skill they load. Read `references/phase-boundaries.md` when the question is whether to continue, start fresh, hand off, delegate or compact between two phases of work.

- These flows need the repo configured once: `/skill:setup-repo` records the issue tracker, triage labels and domain docs the other skills read. It shows drafts and asks before it writes.
- A flow skill grants only what it says. Invoking one never authorizes a push, a pull request or a tracker write unless that skill says so, and `/skill:implement` and `/skill:implement-spec` grant none.
- The flows and poteto-mode are separate methodologies. Don't combine them silently on one task: say which one a recommendation follows.
- Playbooks are not skills, so a flow never names one as a `/skill:` command.

## Fix a run that went wrong

| Symptom | Fix |
|---|---|
| The mode stopped applying after a few turns | Check `/poteto-mode status` first. `/skill:poteto-mode` does not enable sticky mode. If off, run `/poteto-mode on`. If on and the skill is available, guidance is supplied automatically, but the model can still skip instructions. Name the missed step rather than assuming the switch reset. |
| `/poteto-mode` refused to turn on | The `poteto-mode` skill is filtered out or shadowed by another file. The message says which. `/poteto-mode status` says where the `poteto-mode` skill resolves. |
| `/poteto-mode <task>` did nothing | It is refused while a turn is running, and nothing is queued. Send it again when the session is idle. |
| A question got treated as the next step of the last task | Say "new task", or say the turn doesn't need the mode. `/poteto-mode off` stops the reminders. |
| A new model choice had no effect | A saved `/setup-pstack` change needs a Pi reload. An explicit `model` in a `subagent` call also wins over the task categories. |
| `/setup-pstack`, `/subagents-init` or a task-model write was refused | pi-herdr-agents writes only after the user chooses to save in its dialog, and never in a session without dialogs or in a subagent. A stale revision means the config changed after setup read it; run `/setup-pstack` again. If `/setup-pstack` did not start, its message says why (no pi-herdr-agents 3.10.0 or later, no dialogs, a busy session, or a config file it cannot read). |
| Runs cost more than expected | See the cost paragraph under Get set up. |
| A skill didn't load on its own | Only the skills named under Get set up load from the user's words. The others load when the user types `/skill:<name>` or when poteto-mode or another skill reads them, and poteto-mode doesn't read every skill. |
| A skill named in a reply isn't installed | Every skill in this package ships, so the package is missing, filtered or shadowed. `/poteto-mode status` says where the `poteto-mode` skill resolves. |
| Parallel agents overwrote each other | Give each parallel writer its own `worktree` in the `subagent` call, per `../../pstack/poteto-mode/references/delegation.md`. |
| A babysit, autopilot or orchestrate run sat idle | Nothing in pstack schedules a wake. The coordinator acts when a child delivers, on a stall or no-progress advisory, or when the user asks. During a watcher's blocking wait, one informational advisory per idle minute is expected and is not a stall. |
| An autonomous run moved but finished nothing | Done needs a check that can pass or fail, not a duration. See `../../pstack/poteto-mode/playbooks/autonomous-run.md`. |
| The reply claims success from a green build | Ask for the real command, flow, stored value, or profile. That's Prove It Works in the hub's Principles section. |

For a run that drifts, `references/prompting.md` has one-line steers, and `references/recipes.md` has prompts worth copying.

## Make pstack my own

- `/skill:automate-me` drafts a personal mode skill from the user's own history, to use alongside poteto-mode.
- `/skill:reflect` after a session turns its lessons into skill edits the user approves. It reads `$PI_SESSION_FILE` and this working directory's sessions, and files backlog items only with approval.
- `/poteto-mode write a skill for <workflow>` runs the authoring playbook (`../../pstack/poteto-mode/playbooks/authoring-a-skill.md`). The eval playbook (`../../pstack/poteto-mode/playbooks/eval.md`) tests a skill change blind.
- Fix a misbehaving skill in its own commit or PR, not inside the feature work where it went wrong.

## 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 path of the file the answer came from. Keep it short unless the user asked for the whole map.