Install This Before You Write Your First Prompt
The ten minutes before your first prompt decide the next six months
Codalio Blueprint is live: a free, MIT-licensed plugin that adds six planning skills to Claude Code, Cursor, Codex, Antigravity and Gemini. You install it before you generate any code, because the ten minutes before your first prompt decide whether you're building a product or a rebuild.
Most founders start the other way around. You open the editor, describe the app you've been carrying around in your head for a year, and watch something appear. It works. It's genuinely impressive. And it's built on top of every assumption you didn't know you were making — about who the user is, what "done" means, which of your twelve features actually belongs in v1, and whether the data model survives contact with a second customer.
Nothing in that workflow ever asks. The model is optimized to produce, not to interrogate. So the interrogation has to happen somewhere else, before the first prompt, and until now it happened in a Google Doc you never opened again.
Why vibe coding ships prototypes but not products
The generation tools are not the problem. Lovable, Replit, Cursor and the rest are extraordinary at turning a description into running code, and if your goal is a demo by Friday they are the right call. The gap is upstream of all of them: they take your description at face value.
A description isn't a spec. A description says "users can invite their team." A spec says who can invite, what happens to a pending invite when the inviter's seat is revoked, whether invited users see historical data, and how you'll know the feature is finished. Every question you don't answer before the first prompt gets answered anyway — silently, by the model, in code you'll pay to unwind later.
That's the rebuild cycle. Not a dramatic failure, just a slow one: the prototype works, you show it to customers, customers ask for the thing that was never scoped, and the architecture that was fine for a demo starts costing you weeks per change. Vibe coding ships prototypes. Spec-driven ships products.
Blueprint's bet is that the fix belongs in the editor, not in a separate planning tool you have to remember to open. The planning has to live where the building lives, or it doesn't happen.
What the six Blueprint skills actually do
Six skills, each one a full conversation rather than a template fill. Every one of them stops at a review gate and waits for you before it writes anything — you approve the direction, then it produces the document. That pause is the whole point: it's the moment the assumptions become visible while they're still cheap to change.
prd-builder — turns an idea into a defensible PRD
Takes a product idea and runs it through three lenses in sequence: product and scope, architecture-lite, and GTM-lite. Then it synthesizes one PRD instead of three disconnected documents. This is the entry point for anything new — a real requirements doc, written before a line of code exists, with the trade-offs stated rather than assumed.
mvp-checklist — forces the cut list you'd rather avoid
Scopes or re-scopes v1, and it goes further than a Now/Next/Later list in two specific ways. First, an explicit cut list: the features you are deliberately not building, named on the page. Most founders skip this section, because writing down what you're cutting feels like admitting the product is smaller than the pitch — but an unwritten cut list isn't a cut list, it's scope creep with a delay timer. Second, v1 done-criteria written as checkable facts, not "feels done." A criterion you can't test is a criterion that will be argued about at 11pm the week you meant to launch.
gtm-plan — channels, pricing, and a launch sequence
The GTM section inside prd-builder is deliberately light. This is the deep version: which channels, at what price, in what phased order. Run it once scope is fixed, so the launch plan is built on the product you're actually shipping.
arch-evaluation — reads your code, not your README
Assesses an existing codebase against a set of requirements — will this scale to that customer, is it ready for that contract, where is the debt that matters. The distinction that makes it useful: it reads the actual code. READMEs describe the architecture someone intended eighteen months ago. The repository describes the one you have.
code-to-prd — documents what you already built
The reverse direction. If you've been building for months without a spec, this reconstructs a PRD from the codebase. Critically, where it has to infer intent, it flags the inference as an open question rather than quietly guessing. You end up with a document that separates what the code provably does from what someone has to decide.
doc-generation — turns the approved PRD into working docs
Once a PRD is approved, this generates what comes next: a backlog, an API contract sketch, an onboarding doc. It requires an existing PRD by design — downstream documents inherit whatever rigor the PRD has, so there's no shortcut around writing that one first.
How to run Blueprint on Monday morning
Install steps are in the repo README — it's MIT licensed, and there's a full walkthrough here:
https://www.youtube.com/watch?v=7ntt2WXz7xE
Then run the skills in order, because the order is doing real work. For a new project: prd-builder first, then mvp-checklist to cut it down, then doc-generation to produce the backlog, then gtm-plan once scope is locked. For an existing codebase: code-to-prd first to establish what exists, then arch-evaluation against where you're going, then mvp-checklist on what's left.
Running them out of order doesn't break anything — it just wastes them. A GTM plan written before scope is cut is a plan for a product you're about to change. A backlog generated from an unreviewed PRD inherits every unexamined assumption in it. The sequence is the value; the documents are the output.
At each review gate, actually read what it's about to write. The skill stops and waits precisely so you can catch the assumption you didn't realize you'd made. If you're not sure what good output looks like, the sample PRD in the repo's examples/ folder is the reference.
Blueprint is free and it stays free. If you want the same discipline applied end to end — idea through PRD through working prototype, with a team that has done it before — that's what codalio.com is for. Codalio is the only AI platform that takes non-technical founders from idea to PRD to working prototype — without the rebuild cycles that come from skipping the spec.
Start with the spec, not the prompt
If you're two weeks from opening an editor and describing your product to a model, the highest-leverage thing you can do is spend an afternoon on the six documents that describe what you're actually building.
Try Codalio before you start building — install Blueprint from the repo, run prd-builder on the idea you've been sitting on, and see what a real PRD says about it before the code locks anything in. You'll walk away knowing what's in v1 and, more usefully, what isn't.
Full details and install instructions are at codalio.com/blueprint.
References
-
Codalio Blueprint repo (MIT) — github.com/codalio/codalio-blueprint
-
Blueprint landing page — codalio.com/blueprint
-
Walkthrough video — youtube.com/watch?v=7ntt2WXz7xE
-
Sample PRD —
examples/in the Blueprint repo