plugins

There's a moment every developer who works with agents reaches, usually without noticing. The agent is writing faster than you can read, and one afternoon you merge something you skimmed. Nothing breaks. So you skim the next one too. From then on you are trusting the code, or pretending to, and most of us can't say which.

This week's star is one engineer's answer to that moment, and it's the most honest one we've read. It came with a second answer from Anthropic, published the same week, that we didn't expect to rhyme with it so closely. Together they say something we think matters more than either does alone.

The record so far

The repo on the board is Cursor's plugin collection, so these are its numbers: on the monthly board all week, the weekly board four days, and onto the daily board twice at the very end, #9 on Friday and #4 on Sunday. But nobody starred it for the collection. They starred it for one folder inside, called pstack.

What pstack is

pstack is the personal toolkit of Lauren Tan, known online as poteto. She is on React's core team, works on the React Compiler, and writes code at Cursor. She has said she landed about two thousand pull requests in a month. Nobody reads two thousand pull requests. pstack is what she built so she wouldn't have to, and so she could still trust them.

It isn't a framework, and there's almost no code in it. It's a set of instructions for your agent, written the way a demanding senior engineer would brief a new hire. One entry point, /poteto-mode, reads your request and matches it to one of twenty-three playbooks: bug fix, feature, refactor, perf, shipping, an overnight run. The playbook's steps are copied into the agent's todo list word for word, so the agent can't quietly skip one. A step it decides not to do stays on the list with a reason.

Underneath sit twenty-four principles, each a page long. "Bias toward deletion and the smallest change that solves the problem." "Verify against the real artifact, not a proxy." "Encode the rule as a lint, metadata flag, runtime check, or script instead of more text." The agent has to say which principles shaped its decisions, which turns out to be a cheap way of checking it read them.

The part we found most original is the review. pstack doesn't ask one model whether the code is good. It sends the same change to reviewers running on different models and treats their agreement as the signal. For a hard design it goes further: several models attempt the same task in parallel, a judge from another model family scores them, and the best parts of the losers are grafted onto the winner.

Getting started

In Cursor, it's one command:

/add-plugin pstack

In Claude Code, add the marketplace and install it:

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

Then run /setup-pstack once. It asks which models you have and writes a small rule that maps each role to one: code, judgment, the review panel. After that, start any task that needs care with /poteto-mode (in Claude Code, /pstack:poteto-mode) and describe it the way you'd describe it to a colleague: "this scroll drifts every 750ms even when idle, reproduce it first, then fix and verify." If you don't know which skill fits, /poteto-help asks you what you're trying to do and hands you a prompt. The guide in the repo walks a first real task end to end.

Two notes from our own use. We ran it as shipped in a throwaway project, and we couldn't afford to run it fully. Almost every step spawns subagents, often several per model, and each round of fixes gets a fresh one. It's built for someone at Cursor's scale, and the bill shows it. And in Claude Code the cross-model review mostly collapses to a single model, because it can only spawn Claude. You keep the discipline but lose the disagreement, which is half the point.

The shape behind it

The tools are the visible part. The idea underneath is in a post she wrote to go with them, and it's the best thing we read this week. It's a triangle standing on its point, titled "whenever you correct your agent".

The wide top is the codebase itself: better architecture, stronger types, clear boundaries. Agents, she writes, "love to copy what exists and take the shortest path, so make the easy thing the right thing." Below that is static analysis: lint rules, tests, CI. Then prose: rules files, AGENTS.md, skills, anything that needs the agent's judgment. "Use it minimally." At the point is human review, the thing that scales worst, best spent on "designing an environment where agents do the right thing by default."

Read that and then look at pstack again, and something interesting happens. pstack is almost entirely prose. It lives in the third layer, the one she tells you to use least. We don't think that's a contradiction. We think it's the key to reading it.

Someone else drew the same shape

On the Thursday of the same week, Anthropic published how the Claude Code team does code review. Claude writes about ninety percent of Claude Code, and the volume they describe makes two thousand pull requests a month look quiet. We read it expecting a different philosophy. We found the same one.

They make the agent show its output "instead of saying it's done". They have code checked by agents that didn't write it, and let a finding through only when enough of them agree it's real. When the reviewer keeps flagging the same thing, "we fix it at the source", in a lint rule, a skill or the project's instruction file. They keep people for the decisions machines are bad at, and say flatly that "an agent's approval never counts as a person's."

Neither copied the other. Two teams under the same pressure, at very different sizes, arrived at the same habits. In a field this young, that's about as close to evidence as we get.

And Anthropic is unusually candid about the cost. "Review has to converge," they write. One pull request went through more than fifty rounds of agent review and agent fixes overnight, and most of what the reviewer kept flagging had been there since its first pass. "We made it worse ourselves," by running several rounds by default. They now stop at three.

Take the shape, not the size

Here is where we land. What the pioneers have published aren't recommendations. They are records of what trust cost at their volume. Lauren Tan can afford a panel of models on every change because of what two thousand pull requests a month would cost her without one. Anthropic needed a round cap because it learned the price of not having one. Copy their settings and you'll overpay. Copy none of it and you shouldn't trust what your agent ships.

What you can copy is the order. Prose costs you on every run, in tokens and in the agent's attention. A type or a lint rule costs you once. pstack's best tools point upward: /correct mines your past corrections and fixes each "at the highest level that works (architecture, then types, lint, and ci, then tests, with docs last)", and /create-verification-skill builds a scripted way to check your app. Used like that, pstack is a contractor that helps you build the top of your own pyramid, not a tenant that lives in the third layer and charges rent.

So read it the way you'd read a senior colleague's notes. Take the principles that fit your project. Take the habit of making the agent prove its work, in whatever form proof takes for you. Decide how much review you'll pay for before you start, not after the fiftieth round. Then make all of it yours, which mostly means making it smaller.

Nobody has the finished shape yet. Anthropic lists what it still lacks, and pstack is at version 0.15 with seven commits on Sunday alone. That's why the most interesting repo of the week is a set of opinions rather than a framework. Everyone is still working out how to work with these things, the pioneers included.

What it means on Monday

Next time you correct your agent, stop before you type the correction and ask which layer it belongs to. If you've said it before, it probably doesn't belong in a message at all. It belongs in a type, a test, a lint rule, or the shape of the code, where the agent will do the right thing because the right thing is what's already there to copy.

Then install pstack somewhere you don't mind breaking, give it one real task, and watch how it steers. Keep what made you trust the result. Leave the rest.