Pstack

lastmod 2026-11-03created 2026-11-032 edits

A collection of engineering skills that make agents prove their own work in Cursor and Claude Code

About

A plugin in which Lauren Tan (poteto) — a React core team member who has worked at Meta, Netflix, and Cursor and now works at SpaceX AI — publishes the skills, principles, playbooks, and subagents she uses every day
The goal is not code volume but writing "less, at higher quality". The position is that you must be able to trust one agent deeply before parallelization is safe
There is a single entry point, /poteto-mode. It matches a request to one of 23 playbooks and invokes the skills needed at each step
Provides 24 principles, each as a short skill (Prove It Works, Encode Lessons in Structure, Never Block on the Human, etc.)
No planning skill is provided by default. The position is that "the best spec is code"
Uses multiple models split by role. The defaults are Grok for code work and Claude Opus for judgment and writing work
MIT license

Video summary

The last problem of AI coding, and how a SpaceX lead engineer solved it | Lauren Tan × Matt Pocock
- The original conversation is Matt Pocock's live stream (2026-10). It covers how 2,000–2,500 PRs a month were merged with agents
- The mapping between chapters and skills was reconstructed based on the links in the video description

Time	Chapter	Method	Related skills
00:00	An AI dev team that works even while you sleep	Agents continue working, verifying, and merging even when no human is around
00:50	The cook tastes the dish themselves	The agent operates the real app like a user and leaves evidence	`create-verification-skill`
02:29	The kitchen prevents the same mistake	Turns recurring review comments into lint, types, and checks instead of documentation	`principle-encode-lessons-in-structure`
03:24	AI also takes and splits the orders	Work is split and delegated, and a separate verification agent must approve before merging	`poteto-mode`
04:57	How can you trust it without tasting everything?	Samples merged results and fixes problems in the environment	Operating habits
06:18	I set up my own kitchen	Builds your own skills from your own work history	`automate-me`, `grill-me`

Key concepts

Michelin kitchen: The head chef does not cook every dish personally but sets up the equipment, roles, and standards and is responsible for every dish that goes out. Set up the kitchen before adding more cooks
Trust ladder: Expand an agent's permissions only as far as it can prove itself
Two loops
- Outer loop: takes in new information from Slack, issues, etc. and turns it into work
- Inner loop: a coordinator splits and delegates work to agents, and the agents gather context themselves
Sampling instead of review: Sample merged PRs and look for recurring shortcuts and bad patterns. Fix the skills, rules, and environment, not the output
Verification agent: The agent that wrote a PR does not merge it on its own judgment. A fresh verification agent actually runs the app to check, then merges

Key skills

/poteto-mode - The entry point that matches work to a playbook, opens a to-do list, and invokes the needed skills. Always stops for irreversible actions (force-push to a shared branch, deployment, data deletion, customer messages)
/create-verification-skill - Generates a project-specific verification skill that runs and operates the app like a user and leaves evidence, along with a Feature Map
- Structure: Launch · Doctor (health check) · Drive (operate) · Evidence · Cleanup
- Hands over the generated skill only after running it end to end once to prove it
/maintain-verification-skill - Fixes a Feature Map that has drifted because the app changed
/create-formal-verification-skill - Formally verifies, with TLA+ etc., parts that tests have trouble reaching, such as races, retries, and state machines
/correct - Structures recurring mistakes in the order architecture → types → lint → tests → documentation
/interrogate - Multiple models try to break the diff, and only findings proven by execution are kept
/blast-radius - Finds what a change could break outside the diff and proves the safety rationale in code
/automate-me - Analyzes your own work history and creates a <name>-mode skill
/setup-pstack - Per-role model settings
Matt Pocock's skills introduced alongside
- grill-me - Refines plans and designs through a relentless interview
- grill-with-docs - Also records ADRs and a glossary while interviewing

Using with Claude Code

/plugin marketplace add cursor/plugins
/plugin install pstack@cursor-plugins
/pstack:setup-pstack

Commands get the pstack: prefix (e.g. /pstack:poteto-mode)
Model settings are saved in ~/.claude/rules/pstack-models.md
Because it is a third-party marketplace, auto-update is off by default. To update manually: claude plugin update pstack@cursor-plugins
The verification skill path is .claude/skills/ instead of .cursor/skills/
Steps that use Cursor Automations, Bugbot, or cloud agents are skipped (the Slack bug triage automation benny is unavailable)

Adoption plan: accounts.cvp.run

A plan made on 2026-11-02 to apply this method to accounts.cvp.run, a shared account service based on Cloudflare Workers, D1, Better Auth, and Paddle. At the time the repository had only a design document (docs/design.md) and migrations, with no implementation code or CI

Two things not to follow as-is

A verification skill can only be built if there is a runnable app. create-verification-skill itself says to fix that first in a repository that cannot build or run
Auto-merge applies only to some areas. In the conversation, Matt Pocock asked how irreversible changes are handled, and Lauren Tan gave no general answer. Authentication and payments are exactly that area

