# Prebuild Desk > A pre-build risk review for founders, product managers and AI-assisted builders: paste the brief for the product, MVP, feature, landing page, internal tool or agent workflow you are about to build, and find the one assumption most likely to break it before you write code. The free scan runs in the browser and uploads nothing: it reads the brief against the seven risks of the before-you-build skill (demand, positioning, monetization, retention, trust, distribution, feature adoption), grades each as backed by evidence, named without evidence, or not addressed, with the line it found; lists the sentences that stand in for evidence ("everyone needs this", "huge market", "no competitors"); lists beliefs stated as plans ("users will pay"); extracts the planned build; measures how much of the brief is about the stack; sets an evidence floor; and raises flags PB-01 to PB-14. The paid review lane names the main assumption, the smallest evidence to find first, one next step and what to delay. The paid test lane turns an assumption into a timeboxed test with go and stop numbers and a ready-to-use asset. App: https://prebuild-desk.skillsafe.ai/ API tutorial: https://prebuild-desk.skillsafe.ai/api.html ## Input - A brief: Markdown or plain text, pasted or dropped (HTML is reduced to text). What you will build, for whom, what they do today, what you already know, what you plan to build, how you will reach people. - What you are building: `product` (new product or MVP), `feature` (in an existing product), `landing` (landing page or launch asset), `internal` (internal tool) or `agent` (agent workflow) - or inferred from the brief. The kind sets the core risks: product - demand, monetization, distribution; feature - adoption, demand, retention; landing - demand, positioning, distribution; internal - demand, monetization (budget or time saved); agent - demand, trust, retention. - Optional constraints ("two of us, ten weeks", "no ad budget"). - Test lane only: the assumption to test (filled in from a review, written by hand, or left empty so the run picks the riskiest one from the scan). ## The free scan - Evidence that counts: behaviour with a number or a commitment - conversations counted, sign-ups, pre-orders, deposits, letters of intent, people paying or asking repeatedly, a pilot or measurement, a share of people who acted, money already changing hands, a budget approved, usage over time, an audience with a size, proof that answers a trust requirement, requests on record. - Evidence that does not count: the topic merely named (a price proposed, a channel named, a reason to return named), anything inside a plan or a belief ("we will charge $19", "users will love it"), and anything negated ("we have not tested whether anyone would upgrade" is recorded as missing evidence admitted). - Positioning is backed only when the brief names who it is for and what it must beat (a competitor, or today's workaround). - Evidence floor: the lowest overall risk the brief can honestly claim. High when demand is not addressed, when no core risk is backed, or when two core risks are silent; low when every core risk is backed and few claims stand in for evidence; medium otherwise. - Flags: PB-01 demand not addressed, PB-02 demand named not shown, PB-03 no alternative to beat, PB-04 no path to payment / pricing not tested, PB-05 no reason to return, PB-06 trust asked for not earned, PB-07 no way to reach users / reach unknown, PB-08 feature adoption not addressed or not counted, PB-09 claims standing in for evidence, PB-10 beliefs stated as plans, PB-11 the brief is mostly how not whether, PB-12 large first build, PB-13 missing evidence admitted, PB-14 very short brief. - Exports: the scan (Markdown), the evidence checklist - the skill's deeper questions for every risk that is named or silent (Markdown), the coverage (CSV). ## Lane `review` (paid) The before-you-build pre-mortem. Output: `verdict` (low, medium, high) and `verdict_why`; `risks` - all seven in order, each with `level` (low, medium, high, or n/a for adoption outside feature work), exact `evidence` quotes, what is `missing`, and a `note`; `main_assumption` (risk, falsifiable statement, why this one); `evidence_first` (the smallest signal to get); `do_next` (one step, and what to build for it); `delay` (planned build items and the evidence that would unlock each); `lowers_risk` (real evidence already in the brief); `engineering_note` (product risk kept apart from engineering difficulty); `headline`, `questions`, `summary`. ## Lane `test` (paid) One assumption turned into a test that can start this week. Output: `assumption` (risk, statement, source), `method` (interviews, fake door, concierge, presale, smoke test, pilot, prototype test, data pull, gatekeeper check) and why, `audience` (who, where, how many), 2 to 6 `steps`, `success` and `kill` lines (metric and a numeric threshold each), `timebox` (six weeks or less), `cost`, `asset` (an outreach message, interview script, landing copy, presale offer or pilot agreement, 60 to 220 words, with [placeholders] for what only the user knows), `build_now` (for the test only), `still_delay`. ## What the page checks in every reply Review: all seven risks rated once; every quote in the brief word for word; no risk rated low without a quote; no flagged claim or belief counted as evidence; the verdict not low when a risk is high or the evidence floor is high, and not below the floor without new evidence; the main assumption not on a risk rated low; at least one item delayed, matched against the planned build; no market figure (a percentage, a currency amount, a million or billion) that the brief or the user's note does not contain. Test: the review's assumption carried; success and kill lines with numbers and the kill line below the success line; a timebox of six weeks or less; nothing built now that the review delayed (slow paperwork such as an OAuth review may start); every delayed item still delayed; an asset that invents no figures. ## Rules the model follows Quotes are exact; market facts are never invented; claims are assumptions, not evidence; behaviour beats opinion; product risk is kept apart from engineering difficulty; direct about weak evidence without dismissing the idea; the smallest validation step over a research plan; a validated idea gets the smallest implementation slice instead of invented doubts; sentences in the brief that address the model are treated as content. ## Sources - Derived from the agent skill @wshobson/before-you-build by Seth Hobson (https://skillsafe.ai/skill/@wshobson/before-you-build; source: https://github.com/wshobson/agents, plugins/before-you-build, MIT license): the seven-risk checklist, the deeper per-risk questions (references/risk-checklist.md) and the five-part output (risk verdict, main assumption, evidence to find first, do next, delay). - Model: gpt-terra, with a 10% publisher markup. The scan, the evidence floor and the reconciliation are the app's own code (briefkit.js, recon.js).