pstack Explained: A Cursor Engineer's Agent Skill Pack

Most tools in the AI-assisted development space focus on getting agents to write more code. Yet pstack, an open-source Agent Skills package by engineer Lauren Tan (GitHub @poteto)—who has worked at Meta, Netflix, and Cursor—takes a very different direction.

pstack is part of Cursor’s official plugin repository, cursor/plugins, and is released under the MIT license. Lauren Tan states its purpose directly at the beginning of the project README:

these are the same skills i use everyday to ship high quality code at Cursor. this turns cursor into a real engineering team. the goal is not to maximize loc, in fact it’s the opposite. pstack helps you write less, but higher quality code.

Rather than simply accelerating code output, pstack encodes a senior engineer’s discipline, decision criteria, and defensive thinking into a set of plain-text rules that agents can follow rigorously.

What Is pstack? Its Purpose and Three Common Misconceptions

Before looking at pstack, three common misconceptions need clearing up:

• It is not a framework or library: The entire package consists of Markdown files (skills/<name>/SKILL.md and reference templates), with no executable dependencies. Agents such as Claude Code, Codex, Pi, and OpenCode can therefore read it directly.
• It is not an accelerator for maximizing lines of code: The author explicitly states, “throughput without quality is not a goal i aspire to. if you want to go fast, go deep first”. In pstack’s philosophy, quality comes before speed. Parallelism is a byproduct of thorough verification and earned trust.
• It ships no planning skills: The author distrusts upfront planning, arguing that “the best spec is code”. When planning is needed, poteto-mode’s built-in playbooks handle it as the work unfolds.

If pstack is just a collection of text files, with no planning layer, how does it connect engineering workflows, principles, and collaboration across models into a coherent system? The answer lies in its architecture.

System Architecture: Entry Point, Hierarchy, and Principles You Can Invoke by Name

As of October 2026, pstack contains 51 skills, 24 of which are behavioral principles. Connecting them are a single entry point, poteto-mode, and the 23 playbooks and model orchestration rules defined within it.

The Single Entry Point: poteto-mode

For everyday use, users need to remember just one command: /poteto-mode <task>. This is a sticky mode (marked mode: true in its YAML frontmatter) that remains active across conversation turns. Its core responsibilities include:

1. Routing to a playbook: Based on the task’s characteristics, it selects a suitable workflow from 23 predefined playbooks covering bug fixes, performance, refactoring, investigation, shipping, and more. It copies the standard steps into a to-do list and invokes the relevant skills as it proceeds. Playbooks define how the work is done; skills provide the expertise for each step.
2. Enforcing non-negotiables: It enforces core rules, such as establishing data structures before defining logic (“name the data shape first”), requiring an architecture review before changes that span functions, and applying unslop rules to all natural-language explanations and conversations.
3. Defining when to ask questions: If a question can be answered objectively by running code and observing its behavior, timing, output, or performance, the agent must experiment on its own instead of asking a human. Only product or preference decisions that cannot be resolved experimentally need human input.
4. Governing autonomy and interruptions: The agent proceeds autonomously with reversible actions, such as posting in a team channel, updating a ticket, or starting an eval. It pauses for confirmation only before irreversible writes, such as force-pushing a shared branch, deploying, deleting data, or messaging a customer.

Subagents and Collaboration Across Models

poteto-mode defines explicit orchestration rules: all subtasks run in the background, agents receive file paths instead of full text embedded in the conversation (following the guard-the-context-window principle), and each task is assigned the most suitable model.

In practice, the system separates tasks by complexity. Fast models handle trivial, mechanical code edits, while models with stronger reasoning handle architectural design that spans modules and judgment calls about written reasoning. The system also includes specialized roles, such as poteto-agent, a general-purpose subagent that follows the full principle index, and a read-only code comment reviewer.

Twenty-Four Behavioral Principles You Can Invoke by Name

pstack turns a senior engineer’s intuition into 24 standalone principles covering core thinking, system architecture, verification standards, and delegation discipline. Each principle lives in its own skill file. Agents read them when a task starts, and users can also invoke them by name in conversation to correct the agent’s behavior immediately:

• Minimal changes and questioning assumptions: Examples include laziness-protocol (favor deletion and minimal edits) and attack-the-premise (when multiple solutions hit the same obstacle, question their shared premise first).
• Domain structure and boundary protection: Examples include model-the-domain (express the domain through types and eliminate scattered conditionals) and migrate-callers-then-delete-legacy-apis (migrate callers in the same set of changes and delete the old APIs immediately, without leaving a fragile compatibility layer).
• Verification against actual artifacts: Examples include prove-it-works (verify the actual artifact, refusing proxies and self-reported claims as evidence) and test-behavior-not-implementation (“If the test would still pass when every imported function returns undefined, rewrite the assertions or delete the test”).
• Encoding lessons into the system: encode-lessons-in-structure—when you find yourself writing the same instruction a second time, encode it as lint, a type constraint, a runtime check, or a script, rather than adding more natural-language instructions.

