PStack Deep Dive (Part 1): How a Cursor Plugin Turns Engineering Discipline into Executable Files

PStack Deep Dive series | Part 1 (this article) covers the methodological skeleton: the why, the three layers, the 24 principles, the 23 playbooks, and poteto-mode. Part 2 (PStack Deep Dive (Part 2): Two Agents, Five Special Designs, and How It Actually Lands) covers the executors and the field notes: the two agents, benny automation, the five genuinely unusual design choices, and what porting to OpenClaw and DeepSeek Harness looks like.

The One Question This Article Answers

Why can a Cursor Plugin written as plain text files make an AI agent's engineering output predictable and auditable?

The answer is not in the model. It is in turning a senior engineer's judgment into executable files. This article takes pstack's skeleton apart: which layers it is built from, what the 24 principles say, how the 23 playbooks cover everyday engineering, and how poteto-mode, the "operating system," wires it all together.

1 Why Yet Another Agent Methodology?

In an era of AI coding agent overflow, "agent methodology" is a worn-out phrase. Most projects in this space sell the same thing: more code, faster. pstack's author, Lauren Tan (poteto) — previously at Meta, Netflix, and Cursor, a React core team member who helps maintain React Compiler — diagnoses the problem bluntly: "there's a growing sense that ai writes too much slop code. i agree." (README.md). And the goal she states runs against the mainstream: "pstack helps you write less, but higher quality code." (README.md).

That is not a posture. The problem pstack actually solves is this: an agent's engineering judgment should not depend on improvising fresh in every conversation. Most agent tools bet quality on stronger models — the runtime wrapped around the model is called the harness, and readers new to the idea can start with What an Agent Harness Is: The Ordinary Program Wrapped Around the Model — while pstack bets quality on discipline being documented: "how a senior engineer decides" becomes 24 named principles, "how this class of task runs" becomes 23 playbooks, and an operating system called poteto-mode connects the two, forcing the agent to name, in its reply, the principles it relied on. Judgment gets documented; the documents get cited mechanically; the citations can be audited. That chain is what separates pstack from "a pile of beautifully written prompts."

The README has an exact phrase for what this buys you: "fearless parallelism" — parallelism only becomes truly safe when you can trust one agent to go deep and write verifiable code. This also explains why the methodology is so obsessive about detail: it is designed for multi-agent parallel runs and even unattended overnight sessions. Any link without verification, and parallelism just multiplies the error.

2 The Three Layers: One Diagram

