The Fifty-Cent Check That Saves Fifteen Dollars

Somebody online packaged “use multiple agents to proof your PRDs, specs, and PRs” into a protocol with an acronym. People are passing the doc around. I went to find the actual thing to see if I could lift it into Freebo, and halfway through the hunt I realized I already had a cheaper, uglier version of it running. The acronym isn’t the point. The preflight is.

Here is the preflight.

The step everyone skips

When I ship a feature on Freebo, the lazy version of the flow is: hand a PRD to a team-of-agents command, go make coffee, come back to a diff. That works. It also costs around fifteen bucks of tokens per run, because a feature team spawns a database specialist, an API builder, a frontend builder, a type-sync agent, and a code reviewer, all swinging simultaneously.

What that fast path doesn’t do is catch the moments when the PRD itself is wrong. A missing table. A pricing rule that contradicts an existing invariant. A UI surface the spec forgot to wire to. If those slip in, five agents go spend fifteen dollars faithfully implementing the wrong thing, and I spend the rest of the afternoon unwinding it.

So I added one skill in front of the team: /plan-feature. It takes the PRD and produces a plan file. It does not write a single line of code.

What the fifty-cent check does

/plan-feature reads the PRD, re-reads two or three existing features in the codebase for shape, and writes a markdown plan at docs/plans/feature-<slug>.md. Required sections:

• A one-paragraph summary of what changes for the user
• A checklist of layers touched (DB, API, frontend, background jobs, shared types)
• A task breakdown table — one row per teammate task, with owner, dependency, and estimated tokens
• The files it expects to touch
• Risks and the test plan
• An estimated total cost

That’s it. Thirty seconds of my reading. One Haiku-class pass through the codebase. Call it fifty cents.

The reason it’s load-bearing is the /prd-review step inside it. Before /plan-feature writes anything, it validates the PRD has the required frontmatter blocks:

auth_preconditions:
ui_surfaces:
api_to_ui_wiring:
no_shortcut_rules:
docs_deliverables:

If any of those are missing, planning stops and the preflight prints the failure list. That’s not bureaucracy for its own sake — those five blocks are each the signature of a specific past failure mode. One of them exists because an earlier team run shipped a feature with no UI entry point. Beautiful backend, no way for a user to reach it. The frontmatter is a lesson tax, paid once per PRD.

The three-tier flow

The whole shape, cheapest step first:

The pattern reads obvious written down. It wasn’t obvious in practice. The first version of this flow was just step three — fire the team at the PRD and hope. Steps one, two, and four are scar tissue.

Why the acronym doesn’t matter

The protocol everyone’s forwarding online has a name and a diagram. Mine doesn’t. What matters is the shape:

1. A read-only preflight that validates the input before any writer touches a file
2. A planning step that produces an artifact a human can actually read
3. The expensive execution gated behind step two
4. A review layer specifically for the parts that cost real money if they’re wrong

The read-the-plan step is where the brain is. Not in the fan-out. The fan-out is just how you scale once the input is clean.

What I’m going to steal from the protocol

Enough of a tease. There is one thing from the online version I don’t have yet: a specific “spec-vs-PR” agent that reads a merged PR back against the original PRD and flags scope drift. Right now my review step reads the PR against the codebase; it doesn’t argue with the spec that spawned it. That’s a real gap, and probably the next skill I write.

But I’m not renaming anything. The expensive mistake was never “we didn’t call it LEAN.” The expensive mistake was wiring five writers to a bad PRD.

A fifty-cent check that someone actually reads beats a fifteen-dollar protocol everyone skips.