Planning With Code: How pstack Drives Research and Architecture

In the second part of a series on working with coding agents, lauren explains how their skill pack pstack handles research and design. The post also explains why they have said they don't believe in planning, then clarifies that they do plan, but through code. The starting point is that agents fail mainly in two ways: they get an underspecified request, or they lack the context to do the work properly. So the first steps are about loading context. The author asks the agent to restate a bug report "in its own words" before touching code, so a misreading shows up early and the author's own assumptions don't steer it. A /teach skill draws on two others. /how traces how a subsystem runs, sending parallel explorer agents when the code spans several directories. /why looks for the reasons behind the code in Git history, PR review comments, tickets, design docs, Slack and monitoring tools. A /recall skill pulls context from earlier chat transcripts, so a fresh session can pick up where an older one stopped.

In this approach, the plan is something runnable. For shared packages the README or tutorial is written first, working backward to the implementation. The post calls this readme-driven development, and it gives the agent a concrete target to check its work against. Prototyping works the same way. When a UI interaction is in question, a prototyping playbook has the agent build two or three throwaway variants behind a simple switcher, then use the verification skill from Part 1 to drive each variant, take screenshots and measure timing or layout. The agent then answers its own design questions with evidence instead of waiting for a person.

Larger changes go through /architect. It grounds the problem with /how and /why, then runs several independent design attempts in parallel, often on different model families. Each attempt drafts call-site usage, type definitions and function signatures. A judge on a model different from the main agent scores the candidates against a rubric. The agent then fills in the chosen sketch, and the design is thrown away if implementation shows it is wrong. One sign the post treats as proof of a wrong design is needing escape hatches such as any types or forced casts. Abstract plans don't get adversarial review, because in the author's experience agents invent theoretical risks. When a written plan is wanted, a separate playbook turns an agreed design into small PRs, each with its own verification step. That playbook treats passing tests as insufficient until the code has actually been run, and the author usually deletes such plans when the work is done.