Core Skills: Understanding, Parallel Work, Quality, and Verification

Four groups of skills stand out in pstack’s built-in library:

Understanding: how, why, and blast-radius

• /how: For architecture that spans files or involves significant complexity, it launches 2 to 4 read-only exploration subagents in parallel. A coordinating agent then produces an architectural explanation that reads like a walkthrough from a senior engineer.
• /why: It establishes code anchors through version-control history (git blame and git log), then uses external MCP tools to query multiple kinds of historical evidence—issues, documents, and communications—in parallel, tracing the tradeoffs behind design decisions.
• /blast-radius: It assesses the scope of a change’s impact. At its core is a five-level certainty ladder, progressing from a bare assertion to specific line references, walking through failure paths, writing scripts that invoke real code, and reproducing behavior in the execution environment. Agents must actively move from lower to higher levels and identify “the one fact it’s safe because of”, eliminating vague speculation.

Parallel Work: arena and swarm

Both use subagents to fan work out in parallel, but their purposes and adjudication mechanisms differ completely:

Quality: unslop and no-comments

• /unslop: It defines a checklist with stable rule numbers for removing verbal clutter. It filters out vague verbs, meaningless transitions, and stock phrasing to maintain high information density and precise meaning. These rules are mandatory for any prose, including technical documentation and the agent’s own responses.
• /no-comments: It dispatches a dedicated reviewer to remove comments that add no value and turn comments that express meaningful constraints into concrete code structures, such as types, runtime checks, or lint checks in CI.

Verification: create-verification-skill

/create-verification-skill is pstack’s most deeply developed asset. Its guiding purpose is to write a verification skill for the next agent, who has never seen the project.

Every generated verification skill contains six standard sections: Launch (explicit startup commands and readiness criteria), Doctor (read-only health checks to ensure testing starts from a healthy environment), Drive (actual selectors for interacting with the interface), Evidence (following real user paths and verifying side effects, without substituting self-reported claims for evidence), Cleanup (precise process cleanup to prevent leftover processes from contaminating the environment), and Helpers (any script the skill ships must be executable, with its invocation shown in the skill body).

Before delivery, the agent must use the skill itself to perform end-to-end verification, enforcing the discipline that a verification skill that has not been executed is a draft, not a deliverable.

Design Philosophy: Five Decisions That Shape pstack

1. Implemented entirely in Markdown: In the verification-skill-example README, the author writes, “A wiki is great for humans. Agents pay for every token they reread.” pstack has no clever runtime; all the intelligence is in the text. This both saves context and makes pstack portable.
2. A hierarchy of trust: From strongest to weakest, enforcement mechanisms rank as “architecture > static analysis / CI > lint / compiler > rules / skills”. Written rules are weakest because agents forget them, so pstack pushes requirements toward executable checks wherever possible. Examples include no-comments turning comments into types or lint checks, and the Doctor health checks in verification skills.
3. Strict separation between authors and verifiers: The agent responsible for verification is never the one that wrote the code. The judges in /arena and the reviewers in /interrogate, which puts a diff through multi-model adversarial review, also come from different model families. As the author puts it, “The adversarial signal comes from model diversity, not assigned personas”.
4. Redefining the human role: Humans shift from being a review bottleneck at every step to correcting course after the fact and arbitrating key decisions.
5. Continuous self-improvement: Through the reflect skill, debugging lessons are written back into the skill library, allowing the system to evolve through failures.

Practical Advice: A Gradual Adoption Path for Most Teams

You do not need to install the entire package at once. Teams looking to learn from pstack can introduce it gradually, in descending order of return on investment:

1. Adopt the standard verification skill structure: Create project-specific verification instructions for agents using the six sections: Launch, Doctor, Drive, Evidence, Cleanup, and Helpers.
2. Introduce the certainty ladder and the single fact that establishes safety: During code review, require agents to identify the verification level behind their conclusions and state the key evidence that makes the change safe.
3. Write contracts for unattended tasks (Overnight Contract): Specify four elements—the goal, falsifiable completion criteria, preauthorized permissions, and an escape hatch. Remember that “a duration is not a finish condition”: “run all night” is not a completion criterion.
4. Add core principles to project rules: Choose 3 to 5 principles you strongly agree with, such as laziness-protocol and prove-it-works, add them to AGENTS.md, and invoke them by name in everyday conversations.
5. Apply the unslop checklist: Use it to review both your own writing and the agent’s output.
6. Adopt the full package: Once the above practices are working smoothly, and your tools support subagents and background tasks, install the entire package and switch to poteto-mode.

The README’s introduction closes with a single sentence: “fork it. improve it. make it yours. PRs are welcome!” The most valuable way to read pstack is not as a checklist to follow item by item, but as a detailed example of how a senior engineer puts “what counts as done, what counts as safe, and what should be asked of a human” into words an agent can understand.