1. Setting the starting line

Commit the design document, migrations, and package.json to establish a baseline
Install pstack and keep auto-update off. This is so the working rules of the authentication repository don't change silently

2. Building the skeleton and checking risky assumptions

Complete design document §13 step 0 (empty Worker, D1·KV·Queue, migrations applied, vitest-pool-workers) first
Check two-step verification for social login first, using the Prototype playbook
- Better Auth 1.7.15's twoFactor plugin only intercepts /sign-in/email, /sign-in/username, and /sign-in/phone-number
- The databaseHooks.session.create.before approach written in the design is a still-unproven assumption
Back-channel logout has code in @better-auth/oauth-provider, but the actual behavior needs to be checked with a sample RP
Settle the open items in the design document with grill-with-docs. Since a design document already exists, the approach that leaves decision records is the right one

3. Verification skill verify-accounts

Generate .claude/skills/verify-accounts/ with /pstack:create-verification-skill
External boundaries are handled as follows

External boundary	Verification method
Turnstile	Cloudflare test keys
Email	A development sender stores the links and a script reads them
6 social logins	Fake OIDC provider. Real providers are checked manually in a remote environment
TOTP	A script computes the code from the secret
Passkey	Playwright virtual authenticator (needs to be added to `package.json`)
Paddle	Signed webhook replayer, then sandbox
OIDC apps·CLI	The sample RP Worker and sample CLI from design document §13

Evidence checks both the screen and the DB state. Looks down to the rows of admin_audit_log, account_event_outbox, and credit_ledger with wrangler d1 execute --local
First 5 items of the Feature Map
- Sign-up·sign-in
- OIDC sign-in·logout propagation
- Two-step verification·re-authentication
- Device grant·PAT
- Paddle webhook → plan·credits
Carry the per-step completion criteria of design document §13 over directly as verification scenarios
Also check with scenarios that what should be blocked is blocked (an addition not in the video)
- Reject tokens with another app's aud
- 401 for a revoked PAT
- Revoke the whole chain on refresh token reuse
- An unverified social email is not linked to an existing account

4. Turning the security checklist into structure

With rules that exist only as sentences, nothing fails if an agent skips them. Move them in the order architecture → types → lint → tests → documentation

Rule	Enforcement
Single `isAdmin` check	Forbid `role` comparisons outside that module via lint
Administrator writes must be audited	Only allow a route registration function where `audit` is a required argument
Credits are recorded only with `batch()`	Restrict ledger·balance writes to one module
PATs are issued only through a server wrapper	Forbid direct `createApiKey` calls via lint
FK `ON DELETE`, length CHECK	Schema check script after applying migrations
Better Auth schema matches	Compare against the `auth generate` output in CI
No cookie sharing between apps	Assert in E2E that `Set-Cookie` has no `Domain`
Internal RPC not exposed over HTTP	Route list snapshot test

Confirm once that each check fails on code that deliberately violates it
The mapping table of rules to enforcement lives in CLAUDE.md

5. Autonomy zones

The part that differs most from the video

Zone	Scope	Merge
A. Easy to revert	Screens, copy, i18n, documentation	Automatic when verification passes (`autopilot-full`)
B. Security boundary	Sign-in, sessions, tokens, two-step verification, social linking, OAuth, PAT, administrator checks, webhook signatures	Agent implements and verifies; a human reads and merges (`autopilot-stack`)
C. One-way	Production migrations·deployment, live payments, key rotation, deletion cron	A human runs it directly

Why a human reviews B: code can be reverted, but sessions and tokens stolen in the meantime cannot. Verifiability and reversibility are separate things
Zones are also enforced structurally: CODEOWNERS, branch protection, and production credentials are not kept in the agent environment
At first a human merges in all zones. Once required CI checks exist and sampling finds no problems, allow auto-merge starting with zone A
Concentrate heavy verification on B and C. In one comparison, using all of pstack took about twice the time and many more tokens

6. Implementation and operation

Proceed through design document §13 steps 1–7 with /pstack:poteto-mode
At the Paddle step, use create-formal-verification-skill to verify webhook reordering and credit idempotency (an addition not in the video)
Review the previous day's commits every day. A by sampling, B and C in full
When the same review comment comes up twice, don't just fix the output; reflect it in the structure with /pstack:correct
Run /pstack:automate-me after a few weeks of work history have accumulated

Caveats

The 2,000–2,500 PRs a month figure is self-reported, and there is analysis suggesting it includes many maintenance changes
The conversation gave no general answer for areas that are irreversible or hard to verify (data loss, etc.)
The video summary on this page was compiled not from subtitles but from the video chapters, the original skill documents linked in the description, and secondary summaries of the original conversation

Favorite site

author Zer0 sitemap