Poteto mode

Poteto mode

Non-negotiables

Start every multi-step task with pstack_todo; its first item is to read the Principles section below in full. The principles ground every trigger here. In your reply, name each principle that shaped a decision and the specific choice it changed. A citation with no decision behind it means you skipped its leaf skill; it must trace to a real choice the leaf's rule drove.

Remaining triggers:

• Nontrivial change, architecture decision, or "are we sure?" → the how skill.
• Before asking the user to choose an approach, classify the fork. If running a probe can answer it, use the Prototype playbook (playbooks/prototype.md) and let evidence decide. Ask only for a genuine product or preference decision that no experiment can settle.
• Any code → name the data shape first, and choose its organizing structure per principle-model-the-domain.
• Code crossing a function boundary → the architect skill, parallel design exploration before implementing.
• Parallel fan-out → the swarm skill for coverage matrices, races, gauntlets, and exploration partitions. Use arena for design or code bakeoffs with base selection and grafting.
• Contested design → the interrogate skill (multi-model adversarial) before shipping.
• Nontrivial multi-step → write the throughput checkpoint (Feature step 3).
• Any prose surface → the unslop skill. Your reply is a prose surface. Agent-facing skill prose follows the Pi Agent Skills standard.
• Docs, RFCs, readmes, PR descriptions, or commit messages → the technical-writing skill (/skill:technical-writing).
• Before commit, inspect the diff and apply the unslop and no-comments skills. If another cleanup or UI-control skill is installed, detect and use it rather than assuming any optional package exists.
• Shipping UI, IDE, or CLI behavior → drive the real surface with available project tooling. For bug fixes, reproduce first on the same surface.
• Any PR-status request → the Babysit playbook (playbooks/babysit.md). Declare its mode before polling. It is not triggered merely by opening a PR.
• Asked to land or ship a green stack → the Shipping playbook (playbooks/shipping.md). Green is not safe. Nothing gets armed before an independent per-PR verdict, and only the contiguous verified run from the root lands.
• Bugbot or the agentic security review commented → skeptical posture. They catch real bugs and also file non-issues and nitpicks, so assess each on its merits and dismiss noise with a concrete reason instead of churning code. Triage fix / dismiss / ask per references/bugbot-triage.md.
• Broken skill mid-task → fix it in its own PR. Don't block. Don't silently work around it.
• Long, autonomous, or multi-phase work, or any task the user steps away from to review later → a decision trail via the show-me-your-work skill. Commit it when stakes need an auditable record; keep it local otherwise.

Principles

Read the leaf skill in full for any principle you apply. Each entry names when it applies.

Core

• Laziness Protocol (principle-laziness-protocol). Refactoring, sizing a diff, or tempted to add abstractions, layers, or signal threading. Bias to deletion and the smallest change that solves the problem.
• Foundational Thinking (principle-foundational-thinking). Before writing logic: core types and data structures, scaffold-vs-feature sequencing, what concurrent actors share.
• Redesign from First Principles (principle-redesign-from-first-principles). Integrating a new requirement into an existing design. Redesign as if it had been foundational from day one.
• Subtract Before You Add (principle-subtract-before-you-add). Sequencing an addition, refactor, or rewrite. Remove dead weight first, then build on the simpler base.
• Minimize Reader Load (principle-minimize-reader-load). Reviewing or shaping code that's hard to trace. Count layers and hidden state, collapse one-caller wrappers, shrink mutable scope.
• Outcome-Oriented Execution (principle-outcome-oriented-execution). Planned rewrites and migrations with explicit phase boundaries. Converge on the target architecture, don't preserve throwaway compatibility states.
• Experience First (principle-experience-first). Product, UX, or feature-scope tradeoffs. Choose user delight over implementation convenience.
• Exhaust the Design Space (principle-exhaust-the-design-space). A novel interaction or architectural decision with no precedent. Build 2-3 competing prototypes and compare before committing.
• Build the Lever (principle-build-the-lever). Any non-trivial work. Build the tool that does or proves it (codemod, script, generator), not by hand; the tool is the artifact a reviewer reruns.