Cursor Engineer Open-Sources Pstack: A Six-Phase AI Coding Workflow Breakdown

Cursor engineer open-sources Pstack, splitting AI coding into a six-phase workflow of triggerable skills.
This article systematically breaks down Pstack, the AI coding workflow repository open-sourced by Cursor engineer Lauren Tan. Its core innovation is splitting the AI software development lifecycle into six phases—planning, design, building, testing, deployment, and maintenance—each made up of triggerable skills, with principles made into independent skills loaded on demand rather than stuffed into the system prompt to save tokens. The design phase uses a multi-model arena with interrogate to aggregate; the building phase emphasizes TDD, TypeScript discipline, and no comments/cleanup diff; testing covers end-to-end verification and multi-agent swarm; deployment covers the full PR chain; maintenance remains a blank. The article also distills two key principles: attack the premise and type system discipline.
Cursor Engineer Open-Sources Pstack: A Six-Phase AI Coding Workflow Breakdown
Lauren Tan, an engineer who holds three roles at once—principal engineer at SpaceX, member of the Cursor technical team, and Meta Staff Engineer—and who is also a React core team member, has recently open-sourced her complete AI coding knowledge system, workflow, and coding principles into a repository called Pstack. A Bilibili creator did a systematic breakdown of it, and this article, based on that video, walks through the six phases of the workflow, the key skills, and the engineering ideas worth borrowing.
Why Pstack Is Worth Attention
What makes Pstack special isn't that it's "yet another collection of AI coding prompts," but that it breaks the entire AI software development lifecycle into reusable skills and defines a trigger for each one. According to the Bilibili creator's analysis, Lauren Tan organizes skills into six phases: planning, design, building, testing, deployment, and maintenance—a clear departure from the old "single-point prompt" approach.
Another notable design choice: principles are not stuffed into the system prompt. Instead, they're split into standalone skills with an index table. The reason is that the system prompt is re-read with every message, so piling in a large set of principles both wastes tokens and may be irrelevant to the current task. This "load on demand" approach offers direct reference value for teams maintaining AI workflows long-term.
System prompt refers to the global instructions injected into the LLM at the start of a conversation, typically in effect throughout the session. Since the model's context window is limited and every inference re-reads all tokens in the window, stuffing many principled rules into the system prompt causes two problems: first, token cost accumulates with every turn of conversation; second, the model's attention is diluted by irrelevant rules, and it may actually ignore key instructions for the current task. Lazy loading turns these rules into retrievable, triggerable independent modules that are injected into context only when the relevant task is activated—an idea that runs parallel to modularization and dependency injection in software engineering.
Phase 1: Planning—Aimed at Existing Codebases
Pstack's planning phase clearly leans toward brownfield projects, i.e., engineering with existing code. The core workflow is "learn the code first": the how skill answers how the code works, the why skill explains why it was designed that way, and the teach skill merges the two. To break down a large task, you can use figure out and show me your work; the latter records decisions into a document or Markdown file.
The Bilibili creator offers a caveat: for an independent developer starting from scratch, he prefers the planning skills from Matt Pocock or the Superpower series, because Pstack's planning serves large-scale migrations and legacy refactoring rather than greenfield builds. This is a positioning difference worth stating honestly, not a judgment of better or worse.

Brownfield and greenfield are a pair of common metaphors in software engineering. Brownfield refers to projects with a large amount of existing code, historical baggage, and implicit constraints, where the first task of refactoring is to understand the existing system rather than design from scratch; greenfield refers to brand-new projects with few constraints and high design freedom. AI coding tools have very different capability requirements for the two: brownfield projects rely more on code comprehension, impact analysis, and incremental migration, while greenfield projects rely more on requirement decomposition and architectural decisions. Pstack placing the focus of its planning phase on brownfield scenarios actually corresponds to the portion of work that accounts for a higher share of real enterprise-grade engineering.
Phase 2: Design—Multiple Models Propose in Parallel
The design phase has only one workflow, "settle the code shape," but its implementation is quite interesting. The architect skill triggers an "arena" in which multiple different models (such as Opus, GPT, Grok, etc.) or multiple agents propose design solutions in parallel; then the interrogate skill acts as judge, evaluating the results and aggregating the strengths of each proposal into a unified report.
This contrasts sharply with most single-model approaches—we're used to having one model iterate repeatedly, whereas Pstack's idea is to trade breadth for quality first, then converge. Multi-model cross-validation here is not a gimmick but a safeguard against errors in design decisions.
Phase 3: Building—TDD, Type Discipline, and Removing the AI Smell
The building phase has two main threads. The first is test-driven development; Pstack's TDD skill and those of Matt Pocock and Superpower each have their own emphases, and the Bilibili creator did a dedicated comparison covering scenarios like quick bug fixes, new features, and strict team discipline. The second is a TypeScript best-practices skill, which is directly related to Lauren Tan's React background—the React ecosystem relies heavily on TypeScript, so this skill forces AI to produce code according to TS conventions.
A third thread that's easy to overlook but very practical: the cleanup diff skill. It compares the diff between the main branch and the current branch, cleans up "AI-smelling" code such as redundant comments, odd try-catch blocks, variables without types, and overly deep nesting, and ensures behavior is unchanged by running tests, finally giving a one-to-three sentence summary.

