pstack

Settle data shapes, ownership, boundaries, and interfaces before code crosses a function/module boundary. Use for non-trivial design work.

Spawn parallel candidate implementations for the same task, cross-judge, and graft the best parts into the winning base. Use when exploring competing designs or critical artifacts.

Create a personal mode skill from recurring workflow patterns in available history. Use when the user wants their own agent style encoded.

Prove what a small-looking change can affect before or after editing. Use for compatibility, caller, state, schema, or behavior impact analysis.

Restate the last technical explanation in plain human language with minimal jargon. Use when the user asks for a simpler version.

Generate a project-local verification skill that drives the real app and captures evidence. Use when setting up automated verification for a repo.

Design a rigorous custom playbook when no bundled playbook safely fits a large or unusual task. Use for cross-cutting ambiguous execution.

Trace how a subsystem works using code and runtime evidence. Use for architecture walkthroughs, data flow, call paths, and are-we-sure investigations.

Adversarially review a diff or design with independent lenses and evidence. Use before shipping contested or high-impact changes.

Repair a project verification skill whose feature map or commands drifted. Use when app behavior and verification docs no longer agree.

Build a small operator UI over an agent/webhook backend. Use when buttons or controls should trigger an agent workflow.

Remove redundant comments, dead workaround explanations, and AI tells from code while preserving necessary constraints. Use when cleaning up code or diffs.

Lauren Tan-inspired rigorous engineering mode for concise communication, deliberate decomposition, simple code, independent review when available, and runtime verification. Use for non-trivial engineering tasks or when the user asks for Poteto Mode/pstack-style rigor.

Inventory who actually owns or exhibits the imbalance, then challenge the shared premise before writing another patch. Use when two or more fixes that share one premise have failed the same gate.

Validate and normalize at boundaries, trust internal invariants, and keep business logic free of adapter noise. Use when at parsing, framework, process, network, storage, or user-input boundaries.

Prefer a script, codemod, generator, benchmark, or verifier that performs or proves the work repeatably over hand edits. Use when for repetitive, large, or verification-heavy work.

Turn recurring guidance into a type, lint, test, metadata flag, generator, runtime check, or skill so the system carries the lesson. Use when when the same corrective instruction appears more than once.

Build a few materially different cheap prototypes and compare evidence before committing to one design. Use when for novel interactions or architecture with no strong precedent.

Optimize for the end-user experience unless the cost violates an explicit constraint. Use when product, UX, API design, or feature-scope tradeoffs arise.

Reproduce the symptom, trace causality until one mechanism explains it, and fix that mechanism rather than compensating for downstream effects. Use when during debugging and incident repair.

Choose the core data structures, ownership, and sequencing first so downstream logic becomes simpler. Use when before writing logic, especially when state or concurrency is involved.

Route bulk exploration to isolated workers or files and bring back compact evidence summaries, not raw floods. Use when when reads, logs, fan-out, or generated output threatens to dominate context.

Bias toward deletion and the smallest change that fully solves the problem. Use when considering adding code, abstractions, dependencies, or speculative features.

Design repeated execution to converge on the same correct end state rather than multiplying side effects. Use when for commands, lifecycle steps, retries, loops, or crash recovery.

Move callers to the new shape and delete the old path in the same migration wave instead of carrying a compatibility layer. Use when when replacing an internal api.

Reduce indirection, mutable scope, and one-caller abstractions until the causal path is easy to hold in one mind. Use when when code requires too many hops, wrappers, hidden states, or mental joins.

Run the experiment or make the reversible best-effort change, then show the result. Ask only for genuine preference, authority, or irreversible decisions. Use when when a reversible empirical or implementation choice can be resolved with available tools.

Converge on the target architecture rather than preserving temporary compatibility states as permanent complexity. Use when during planned migrations or rewrites with explicit phases.

Verify the requested behavior against the real artifact or surface whenever possible; a proxy check only proves the proxy. Use when verifying changes, completing tasks, or claiming something is fixed.

Design the shape you would choose if the requirement had existed from day one, then migrate toward that shape. Use when when integrating a new requirement into a design that keeps fighting it.

Eliminate unnecessary sharing or partition ownership before adding locks, queues, or coordination. Use when concurrency, locks, queues, shared state, or complex coordination are being considered.

Break work into small units that each end with a proof and order delivery so every next unit builds on verified state. Use when for migrations, sweeps, repeated edits, and stacks.

Remove dead weight and obsolete paths first; build on the simpler remaining system. Use when before an addition, rewrite, or structural refactor.

Call the system the way its consumer does and assert meaningful observable output; avoid mocks or assertions that only mirror internal calls. Use when when writing or evaluating tests.

Make invalid states hard or impossible to represent and parse external primitives into meaningful internal types at the edge. Use at data modeling, API design, or external data ingestion points.

Reconstruct current task context from available durable history and records. Use when resuming work or rebuilding context on a topic.

Convert lessons from a completed difficult task into structural improvements. Use after a long or unexpectedly painful workflow.

Configure potetos-for-everyone model roles and capability preferences for the current agent/runtime. Use during initial setup or routing changes.

Maintain a compact auditable decision trail during autonomous or high-stakes work. Use when the user will review decisions later.

Fan out independent slices or coverage partitions and aggregate them with owner verification. Use for large audits, races, and parallel work.

Write a minimal failing test before implementation, make it pass with the simplest code, and refactor cleanly. Use when implementing bug fixes or features with clear verification targets.

Teach a subsystem or change so the reader can reason about it, combining how and why evidence. Use for real understanding rather than summary.

Write maintainable technical docs, RFCs, READMEs, PR descriptions, and commit messages. Use for durable engineering prose.

Apply disciplined TypeScript modeling and boundary parsing. Use when reading or editing TypeScript.

Cut AI tells, filler prose, superficial -ing phrases, and bloated commentary from writing and code. Use for all written deliverables and code cleanup.

Recover why a system or decision exists by triangulating source history and connected evidence. Use for rationale archaeology and historical questions.