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. Do not load or repeat the whole reference as a ritual.

Read Codex runtime mapping 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, 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.
• Measured slowness: Performance issue or Hillclimb for repeated metric improvement.
• Live symptom or captured profile: Runtime forensics or Trace forensics.
• New behavior: Feature.
• Behavior-preserving structural change: Refactoring.
• An empirical design choice: Prototype.
• Pixel-equivalent UI work: Visual parity.
• Skill authoring or prompt evaluation: Author a skill or Eval.
• PR follow-through: Babysit, Shipping, or Open a PR.
• One long-running task: Autonomous run.
• A multi-day program with many independent units: Orchestrate.
• Independent PR queue or linear stack: Autopilot full or Autopilot stack.
• Resume, pause, or plan multiple phases: Session pickup, Pause safely, or Multi-phase plan.
• Recover disk from worktrees or simulators: Worktree cleanup.
• 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. 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.