This document explains how to use short names for pstack's 24 principles to adjust an agent's judgment precisely, instead of writing long instructions. At the start of a multi-step task, /poteto-mode reads the principles index, applies those relevant to the work, and must explain which principle changed which decision. The point is not to memorize or invoke principles directly, but to steer work with the name of the principle matching a problem.

1. Steering Work With Principle Names

pstack provides its 24 principles as individual skills. When a user requests a multi-step task, /poteto-mode checks their index at the start and selects the principles the task triggers. Its final response must identify each applied principle and explain the specific design or execution decision that changed because of it.

Users do not need to "invoke" principles as separate commands. They use the names to steer the agent. Each name points to a complete rule the agent has already read, conveying intent more precisely than a long explanation.

"You do not invoke principles. You steer by their names."

For example, if an agent wants to add a new adapter alongside three existing ones, say:

"Subtract Before You Add. Delete the old adapters first, then design around what remains."

If it claims completion merely because the build succeeded, require verification of the actual user flow:

"Prove It Works. Run the real import flow and show the resulting records actually written."

If two parallel tasks want to write to the same branch, encourage removing sharing rather than adding a lock:

"Separate Before Serializing Shared State. Give each task its own worktree, without locks."

These are powerful because they represent concrete behavior rules rather than slogans. If an agent merely names a principle but cannot explain any changed decision, it is name-dropping, not applying the principle.

2. Core Design Principles: How Much to Build and When to Rethink

The first group concerns how much to implement and whether to preserve or redesign an existing approach. It focuses on reducing unnecessary complexity and choosing a design that fits the actual problem. 🧭

• Laziness Protocol: Prefer the smallest change needed to solve the problem, deleting functionality rather than adding it where possible.
• Foundational Thinking: Choose the core data structures before writing logic.
• Redesign from First Principles: Integrate new requirements naturally, as though they had existed from the beginning.
• Attack the Premise: Question the assumption shared by fixes that have failed twice or more. First investigate which actors have asymmetric conditions.
• Subtract Before You Add: Remove unnecessary and dead structures before building new functionality on top.
• Minimize Reader Load: Reduce the layers and hidden state a code reader must keep in mind.
• Outcome-Oriented Execution: Drive rewrites toward the target design rather than preserving temporary compatibility states indefinitely.
• Experience First: Prioritize actual user outcomes and experience over implementation convenience.
• Exhaust the Design Space: For unprecedented problems, compare two or three viable prototypes instead of rushing into one implementation.
• Build the Lever: Create scripts that perform work or prove its result so reviewers can rerun them. If an agent repeats the same manual work, have it create the needed tool or skill. Delegate consistently repeatable steps to scripts so agents can focus on judgment.

Build the Lever particularly emphasizes reproducibility and automation over one-off fixes. Preserve knowledge in tools anyone can rerun instead of having people or agents repeat identical manual processes.

3. Architecture Principles: Where State and Validation Belong

The second group addresses where structural responsibilities such as state, validation, types, and compatibility belong. The goal is to prevent scattered rules, invalid states, and unnecessary synchronization problems by design.

• Model the Domain: Put repeated rules into a shared structure or model rather than scattered conditionals.
• Boundary Discipline: Validate at input boundaries, then trust validated types internally.
• Type System Discipline: Design types so invalid states cannot be represented.
• Make Operations Idempotent: Ensure repeated retries reach the same final state.
• Migrate Callers Then Delete Legacy APIs: Move callers to the new API and delete the old API in one continuous effort.
• Separate Before Serializing Shared State: Before adding coordination, locks, or waiting, remove the sharing itself where possible.

The last principle is particularly relevant to parallel work. Do not automatically add locks or sequencing to resolve conflicts. First see whether tasks can avoid sharing the same resources.

"Separate Before Serializing Shared State."

4. Verification Principles: What Counts as Evidence?

The third group emphasizes that "tests passed" may be insufficient. Verify actual artifacts and user behavior, and explain measurements and error causes convincingly. ✅

• Prove It Works: Verify the actual artifact works, rather than relying on indirect indicators or proxy checks.
• Fix Root Causes: Reproduce and trace a problem to its cause before changing code.
• Sequence Work into Verifiable Units: Finish verification of each small unit before moving to the next.
• Test Behavior, Not Implementation: Run code as users call it and check specific expected values. Delete a test that would pass even if every import function returned undefined.
• Explain the Number: Before trusting or reporting a measurement, explain what limits it and whether it measures the wrong thing. /benchmark-checklist makes this concrete with seven questions answered from actual execution results.

These principles do not simply mean "write more tests." They ask whether actual usage results were checked, the real cause was found, and there is a basis for trusting the measurement.

"Validate the actual artifact. Do not validate a proxy."

5. Delegation Principles: Handling Parallel Work Safely

Parallel tasks and subagents require careful management of workload and conversation context. Two principles address this:

• Guard the Context Window: Delegate bulk reading to subagents and keep the key findings in the main conversation.
• Never Block on the Human: Proceed with reversible work while waiting for the user, and present results.

The first reserves limited main-conversation context for valuable judgment and decisions. The second says uncertainty need not halt all work: advance within reversible boundaries.

6. A Meta-Principle: Encode Repeated Lessons in Structure

The last principle addresses how to avoid relying solely on memory and attention for recurring advice.

• Encode Lessons in Structure: If the same advice has been repeated twice, turn it into a lint rule, check, or script. /correct applies this across a repository, and the "Make it yours" guide provides examples.

Rather than ending with "be more careful next time," change the development environment and workflow so the same mistake is harder to repeat. Use automated structure, not individual memory, to solve recurring problems.

7. The Best Way to Learn the Principles

The document advises against memorizing all 24 principles. Skim the list now, then return when an agent behaves poorly and ask which named principle could have prevented it.

"Do not memorize the list. Skim it now, and return when an agent does something one of these names could have prevented."

Connecting names to real situations gradually establishes a shared vocabulary that changes agent design, verification, and collaboration without long instructions. The next guide explains how to adapt this to your own project and environment.