The accompanying no comments skill explains a common trap: AI sometimes reads comments instead of code. If a comment says a function returns A but the code actually returns B, AI may trust the comment. Removing comments is essentially reducing noise so the model faces the real code directly. This insight is especially useful for teams that are often bitten by "stale comments."
TDD's classic loop is red—green—refactor: first write a failing test (red), then write the minimum code to make the test pass (green), and finally refactor under the protection of tests. In the context of AI coding, the value of TDD is further amplified—test cases amount to giving the model an executable acceptance standard, turning "is the code correct" from a subjective judgment into an automatically verifiable objective signal. Running the tests once per code revision can significantly reduce hallucination and regression risk. The differences among TDD skills mainly lie in test granularity (unit/integration/end-to-end), whether writing tests first is enforced, and the repair strategy after failure.
Phase 4: Testing—From Unit Tests to End-to-End Verification
The testing phase has three workflows. The first, "prove the app works," relies on the create verification skill; its difference from TDD is that it targets end-to-end testing: it needs to spin up the environment, database, and server, simulate real user behavior, collect evidence, and finally tear down temporary resources. It also has a rule—one folder per feature, rather than cramming everything into a single directory.
Building on this, the swarm skill lets multiple agents (optionally using different models) each take charge of different pages or small modules, then aggregate into a report. The second workflow, "attack the diff," reuses the interrogate skill from the design phase, letting multiple models try to break the changes on the current branch.
There's also a rather dramatically named skill here: thermonuclear code quality review, which adds an even stricter layer of quality review on top of the regular review to see whether the code can be simplified further. The Bilibili creator thinks it's similar in spirit to his channel's ponytail skill.

Phases 5 and 6: Deployment and Maintenance
The deployment phase covers the complete path from opening a PR to merging: writing the PR in the team's style, the easy to review skill tidying the PR for review, babysit watching the PR throughout, fix merge complex handling merge conflicts, fetching PR comments, and fixing CI checks. The value of this skill set is that it brings "the trivial friction before merging" into the AI workflow as well.
The maintenance phase is a gap in Pstack—there's no skill to collect issues and feed them back into the planning phase. The Bilibili creator fills this in with his own super collect and similar solutions, indicating that this part still needs external tools to complete.
Always-Available Auxiliary Skills and Two Principles Worth Borrowing
Among the auxiliary skills, potato mode acts as a router: when you're unsure which skill to use, just describe the problem and it picks the right one. catch up and plain talk are especially useful when switching project context, quickly recapping prior progress.

On the principles side, the Bilibili creator singles out the two most valuable. The first is attack the premise: when AI repeatedly fixes the same bug and falls into a "fix—blocked—fix again" loop, you should stop and question the underlying assumptions, confirm whether the direction is right, rather than continuing to double down on the wrong path. The second is type system discipline: reject impossible states—for example, a payment cannot be both paid and pending at the same time—using type design to rule out such illegal combinations.
Key Takeaways
- Pstack splits AI coding into six phases—planning, design, building, testing, deployment, and maintenance—each composed of triggerable skills, with principles loaded on demand rather than stuffed into the system prompt.
- The design phase uses a multi-model arena to propose solutions in parallel and then interrogate to aggregate, a key design that distinguishes it from single-model iteration.
no commentsandcleanup difftarget the common failings of AI reading comments and writing redundant code, reducing noise so the model faces the real code directly.- The testing phase emphasizes end-to-end environment setup and multi-agent swarm division of labor, and reuses design-phase skills to aggressively verify changes.
- The maintenance phase is a blank area in Pstack and needs other tools to complete the loop.
FAQ
Is Pstack suitable for independent developers starting from scratch?
The planning phase leans toward refactoring existing projects; when building from scratch, the Bilibili creator suggests referring to the planning skills of Matt Pocock or Superpower.
Why does Pstack make principles into skills rather than the system prompt?
To avoid re-reading a large number of irrelevant rules with every message, saving tokens and ensuring relevance.
Does no comments cause code to lose necessary documentation?
Its goal is to eliminate comment noise that is inconsistent with the code or redundant, preventing AI from trusting stale comments and misjudging behavior.
One-line Summary
Cursor engineer open-sources Pstack, splitting AI coding into a six-phase workflow of triggerable skills.
Paragraph Summary
This article systematically breaks down Pstack, the AI coding workflow repository open-sourced by Cursor engineer Lauren Tan. Pstack's core innovation is splitting the AI software development lifecycle into six phases—planning, design, building, testing, deployment, and maintenance—each composed of triggerable skills, and making principles into independent skills loaded on demand rather than stuffed into the system prompt to save tokens. The design phase uses a multi-model arena to propose solutions in parallel with interrogate to judge and aggregate; the building phase emphasizes TDD and TypeScript discipline, using no comments and cleanup diff to eliminate the common failings of AI reading comments and writing redundant code; the testing phase covers end-to-end verification and multi-agent swarm division of labor; the deployment phase covers the full PR chain; the maintenance phase remains a blank to be filled by external tools. The article also distills two key principles: attack the premise and type system discipline.
Related articles

RAG Getting Started in Practice: From Principles to Building an Enterprise Knowledge Base
Bilibili RAG course highlights: from retrieval-augmented generation principles, document chunking and vectorization, to five accuracy factors and enterprise knowledge base boundaries, with fine-tuning vs RAG selection advice.

AI Model Selection Guide: DeepSeek vs. Qwen3 in Practice
How should AI developers choose models? Based on a Bilibili tutorial, this article breaks down the Function Calling differences between DeepSeek V3 and R1, Qwen3's programmatic thinking mode switching and agent capabilities, and outlines a multi-model learning path and practical selection logic.

Anchoring, Loss Aversion, and Nudges: 5 Psychological Tactics Retailers Use to Make You Spend
Behavioral economics reveals how retailers use anchoring, framing, loss aversion, and nudge theory to manipulate your spending decisions. This article breaks down 5 common psychological tactics and offers counterstrategies like slowing down decisions and setting your own anchors to see through the pricing design behind discounts.