Skip to content

Verify the result and open a PR

"It compiles" is not evidence. The Prove It Works principle makes the agent check the real artifact before it reports success, and your job is to make "the real artifact" checkable. This page covers stating a finish condition, vetting a measured number, generating a verification skill for your app, opening the PR, and driving it to merged.

Verification is the slowest step in most agent work, because it's the step that usually waits on a human. Make the agent able to do it, and you stop being the bottleneck. Skip it, and running more agents only gets you more unchecked work to review.

A prototype plane flies a real test course while she times it with a stopwatch and robots film and checklist the run; the terminal reads verify: pass, evidence: captured.

State the finish condition up front

Put what done means in the first prompt, in whatever words fit:

/poteto-mode add json output to this command. text output stays byte-identical, the json parses, both run against the sample project. show me the evidence.

Now the agent has three checks it can run, not a mood to satisfy. When the reply comes back, it should carry the exact commands and outputs. If a check couldn't run, a good reply says "inconclusive", and you should treat a confident reply without evidence as a red flag.

Match the check to the change:

  • A CLI change runs the real command.
  • A UI change walks the changed flow in the running app. When it must match a reference pixel for pixel, the Visual parity playbook diffs screenshots against a frozen baseline instead of judging by eye.
  • A parser or migration replays a saved input.
  • A perf change compares before and after profiles.
  • A storage change reads back the written value.

Ask for the proof as an artifact you can inspect yourself: the failing test and then the passing one, a before-and-after video, the trace, the screenshot. If the fix already merged, ask for the same check again on main. An artifact beats a plausible explanation, because you can challenge it without replaying the whole run.

For a small diff you don't fully trust, /blast-radius finds what it could break elsewhere. It picks the one fact the change is safe because of and proves it by running code instead of writing an essay about it.

Vet a measured number with /benchmark-checklist

A before-and-after number is the easiest evidence to get wrong by accident. A warm cache, a debug build on one side, or work that never ran inside the timed region can each produce a convincing speedup. Before you report or act on a number, type:

/benchmark-checklist vet the export speedup before it goes in the pr

/benchmark-checklist asks seven questions and wants evidence from a run for each:

  1. What limits the number, and why isn't it double?
  2. Did every side run tuned the way production runs?
  3. Does the result break a physical limit, like disk bandwidth or core count?
  4. Did anything error or return wrong output?
  5. Does it reproduce over alternating runs, with a median and a range?
  6. Does it matter end to end, on the path a user waits on?
  7. Did the work actually happen inside the timed region?

The verdict comes back as faster, slower, no measurable difference, or inconclusive, with the run count, range, and limiter. It says inconclusive when it can't name the limiter or a side ran untuned. /poteto-mode already runs the checklist inside the Perf issue and Hillclimb playbooks, so you type it yourself when you measured something outside them, or when someone else's number looks too good. It's the working form of the Explain the Number principle.

Create a project verification skill

The UI bullet above hides a real requirement. The agent needs a scripted way to drive your app. If your project has one, great. If not, run:

/create-verification-skill

/create-verification-skill interviews the repository, not you. It works out what a user touches, how the app launches locally, what can drive it (an existing harness first, otherwise browser and CDP, a PTY, or plain HTTP), what evidence proves behavior, and whether two instances can run side by side. It asks you only what the code can't answer.

It writes .cursor/skills/verify-<app>/, agent-facing instructions with exact Launch, Doctor, Drive, Evidence, and Cleanup sections, plus a feature map under features/ that indexes what the app does and what result proves each feature works. The skill ships a worked feature-map example with a README index and one file per feature using the four required H2s. Before handing it over, the generator proves the skill once end to end: launch, doctor check, drive one feature, capture evidence, clean up. If that proof fails, don't use the output.

From then on, "verify it in the app" is a step any agent can execute, in this repo, with no setup conversation. Name it in the prompt when you want the proof in a specific form:

/poteto-mode build the bulk-archive action. use /verify-<app> to verify your changes and show me a video and screenshots as proof.

/poteto-mode repro this with /verify-<app>. if it repros on main, fix it and show me a video as proof.

Once the verify skill works, a /swarm can split a full pass by feature-map entry and aggregate the results. A swarm of verifiers also confirms a perf win over a big enough sample, or fuzzes the app for regressions before a PR ships.

Treat the verification skill as infrastructure, not a one-off. Commit it, so every person and every agent on the team drives the app the same way. Then build the lever. When agents keep writing throwaway scripts to click through the app, ask for a small control CLI that the skill calls instead. Agents spend fewer tokens, and every run becomes repeatable. A CLI that agents use well has these traits:

  • A few composable commands, each doing real work, rather than many thin ones.
  • A --dry-run option on anything destructive.
  • Subcommands that reveal features gradually instead of all at once.
  • Error messages that say what to do instead.
  • Rich --help text.
  • Machine-readable output, such as JSON.

While you're there, make the dev setup repeatable too: seeded data, test users, and one command that brings the environment up the same way every time.

Keep the verification skill honest

Apps change and feature maps rot. Run this at least once a day, ideally from a scheduled automation so nobody has to remember:

/maintain-verification-skill

/maintain-verification-skill audits the generated skill: one read-only source reader per feature in parallel, then one live pass that drives every mapped feature. It ends in exactly one of three outcomes. clean means full coverage and nothing to ship. changed means one PR of proven corrections, confined to the verification skill's own directory. blocked names the blocker. It never edits product code. If the live pass catches a product regression, it reports the regression instead of papering over it in docs.

Open the PR

/poteto-mode open the pr. small ordered commits, evidence in the description.

The Opening a PR playbook works from a worktree, rebases the work into small ordered commits, cleans the diff, unslops the prose, and returns the PR link. Five narrow PRs beat one fat one, and stacked follow-ups beat a growing branch.

Drive the PR to merge-ready with Babysit

An open PR starts collecting blockers immediately. Checks fail, reviewers comment, trunk moves. Hand that churn to the Babysit playbook:

/poteto-mode babysit this pr. get it green.

Babysit watches the PR with a bundled watcher and takes blockers in order: conflicts, then review threads, then CI. Every known fix batches into one push, so the checks restart once instead of after every fix. The comment triage is skeptical, because humans and bots file real catches and noise in the same list. A real finding gets a fix, and noise gets dismissed with the disproof posted on the thread. When all you want is status, ask smaller and Babysit answers without starting the loop:

/poteto-mode check on pr 123. anything outstanding?

Babysit stops at merge-ready. It never merges, even with everything green, because merging is a different decision.

Land the stack with Shipping

Green is not the same as safe. When you're ready to land, say so:

/poteto-mode land the stack.

The Shipping playbook verifies each PR independently before it arms anything. One fresh agent per PR proves the behavior live, and the agent that judges a change is never the one that wrote it. Then Shipping lands only the contiguous verified run from the bottom, one PR at a time through GitHub by default or Origin when its CLI is available, and reports the first PR that breaks the chain. A verified PR sitting above an unverified one waits, because merging it would pull the gap in underneath.

Next: Run work while you sleep.