# Poteto Mode

> Run a rigorous pstack engineering workflow in Codex. Use when the user invokes $poteto-mode or asks for pstack-style investigation, implementation, verification, review, shipping, or sustained autonomous work.

- Skill: `vaibtan/poteto-mode` (Agent Skill, multi-file: 47 files)
- Install (CLI): `npx skillmds@latest add vaibtan/poteto-mode`
- Raw SKILL.md: https://api.skillmd.com/api/skills/vaibtan/poteto-mode/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Productivity
- Author: Vaibtan (https://skillmd.com/u/vaibtan)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/vaibtan/poteto-mode

---


# Poteto mode for Codex

Carry the user's authorized task to a verified outcome. Match the task to one playbook, load only the supporting skills and principle sections that change a decision, and keep the main thread focused on evidence and integration.

The user's instructions and repository `AGENTS.md` files take precedence over this skill. Do not treat this mode as authorization for deployment, merge, publication, destructive operations, external messages, paid services, or other actions outside the request.

## Start

1. Read the matching playbook under `playbooks/` before acting. When Routing names a supporting skill directly, that skill owns the workflow and no playbook is required.
2. Inspect the repository instructions, current worktree, and task-relevant source.
3. State the done predicate and the strongest practical verification.
4. Keep a compact task list when the work has three or more dependent steps.
5. Apply only the relevant named sections from [engineering principles](references/principles.md). Do not load or repeat the whole reference as a ritual.

Read [Codex runtime mapping](references/codex-runtime.md) only when the selected workflow actually delegates, waits, recalls prior task state, controls a UI, schedules follow-up work, or needs an explicit model choice. Skip it for single-agent local work.

## Routing

- Read-only explanation of an existing system or rationale: [Investigation](playbooks/investigation.md), plus `$how` or `$why` when their distinct evidence models apply.
- Design, contract, module-boundary, or implementation-ready specification: `$architect`. Follow its design-only boundary when the user asks to review the design before implementation.
- Reported defect: [Bug fix](playbooks/bug-fix.md).
- Measured slowness: [Performance issue](playbooks/perf-issue.md) or [Hillclimb](playbooks/hillclimb.md) for repeated metric improvement.
- Live symptom or captured profile: [Runtime forensics](playbooks/runtime-forensics.md) or [Trace forensics](playbooks/trace-forensics.md).
- New behavior: [Feature](playbooks/feature.md).
- Behavior-preserving structural change: [Refactoring](playbooks/refactoring.md).
- An empirical design choice: [Prototype](playbooks/prototype.md).
- Pixel-equivalent UI work: [Visual parity](playbooks/visual-parity.md).
- Skill authoring or prompt evaluation: [Author a skill](playbooks/authoring-a-skill.md) or [Eval](playbooks/eval.md).
- PR follow-through: [Babysit](playbooks/babysit.md), [Shipping](playbooks/shipping.md), or [Open a PR](playbooks/opening-a-pr.md).
- One long-running task: [Autonomous run](playbooks/autonomous-run.md).
- A multi-day program with many independent units: [Orchestrate](playbooks/orchestrate.md).
- Independent PR queue or linear stack: [Autopilot full](playbooks/autopilot-full.md) or [Autopilot stack](playbooks/autopilot-stack.md).
- Resume, pause, or plan multiple phases: [Session pickup](playbooks/session-pickup.md), [Pause safely](playbooks/pause-safely.md), or [Multi-phase plan](playbooks/multi-phase-plan.md).
- Recover disk from worktrees or simulators: [Worktree cleanup](playbooks/worktree-cleanup.md).
- No close match: `$figure-it-out`.

## Supporting skills

Load a supporting skill only when its trigger is present.

- `$architect` for a contract or module boundary that must be settled before implementation. For an implementation-ready design document, it routes to `architect/references/technical-spec.md`.
- `$arena` for several competing solutions to the same artifact. `$swarm` is for independent slices or coverage.
- `$interrogate` for adversarial review of a diff or design.
- `$blast-radius` for a small change whose downstream effects are unclear.
- `$tdd` when the user asks for TDD or a cheap local regression test is the clearest reproduction.
- `$typescript-best-practices` when reading or changing TypeScript. Its larger standards are conditional references, not default context.
- `$no-comments` before review when comments may narrate code or encode unenforced invariants.
- `$technical-writing` when the user explicitly asks to write or review prose, or when a narrative document has no dedicated workflow. A structured artifact such as an architect technical spec uses its own writing rules. Use `$unslop` only for an explicit cleanup request or when a draft contains patterns that skill owns; do not load both by default. `$bro` only restates the previous response in plain language.
- `$show-me-your-work` for long or unattended work where a decision trail helps review.
- `$create-verification-skill` when a project lacks a repeatable real-surface verification path. `$maintain-verification-skill` audits an existing one.

## Work discipline

- Name the caller-visible behavior and the data shape before writing nontrivial logic.
- Inspect existing contracts and callers before introducing a new abstraction or dependency.
- Use the smallest change that establishes the requested outcome, while fixing the root cause across the required semantic surface.
- Preserve unrelated work. Give parallel writers separate files or worktrees.
- Review every delegated result and diff yourself. Subagent output is evidence, not authority.
- Verify the real artifact when practical. Compilation and unit tests are supporting evidence, not universal proof of runtime behavior.
- Ask the user only for a genuine product choice, unavailable credential, irreversible action, or missing fact that cannot be established safely.
- Stop at the boundary of the user's authorization. Prepare a concrete reviewable result before requesting any needed external action.

## Model routing

Immediately before delegation or an explicit model selection, read `$CODEX_HOME/pstack-models.toml` when it exists. Otherwise use the profiles in [Codex runtime mapping](references/codex-runtime.md). Skip model configuration for single-agent work. Use `$setup-pstack` to change profiles or role assignments. Omit model overrides when a configured role says `inherit-parent`.

## Reply

Lead with the outcome. State material changes, verification actually run, and any remaining boundary or uncertainty. Use concise prose and lists only when they improve scanning. Do not claim evidence that was not observed in the current task.