pstack itself is a stack of plain text files (Agent Skills format, skills/<name>/SKILL.md; readers who want that format first can start with In-Depth Analysis of Addy Osmani's agent-skills Open Source Project), published as a Cursor plugin without depending on Cursor-proprietary machinery — if Cursor itself is new to you, start with What Is Cursor: The AI Coding Tool That Lives in Your Editor. The structure boils down to three layers plus two executors:

Layer	Contents	Role
Entry	poteto-mode	OS / router: task → match playbook → invoke skills per step, apply principles
Principles	24 principle-* skills	Answer "how to judge": when to suspect a premise, when to verify yourself, when not to wait
Playbooks	23 playbooks	Answer "how to execute": fixed steps for bug fix, perf, shipping, overnight runs
Support	how · why · architect · arena · swarm · interrogate · unslop · no-comments · tdd etc.	Understanding, adversarial design, cleanup, discipline
Executors	poteto-agent, comment-sicko	Delegated execution · radical comment review
Automation	benny	Slack triage → reproduce → bounded fix, unattended

The division of labor deserves spelling out. The principle layer owns judgment: when to suspect a premise, when to verify with your own hands, when not to wait for a human. The playbook layer owns execution: bug fix, perf, shipping, and overnight runs each have fixed steps. The support layer is the toolbox: how/why for understanding, architect/arena/swarm/interrogate for design and adversarial review, unslop/no-comments/tdd for cleanup and discipline. poteto-mode is the single entry point — the README is explicit: the other skills "are situational, and the mode skill uses them for you as needed" (README.md). The agents and automations extend the methodology to delegation and unattended scenarios.

3 The Principle Layer: 24 Named Principles

The 24 principles fall into five groups: ten Core, six Architecture, five Verification, two Delegation, one Meta (grouping per the Principles index in skills/poteto-mode/SKILL.md; full names in the appendix). Each principle is its own file with a consistent shape: a description stating "when to apply," then a body with reasoning and patterns. That "when to apply" design is the key — a principle is not a maxim, it is a trigger condition.

Three of them deserve a close read.

attack-the-premise (skills/principle-attack-the-premise/SKILL.md). Opens with: "When two or more fixes that share one premise have failed the same gate, suspect the premise, not the fixes." If two-plus fixes sharing one premise fail at the same gate, the thing to suspect is the premise, not the fixes. It even sets a hard stop: "Do not start the next fix before the premise is written down and tested." Write the premise down, test it directly, and only then may the next fix begin. This principle targets the most common AI agent failure mode head-on: the same move hits the wall three times, with different parameters each round. It also defines itself against redesign-from-first-principles: the latter rebuilds a design around a new requirement; the former questions one fact the current design assumes.

prove-it-works (skills/principle-prove-it-works/SKILL.md). The text: "Verify every task output by checking the real thing directly. Do not infer from proxies, self-reports, or 'it compiles.'" Verification must aim at the real artifact — run the feature, read the actual value, look at the diff — not at proxy signals. Two parts are unusually mature. First, the direction of suspicion is fixed in writing: "When verification fails, suspect the observation method before suspecting the system" — when verification fails, suspect how you measured before suspecting what you measured, so the agent does not "fix" a system that was merely mis-measured. Second, verification is required to become a re-runnable script: "The strongest proof is a deterministic script that re-runs the same comparison" — the strongest proof is a deterministic script that re-runs the same comparison, not a one-off eyeball check.

never-block-on-the-human (skills/principle-never-block-on-the-human/SKILL.md). The first sentence is a worldview: "The human supervises asynchronously. Agents must stay unblocked." The human is an asynchronous supervisor; the agent must stay unblocked. Its cost-benefit analysis is blunt: "a wrong decision usually costs less than blocking" — code changes are reversible and reviewable, so a wrong call usually costs less than waiting. The boundary is equally clear: irreversible actions (force-push, deleting production data, sending external messages) still need confirmation; product direction is set by humans, execution should not wait.

These three together are pstack's soul: suspect what deserves suspicion, prove what deserves proof, and keep moving on the rest.

The other twenty-one, read by group, form one complete decision chain. The Core group governs "how to act": laziness-protocol biases toward deletion and the smallest change; build-the-lever requires a tool before any non-trivial work — a codemod, a script, a generator — with the rationale stated in the principles index: "The tool is the artifact a reviewer can rerun" (skills/poteto-mode/SKILL.md) — the tool is the artifact a reviewer can re-run. The Architecture group governs "how to design": type-system-discipline makes illegal states unrepresentable; make-operations-idempotent requires operations to converge to the same end state across crashes and retries. The Verification group governs "how to finish": explain-the-number demands finding what limits a measured number before trusting it; fix-root-causes states "A guard is a fix only when the state it handles is legitimate" (skills/principle-fix-root-causes/SKILL.md) — a defensive check only counts as a fix when the state it handles is itself legitimate; otherwise it just masks the symptom. The Delegation group governs "how to multiply yourself": guard-the-context-window routes bulk work to subagents and keeps only summaries in the main thread. The Meta group has a single entry, encode-lessons-in-structure, worth stealing for any team: the second time you find yourself writing the same instruction, turn it into a lint, a metadata flag, a runtime check, or a script — not more prose.

4 The Playbook Layer: 23 Named Flows

poteto-mode ships 23 built-in playbooks (skills/poteto-mode/playbooks/). The repo itself lists them flat; the five-way grouping in the table below is this article's analysis, for easier comparison:

Group	Playbooks (file names)
Delivery / landing (8)	babysit · shipping · opening-a-pr · autonomous-run · autopilot-full · autopilot-stack · orchestrate · multi-phase-plan
Diagnosis (6)	investigation · bug-fix · perf-issue · hillclimb · runtime-forensics · trace-forensics
Design / build (4)	feature · refactoring · prototype · visual-parity
Collaboration / sessions (2)	session-pickup · pause-safely
Governance / meta (3)	authoring-a-skill · eval · worktree-cleanup

A few concrete uses per group.

Diagnosis. investigation (playbooks/investigation.md) comes first: it is the only mainstream flow positioned as strictly read-only; its output is a cited explanation or recommendation, not a code change; the reply format is fixed to the how skill's structure (Overview / Key Concepts / How It Works / Where Things Live / Gotchas), and it explicitly requires "Push back if the premise is wrong" — if the question itself is wrong, say so; do not force an answer. The README's example use: "/how do we cancel runs? do we have an n+1 when we look up every run to cancel?". bug-fix (playbooks/bug-fix.md) starts with reproducing it yourself: "Reproduce it yourself on the matching surface … even when a debug or instrumentation protocol says to ask the user to reproduce" — never push reproduction onto the user. Its iron rule is "Every shipped line traces to runtime evidence": every landed line must trace back to runtime evidence; the commit order is also prescribed — the failing repro precedes the fix in git history, so the reviewer sees red before green. hillclimb (playbooks/hillclimb.md) is sustained, scientific improvement of a single metric, with the discipline "one change, one measurement, keep or revert," a decision.tsv log, and even a stop condition requiring "a target with a floor on attempts" — to prevent quitting on one lucky early win.

Delivery. shipping (playbooks/shipping.md) opens with "Green is not safe." — an all-green CI is not safety. It requires every PR to be exercised by an independent verification agent, the way a user would, and states "Only a verdict from an agent that did not write the code counts," because authors verify against their own intent; the landing order must be bottom-up, landing only the "contiguous verified segment." autopilot-full drives a queue of independent PRs, each with one owner, to merged, with a root-side swarm re-verifying before every merge.

Design / build. prototype (playbooks/prototype.md) operationalizes never-block-on-the-human: at a "which option?" fork, if the answer can be observed by running something once, you are not allowed to ask a human — sketch it and let the result speak. visual-parity handles pixel-exact UI equivalence, common when migrating style systems.

Collaboration / sessions. session-pickup takes over a previous agent's in-flight work from a transcript, a cloud agent URL, or a pushed branch; pause-safely is its complement — suspending cleanly so work can resume, triggered for example when the context is about to be compacted. In practice: take over a half-finished artifact left by an overnight agent by rebuilding state from the transcript with session-pickup; pause-safely before you log off, so tomorrow picks up exactly where today stopped.

Governance. eval (playbooks/eval.md) tests "how does changing one SKILL.md affect agent behavior" — blinded. The methodology runs controlled experiments on its own changes. worktree-cleanup reclaims disk, behind safety gates throughout.

5 poteto-mode: An Operating System, Not a Skill

Read poteto-mode (roughly a thousand lines of rules in SKILL.md) to the end and you find it is not a skill but a small operating system. Four components:

Non-negotiables. A set of trigger rules hard-binding situations to skills or principles: any code starts with the data shape; anything crossing function boundaries goes through architect first; any text surface (including user-facing replies) passes unslop; no-comments before review; benchmark-checklist before reporting benchmark numbers; PR status requests always go through babysit. The first one matters most: "In your reply, name each principle that shaped a decision and the specific choice it changed. Cite only principles whose leaf SKILL.md you read this session." (skills/poteto-mode/SKILL.md) — name every principle that shaped a decision and the specific choice it changed, and cite only principles whose full text you actually read this session. That is the anti-"verbal citation" mechanism: no reading the file, no right to cite it.

Writing the reply. Short declarative sentences; one idea per sentence; em dashes banned throughout; no mid-sentence colons; "Frame impact for the consumer and the maintainer" — say what it means for the user and the maintainer before the implementation. And the constraint most lethal to AI output: "Every claim carries its evidence or its label in the same sentence. Measured, inferred, or guess." — every claim carries its evidence or its label in the same sentence: measured, inferred, or guessed. No dressing guesses up as conclusions, no handing the human a check you could have run yourself.

Autonomy. The default is "Just do it.": reversible work and external actions (team chat, ticket updates, starting an eval) proceed without asking. The hard boundary is one line: "Always pause" is reserved for irreversible writes — force-push to a shared branch, deploys, deleting data, customer-facing messages. The most interesting clause is the attitude: "No is an acceptable answer." — when invited to expand scope, honest judgment beats compliance: "candor over sycophancy." Agreement is not the default.

Subagents. Any subagent spawned inside a playbook uses the poteto-agent type; models are assigned by role: code delegation defaults to grok-4.7-xhigh-fast, while the hardest changes, prose, and judgment go to claude-opus-5-5-xhigh (the README says /setup-pstack can change this). One easily missed discipline: "Fresh subagents by default" — new work defaults to a new agent carrying the merged full context, reusing an old agent only when state is hard to move, because "Interrupt-chained resumes silently drop directives" — interrupt-chained resumes silently drop directives.

6 Hands-On: Thirty-ish Lines of Python to Enforce the "Named Principle" Discipline

poteto-mode's first Non-negotiable requires every decision to cite a principle by name. In the spirit of encode-lessons-in-structure, the discipline itself becomes a re-runnable script: check that every decision in an agent reply carries a registered principle name. The script below uses only the standard library, prints deterministic output, and can be re-run directly:

#!/usr/bin/env python3
"""pstack discipline checker: every decision must cite a named principle.

Models poteto-mode's first Non-negotiable:
"In your reply, name each principle that shaped a decision
 and the specific choice it changed."
"""
import re
import sys

# The 24 registered principles (matching pstack skills/principle-* file names)
PRINCIPLES = {
    "laziness-protocol", "foundational-thinking",
    "redesign-from-first-principles", "attack-the-premise",
    "subtract-before-you-add", "minimize-reader-load",
    "outcome-oriented-execution", "experience-first",
    "exhaust-the-design-space", "build-the-lever",
    "model-the-domain", "boundary-discipline",
    "type-system-discipline", "make-operations-idempotent",
    "migrate-callers-then-delete-legacy-apis",
    "separate-before-serializing-shared-state",
    "prove-it-works", "fix-root-causes",
    "sequence-verifiable-units", "test-behavior-not-implementation",
    "explain-the-number", "guard-the-context-window",
    "never-block-on-the-human", "encode-lessons-in-structure",
}

DECISION = re.compile(r"^Decision:\s*(.+)$", re.M)
CITED = re.compile(r"\[(?:principle:\s*)?([a-z0-9-]+)\]")

REPLY = """Decision: kept the fix to two lines instead of a new helper [principle: laziness-protocol]
Decision: wrote a repro script before touching the fix [prove-it-works]
Decision: wrote the premise down and tested it directly, after two fixes on the same assumption failed [attack-the-premise]
Decision: added a retry loop to be safe
Decision: rewrote the parser in one pass, it feels faster now [code-harder]
"""


def check(reply: str) -> int:
    problems = 0
    for i, m in enumerate(DECISION.finditer(reply), 1):
        text = m.group(1)
        cited = CITED.findall(text)
        if not cited:
            print(f"FAIL decision #{i}: no named principle -> {text[:48]}...")
            problems += 1
            continue
        for p in cited:
            if p not in PRINCIPLES:
                print(f"FAIL decision #{i}: cited unregistered principle '{p}'")
                problems += 1
            else:
                print(f"PASS decision #{i}: {p}")
    return problems


if __name__ == "__main__":
    src = open(sys.argv[1], encoding="utf-8").read() if len(sys.argv) > 1 else REPLY
    n = check(src)
    total = len(DECISION.findall(src))
    print(f"\n{total} decisions checked, {n} problem(s)")
    sys.exit(1 if n else 0)

Actual run (macOS, Python 3) prints the following — note that decision #4 carries no named principle and #5 cites the nonexistent code-harder; both get caught, and the script exits with code 1:

PASS decision #1: laziness-protocol
PASS decision #2: prove-it-works
PASS decision #3: attack-the-premise
FAIL decision #4: no named principle -> added a retry loop to be safe...
FAIL decision #5: cited unregistered principle 'code-harder'

5 decisions checked, 2 problem(s)

Wire a check like this into CI and you have the minimal closed loop of "judgment documented, documents cited mechanically, citations auditable": the agent can name the principle, and the machine can verify it did.

Appendix: All 24 Principles (Matching File Names)

Core (10): laziness-protocol · foundational-thinking · redesign-from-first-principles · attack-the-premise · subtract-before-you-add · minimize-reader-load · outcome-oriented-execution · experience-first · exhaust-the-design-space · build-the-lever

Architecture (6): model-the-domain · boundary-discipline · type-system-discipline · make-operations-idempotent · migrate-callers-then-delete-legacy-apis · separate-before-serializing-shared-state

Verification (5): prove-it-works · fix-root-causes · sequence-verifiable-units · test-behavior-not-implementation · explain-the-number

Delegation (2): guard-the-context-window · never-block-on-the-human

Meta (1): encode-lessons-in-structure

What's in Part 2

The methodological skeleton is done; Part 2 (PStack Deep Dive (Part 2): Two Agents, Five Special Designs, and How It Actually Lands) moves to the executors and the unusual parts:

• How poteto-agent and comment-sicko divide the work
• How benny turns a Slack issue into a reproducible fix
• The five genuinely special design choices (named principles, premise attack, prove-it-works, never-block, harness portability)
• Porting notes for OpenClaw and What Is DeepSeek Harness: The Open-Source Agent Runtime Where 'Everything Is a Plugin'
• The limits and criticisms of this methodology

Sources and Version

• The facts come primarily from the pstack/ directory of the cursor/plugins repo: README.md, skills/poteto-mode/SKILL.md, skills/principle-*/SKILL.md, and skills/poteto-mode/playbooks/. Quoted English is verbatim from those files.
• pstack was merged into cursor/plugins via PR #73 on 2026-05-23; this article is based on the version reviewed on 2026-10-21, with the 24 principles and 23 playbooks cross-checked line by line against the README.
• The five-way playbook grouping in section 4 is this article's analysis (the repo itself lists playbooks flat); the script in section 6 is an original demo for this article, and its output is from an actual run.