How to Make Your AI Coding Agent Prove Its Work

Your AI agent says "Done." The build is green. The tests pass.

Did it actually work? Did it do the correct thing?

Most of the time, you only find out when you check it yourself. That makes you the verifier for every task, and the agent is only as fast as your review.

I spent the last few weeks with pstack, a plugin by Lauren Tan (poteto) that changes this. I turned the official guide into a 19-minute video and 24 Shorts. In this post, I will teach you the core habit, show you the prompts that make it work, and point you to the part of the video for each topic.

TL;DR

If you remember one thing: give the agent a goal and a way to check it.

/poteto-mode the export writes duplicate rows when a retry lands mid-run. repro first, then fix and verify.

1. Install pstack and run /setup-pstack. Say yes when it offers a verification skill.
2. Write prompts that can fail. A goal, a done check, and the proof you want to see.
3. Steer with principle names. "apply prove it works" redirects the agent better than a paragraph.

The Problem

Here is a prompt most of us have typed:

fix the export bug

Can you spot what's wrong?

There is no way to know when it is done. The agent will change some code, run the build, and report success. A green build proves the code compiles. It does not prove the export stopped writing duplicate rows.

So you open the app, run the export, and count rows yourself. Every task ends with you checking by hand.

The scary part is that this gets worse as agents get faster. More output with no proof only means more unchecked work for you.

The Solution

pstack is a set of skills, playbooks, and principles for AI coding agents. It started in Cursor, and it now installs in Claude Code too.

The entry point is one command, /poteto-mode. You give it a goal. It matches one of 23 playbooks, copies that playbook's steps into a todo list, and calls the other skills as each step needs them:

your prompt
└── /poteto-mode
    ├── question           → Investigation ─┐
    ├── defect             → Bug fix        ├─→ verify and show evidence
    ├── new behavior       → Feature        │
    ├── structure only     → Refactoring    │
    └── measured slowness  → Perf issue    ─┘

Notice how every route ends in the same place. The reply carries the evidence: the commands run, their output, the stored value, the row count. You read proof instead of producing it.

Now the bad prompt becomes this:

/poteto-mode the csv export drops its last row since yesterday's deploy. failing job id is 4812. repro first, then fix. done means the 60k-row fixture exports every row. show me the row counts before and after.

It is longer, but every part does work. And once the conversation has context, your follow-ups shrink to continue or keep going until done.

Here is the full walkthrough, from setup to overnight runs:

How to Use It

1) Install and pick your models

In Cursor:

/add-plugin pstack
/setup-pstack

In Claude Code, add the marketplace, install, and then every pstack command takes a pstack: prefix:

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

/setup-pstack detects your models, asks for a reasoning budget, and writes a small rule file every skill reads. At the end it offers to create a verification skill for your project. Say yes.

Important: The verification skill is the part that pays off the most. An agent that can drive your app checks its own work and keeps going until the check passes. An agent that can't hands every result back to you.

In the video: setup at 0:26, the verification skill at 10:33.

2) Write a prompt that can pass or fail

A useful prompt carries up to five things:

• The goal. What is wrong, or what you want.
• The done check. It must be able to fail. "Make it better" is not a check.
• The proof you want. Command output, a video of the flow, a before and after number.
• What you already know. A log line, a job id, a repro step.
• The real constraints. "repro first", "zero behavior change", "don't change any code yet".

Leave out two things: the how, and your theory of the cause. A stated guess narrows the search to wherever you pointed. Let the agent restate the problem first:

/poteto-mode read this thread. restate the underlying issue in your own words, in plain english. don't change any code yet.

A misreading shows up in the restatement, before any code exists. In the video: writing a good prompt at 2:39.

3) Steer with principle names

pstack ships 24 principles. You never call them directly. /poteto-mode reads them on every multi-step task, and you use their names to redirect the agent mid-task:

apply prove it works. run the real import flow and show me the written records.

use subtract before you add. delete the obsolete adapters first, then design what's left.

One name points at a full rule the agent already read. That is why a single line is enough.

This is what the 24 Shorts are for. Each one is about 80 seconds: the rule, a small example, and how to tell if the agent applied it. Good ones to start with:

• #17 Prove It Works: check the real thing, not a proxy, a self report, or "it compiles".
• #18 Fix Root Causes: trace the problem to its cause and fix it there.
• #1 Laziness Protocol: the most result with the least code and complexity.
• #22 Guard the Context Window: every token in the session should be worth its cost.
• #24 Encode Lessons in Structure: turn a repeated correction into a tool, a check, or a lint.

All 24 are in one playlist.

4) Leave it running overnight

This is the payoff. An agent that verifies its own work is an agent you can leave alone with a hard task. The handoff does not need to be long:

/poteto-mode im going to bed. migrate every caller to the new parser in a fresh worktree off main.
done means zero old callers, all parser fixtures pass, old api deleted.
keep a decision log. don't ask me before committing.
/loop until done. if you're truly stuck after a few hours, stop and write up why.

Each line buys you something:

1. "im going to bed" tells the agent to stop asking and keep going.
2. "done means..." gives every loop iteration a check it can run.
3. "fresh worktree" keeps it away from anything else you have open.
4. "keep a decision log" gives you something to audit in the morning.
5. The escape hatch lets it stop at a real dead end instead of reinterpreting the goal for eight hours.

Caveat: A loop you don't trust only produces unchecked work faster. Do the task once while you watch, and get the verification skill working, before you walk away.

In the video: the overnight chapters start at 11:51.

Tradeoffs

pstack is not free. Here is what you pay.

Pros

• Replies carry evidence, so you review proof instead of re-running everything.
• Short prompts work, because the playbook holds the structure.
• Principle names give you a precise way to correct a drifting agent.
• Safe long runs become possible once verification works.

Cons

• More tokens. Subagents and review panels cost money. /setup-pstack lets you pick a smaller budget or cheaper models.
• Slower on small edits. A one-line change does not need a playbook. Save /poteto-mode for work that needs rigor.
• Setup work. The verification skill needs a way to drive your app, and that takes a first run to get right.

Best Practices

1. Don't list skills in the prompt. "use /how then /architect then /arena" fights the order the playbook already has. State the goal; name a skill only to override a default.
2. Never accept a green build as proof. Ask for the real command, flow, or stored value.
3. Ask for prototypes before you pick a design. The first design is only the first shape the model thought of.
4. One worktree per parallel agent. Otherwise they overwrite each other.
5. Vet numbers before you share them. A warm cache can fake a speedup; run /benchmark-checklist.
6. Fix the repo, not the chat. /correct turns a repeated mistake into a check, so the next run can't repeat it.

The video ends with 6 common mistakes at 18:10, if you want them in under a minute.

Conclusion

pstack does not make the model smarter. It changes what "done" means. A goal plus a way to check it is the whole idea, and everything else in the plugin builds on that.

Start with one real, small task:

/poteto-mode add a --json flag to this command. text output stays byte-identical. verify both.

Then watch the full guide for the rest: understanding code with /how and /why, comparing designs with /arena, landing a stack of PRs, and building your own mode.

pstack was created by Lauren Tan (poteto). My videos are an unofficial explainer based on the official guide; they are not made by or affiliated with Cursor. I drafted this post with help from an AI agent and reviewed it myself.

If you made it this far, thank you for reading. What evidence do you ask your coding agent for before you trust a change?