Plan Through Code A narrated lesson adapted from Lauren (@poteto), The Complete Guide to pstack Pt. 2. Source: https://x.com/poteto/article/2097732320606507506 This is an independent educational adaptation, not an official pstack production. Synthetic narration: Microsoft Andrew (edge-tts). Illustrative numbers and code are labelled on screen. Chapters and transcript 00:00:00 — A plan that proves nothing Here's a plan an agent just wrote for you. Forty steps, tidy headings, every edge case considered. It feels like progress. But look closer: not a single line of it has actually run. This lesson is about a different way to plan, where the plan is built out of evidence instead of prose. 00:00:20 — Where this comes from This lesson teaches The Complete Guide to pstack, Part Two, by Lauren, who posts as poteto. pstack is her personal set of agent skills, behind a workflow she says ships thousands of PRs a month. Part One argued that verification comes first. If an agent can't check its own work, you remain the bottleneck, babysitting it all day. Part Two asks the next question. Once verification works, how do you figure out what to build? 00:00:51 — The lesson in four moves We'll move through four stages. First, understand the problem. Then, specify the outcome. Next, explore the options with prototypes. And finally, execute, with proof at every step. Underneath all four sits verification. Keep it in mind as the floor everything else stands on. 00:01:14 — Two ways agents fail Frontier models are very capable coders. Even so, poteto keeps seeing two failure modes. First, the agent can't fully understand your intent, because the task is under-specified, or poorly specified. Second, it doesn't have enough context on how to do the work correctly. The two are related, and they share one fix: prime the agent's context window with high quality context before it starts. 00:01:44 — Supervising someone smarter Before agents, changing a system meant reading enough of it to build a mental model first. For a small fix, maybe hours. For refactoring the core, it could take months. Agents remove that barrier. They'll change code whether or not you understand it. What stays hard is keeping the code and the user experience high quality. So the skill becomes supervision. Tell the agent what you want to achieve, but leave it free to solve the problem in ways you might not have thought of. 00:02:14 — Ask it to restate the problem One of poteto's favorite techniques is the indirect prompt. Instead of telling the agent what you think is wrong, draw the problem out of it, in its own words. When someone reports an issue in Slack, she'll often write something like this: read this Slack thread, and restate in your own words, in plain English, what you think the underlying issue is. That does three things. First, it compresses a noisy conversation into a structured problem statement. Second, it lets you catch a misunderstanding, like a fixation on a red herring, before the agent writes any code. And third, you haven't led it down the wrong path with your own assumptions, which could be wrong, or could limit what the agent finds. 00:03:00 — /how and /why Next, build a mental model you can trust. Two pstack skills do the digging. /how traces runtime mechanics. It first sizes up the subsystem, and if it spans multiple directories or services, it spawns parallel explorer agents on fast, efficient models. /why investigates motivation and intent. Code tells you what happens. It rarely tells you why someone wrote it that way. So /why queries historical evidence in parallel: git history and PR review comments, Linear tickets, Notion design docs, Slack, Datadog monitors, Sentry errors, code lineage, and analytics events. 00:03:41 — /teach and /recall /teach builds on both. It calls /how and /why, then explains the result to you in an intuitive way. Use it whenever you need the agent's work to make sense to you. For example: teach me why you implemented it this way and not another way. What were the tradeoffs, and why? There's a bonus. Models often state things confidently without reading the code. Having to teach makes the agent gather the evidence first, so it helps the agent too. /recall solves a different problem. Long projects span many chats, and each new chat starts from zero. Your past transcripts are a gold mine of context, and /recall pulls them back in. 00:04:25 — Plan in code, not prose Once you understand the problem, how do you specify the solution? In poteto's opinion, most plan modes over-specify implementation details, and under-specify everything else. That's why the pstack readme cheekily says, I don't believe in planning. She does plan. She just plans through code. For shared code and packages, that means readme-driven development. Write the docs a user would read first, describe the API to a hypothetical user, then work backwards to the implementation. When she built Dune, her team's in-house client framework for desktop apps, she started by writing a tutorial for it, to feel what building an app with it would be like. 00:05:08 — One document, one job Her first agent-written draft was painful to read. It tried to be a tutorial, a how-to guide, an architectural explanation, and an API reference, all at once. So she sharpened her knife first, by writing a /technical-writing skill. It uses the Diátaxis framework, which splits documentation into four distinct modes. A tutorial teaches by doing: it leads a newcomer through steps to build something visible. A how-to guide gives an experienced user the steps to solve a specific, real problem. Reference is dry, complete and authoritative: APIs, machinery, configuration flags. And explanation discusses background, design choices, and tradeoffs. Together with /unslop, the docs come out readable. And a plan written this way gives the agent a concrete target to check its own work against. 00:06:08 — Prompts that compound pstack's skills compound in the design phase. Here's a three-part prompt from the article. Part one recalls the past week of virtualization work, and uses /how and /why to understand the current implementation. Part two uses that context, including the bugs it already fixed, to design a new engine that eliminates flicker and jitter entirely. And it starts by writing a tutorial for using it in a React app. Part three asks the agent to teach the design, and prove it's superior. That's where the verification skills from Part One earn their keep. The agent now sees the whole problem the way you do, not just a small slice. 00:06:50 — Measure a hundred times When planning, two mistakes are the most common. One: accepting the agent's first design. Two: overcooking the plan without any empirical evidence. Human teams iterated on design docs through several drafts. With agents you can skip that ceremony, and take measure twice, cut once to its limit, with parallel agents. 00:07:14 — Skills vs playbooks That's the job of the prototyping playbook. But first, what's a playbook? In pstack, playbooks aren't skills. They're reference files inside /poteto-mode, and each one captures a workflow she uses. They load only when the task needs them, to save tokens. As of version 0.15.0, there are twenty-three. You don't call them yourself. /poteto-mode uses them automatically, depending on the task: prototype a few options, fix this bug, eval this skill change. 00:07:46 — Prototyping is planning with code Here's a prompt that triggers it: prototype a few options for a feature request, use /control-app, and take videos or screenshots for me to choose from. For visual changes, the agent builds throwaway sketches, in your app or a scratch directory. When it's testing an interaction, it puts two or three variations behind a simple switcher. Then it drives each one with /control-app, the verification skill from Part One. It takes screenshots of each variant, and measures the actual timing or layout. Prototyping is planning, but with code. The agent answers its own questions with evidence instead of waiting for you, and it gets the chance to surprise you with an option you'd never have considered. 00:08:31 — /architect: five phases For bigger changes, poteto spends her own time on architecture and data structures, and lets agents fill in the implementation. The /architect skill gives that work five disciplined phases. Ground the problem. The agent runs /how and /why over the affected systems, to learn existing ownership and constraints. Sketch. In an architecture arena, independent runners, often from different model families, each draft a complete design package: how a caller would use it, the core types, public function signatures, and a short rationale. Cross-judge and synthesize. A judge running a different model from the main agent evaluates the candidates against a strict rubric, and the best ideas are combined into one design. Implement against the sketch. The agent replaces placeholder bodies with real logic, and if a function needs unexpected parameters or extra state, it surfaces the discrepancy. And scrap it when the design is wrong. If implementation proves the sketch was wrong, the agent throws it away and starts over. 00:09:41 — Evidence the design is wrong How do you know an architecture is wrong? Look for empirical proof in the code. One signal: the same workaround appearing across unrelated call sites. Another: types that need escape hatches, like any, or forced casts. Notice what poteto doesn't do: adversarially review abstract plans. Agents start hallucinating theoretical risks, and inventing complex edge cases to guard against problems that will never happen. So don't overcook plans while they're still abstract. Let the agent answer open questions itself, by prototyping and verifying its own work. 00:10:21 — Okay, but I really want a plan pstack has no planning skill, but it does ship a multi-phase planning playbook. poteto uses it after she's happy with a design, to turn it into a tactical execution plan. Every task in the plan is structured around proof. Tests alone aren't enough: a step counts as verified only when the agent has actually run the code and seen it work. A script validates the plan's structure and formatting. Once approved, it executes item by item, as small, self-contained, easily reviewed PRs. For really large projects, she may commit the plan temporarily so other agents know the work in progress, then delete it when done. Plans aren't worth keeping forever. 00:11:05 — Pick the workflow for the job Here's how the pieces fit together, in four prompts from the article. An ambiguous bug in production: investigate, and give me what we know, what data you used, and your best hypotheses. A new service boundary, like rate limiting for webhooks: /architect it first, answer open questions with prototypes, and let me review before proceeding. A big migration to StyleX: break it into small, verifiable PRs, each with visual regression tests and live verification, so the result is one hundred percent identical to the original, bugs included. And a bug reported on Slack: reproduce it with /control-app. If it reproduces on main, fix it, and show me a video as proof. Because /poteto-mode already pulls in most of these skills, much of the time you can simply say: /poteto-mode, do it. 00:12:00 — Check yourself Let's check your understanding. After each question, pause the video if you want to answer before I do. Question one. Why ask the agent to restate a bug report in its own words, instead of giving it your diagnosis? Because it compresses the noise into a clear problem, exposes misunderstandings early, and doesn't steer the agent with guesses that may be wrong. Question two. What's wrong with accepting the agent's first design? You never see the alternatives. Prototype several options, and let real evidence choose between them. Question three. In a pstack plan, when does a step count as verified? Only when the agent has actually run the code and seen it work. Passing tests alone isn't enough. 00:12:56 — Plan with evidence Plan mode is often a way to convince yourself the agent will do the right thing. But a long, abstract plan only gives you the illusion of progress. pstack instead combines thorough investigation, empirical evidence, and rigorous verification. Plan that way, and engineering with agents stops feeling like a gamble. It becomes predictable and repeatable. This lesson adapted Lauren's article, The Complete Guide to pstack, Part Two. Read the original for links to every skill. Thanks for watching.