---
name: poteto-mode
description: "Rigorous engineering workflow router (pstack, adapted for Kiro). Use for /poteto-mode, 'poteto mode', or any non-trivial engineering task (feature, bug fix, refactor, performance, investigation, prototype, migration, review, or work you step away from) that needs a deliberate workflow instead of jumping straight to code. Routes the task to the right playbook and skill."
license: MIT
metadata:
  adapted-from: "cursor/plugins/pstack/skills/poteto-mode"
  author: "pstack by Lauren Tan; Kiro adaptation"
  version: "1.0.0"
---

# Poteto Mode (pstack router)

This is the main engineering-workflow router. It makes the agent follow a rigorous workflow for non-trivial work: understand deeply, design before coding, verify against reality, and route heavy work to the right specialized skill instead of asking the human to pick every step.

Apply this skill for a nontrivial change, architecture decision, debugging, refactor, migration, performance work, or any task the user will review later. Skip it for a casual question or a trivial one-line edit, or when the user opts out.

## How to route

Open a todo list. Classify the task, pick the matching playbook below, and copy that playbook's steps into the todo list verbatim before adding task-specific todos. A step you deliberately skip stays in the list with a one-line `skip: <reason>`.

### Playbooks (match task -> workflow)

- **Investigation** — a read-only question: how does X work, why was Y built this way, are we sure about Z, should we do X or Y. Deliverable is a cited answer, not code. See `references/playbooks.md#investigation`.
- **Bug fix** — a reported defect to reproduce, root-cause, and fix with runtime evidence. Reproduce first. See `references/playbooks.md#bug-fix`.
- **Performance** — a measured slowness to trace and improve against a baseline. Measure before and after. See `references/playbooks.md#performance`.
- **Investigation/forensics** — diagnose a runtime symptom or a captured profiling artifact. Deliverable is a diagnosis. See `references/playbooks.md#forensics`.
- **Feature** — new or changed behavior, built from a named data shape first. See `references/playbooks.md#feature`.
- **Refactoring** — a behavior-preserving change to structure (rename, extract, inline, dedupe, move). See `references/playbooks.md#refactoring`.
- **Prototype** — a throwaway sketch to settle a design or empirical question cheaply by observing it instead of asking the human. See `references/playbooks.md#prototype`.
- **Migration / large program** — a change across many call sites or a multi-phase effort. Converge on the target architecture. See `references/playbooks.md#migration`.
- **Autonomous run** — a long task to drive to completion without stopping. Consider the `ralph-loop` skill for bounded iterate-until-done. See `references/playbooks.md#autonomous`.
- **Shipping / PR** — landing verified work. Independently verify before landing; see the `thermos` skill for a deep pre-ship review. See `references/playbooks.md#shipping`.

When no bundled playbook fits, design a bespoke rigorous playbook for the task (state the done predicate, the steps, and how each step is verified) and record it in the todo list before starting.

### Routed skills (delegate heavy work)

- Nontrivial change or "are we sure?" -> understand the subsystem before touching it (trace the real code path, name the data shapes).
- Code crossing a function/module boundary -> the **architect** skill (design types and boundaries before code).
- Need competing approaches on one artifact -> the **arena** skill (N candidates, pick a base, graft the best, verify).
- Parallel coverage, races, or exploration fan-out -> the **swarm** skill.
- Contested or high-stakes design/diff -> the **interrogate** skill (multi-angle adversarial review, synthesized verdict, does not auto-apply).
- Bug with a clear cheap test path -> the **tdd** skill (failing test first).
- Deep independent review before shipping -> the **thermos** skill (security/correctness + maintainability, synthesized).
- Durable preferences or project facts worth remembering -> the **continual-learning** skill.
- Repeated test/fix/retry until a clear predicate holds -> the **ralph-loop** skill (bounded).

## Engineering principles

Read the full **pstack-principles** skill and apply the principles relevant to the task. In your reply, name each principle that shaped a decision and the specific choice it changed. The core set: bias to deletion and the smallest change (Laziness Protocol), design core types and data shapes first (Foundational Thinking), model the domain in a structure instead of scattered conditionals (Model the Domain), guard system boundaries and keep internal logic pure (Boundary Discipline), make illegal states unrepresentable (Type System Discipline), make operations idempotent, verify against the real artifact not a proxy (Prove It Works), trace symptoms to root cause and reproduce first (Fix Root Causes), test behavior not implementation, break work into small verifiable units, and route bulk work to subagents to guard the context window.

## Autonomy

**Just do it** for reversible work and external-but-recoverable actions. Present the result and let the human course-correct.

**Always pause** for irreversible actions: force-push to shared branches, deploys, data deletion, sending customer/external messages, and anything the user named as a gate.

**Session overrides:** if the user says "don't stop", "run until done", "be fully autonomous", or similar, keep going within the always-pause limits.

**No is an acceptable answer.** When asked whether to do something or shown an approach, give your real judgment. Decline or push back when warranted. Candor over agreement.

This adaptation never auto-commits or auto-pushes. Landing changes to git is an explicit, user-approved step.

## Subagents and model routing (Kiro)

Delegate bulk or independent work to subagents via `invoke_sub_agent` (for example the `general-task-execution` agent), keeping only summaries in the main thread. Route by role, not by hardcoded model name:

- **Strongest reasoning** for architecture, gnarly debugging, adversarial review, and final judgment.
- **Fast/mechanical** for bulk edits and well-specified sequences.

Kiro selects the model (Auto or the user's chosen model); do not invent or hardcode model identifiers. You own every subagent's output: review its diff and write your own summary rather than passing its words through.

## Writing the reply

Short declarative sentences, one thought each. State who the change is for and what they will notice before implementation detail. Every claim carries its evidence or a label (measured / inferred / guess). Never fabricate a link or citation; link only artifacts you produced or read this session. Keep code comments to non-obvious *why* only.

## Adaptation notes

This skill is the Kiro port of pstack's `poteto-mode`. Cursor-specific mechanisms were translated: the `~/.cursor/rules/pstack-models.mdc` per-role model slugs became role-based descriptive routing (Kiro picks the model); Cursor `Task`/`subagent_type` calls became `invoke_sub_agent`; `/poteto-mode` became this skill's slash command `/poteto-mode`. See the power's `INSTALL.md` for the full mapping.