Try it: /pm-skills:foundation-build-risk-review "Your context here"

Build Risk Review

Don’t build it yet. First name the one assumption most likely to make it fail.

foundation-build-risk-review is a fast, pre-commitment gate for product decisions. Given an idea, a feature request, or a scope change, it returns a Build Risk Review: the single biggest risk, the evidence behind it, a verdict, and a concrete no-code validation step, then routes you to the skill that does the next piece of work. It is a foundation hub: its job is to triage and dispatch, not to duplicate the deeper skills.

When to Use

A product idea, MVP, or new bet is about to turn into build work.
A feature request or scope change has arrived and you need to separate real demand from a polite ask, founder anxiety, or competitor-copying.
Someone wants a fast “should we build this?” verdict before a PRD, roadmap row, or ticket exists.

When NOT to Use

If the ask is	Use instead
A launched product’s pivot-or-persevere call, weighing usage or market data	`iterate-pivot-decision`
You have chosen the assumption and need to design the test	`define-hypothesis`
Framing a confirmed problem for the team or leadership	`define-problem-statement`
The full nine-block business model, not a single-risk read	`foundation-lean-canvas`
Ranking many features or initiatives against each other	`define-prioritization-framework`

The boundary that matters most: this skill is forward-looking and pre-commitment (low or no data); iterate-pivot-decision is retrospective and post-launch (it weighs market feedback on something already shipped).

How to Use

Invoke the skill by name (/pm-skills:foundation-build-risk-review on Claude Code, $foundation-build-risk-review on Codex):

/pm-skills:foundation-build-risk-review "Your context here"

Or reference the skill file directly: skills/foundation-build-risk-review/SKILL.md

Hard gate

Do not write code, scaffold a project, recommend a stack, or design implementation. First answer three things: should this be built, what is most likely to make it fail, and what must be validated before committing.

If the user says the work is for learning, a portfolio, or internal practice, do not judge it by market standards; still flag scope and clarity risks.

Modes (route first; state the mode at the top)

Pre-build - a new idea, product, or MVP not yet built. The usual primary risks: demand and distribution.
Feature-change - a feature request, scope expansion, requirement change, or competitor-copy on an in-progress product. The primary tool here is the demand hierarchy.

If the product is already launched and the question is whether to change direction, hand off to iterate-pivot-decision. If the request is too broad to review responsibly, ask exactly one clarifying question (complete the sentence: “this is for [who] in [situation] to solve [problem]”), then proceed. Never run a long questionnaire; at most two questions before a constrained review.

The review (the contract)

Produce a Build Risk Review with these parts:

Biggest risk (R1). Exactly one primary risk, tagged from references/risk-taxonomy.md. Not a long inventory. Add at most three to five supporting risks (R2, R3, …).
Demand level (feature-change mode). Place the request on the hierarchy: L0 founder anxiety or “competitors have it”; L1 one user asked; L2 repeated asks, no behavior proof; L3 workflow blocker; L4 revenue or retention blocker. Build-now is usually justified only at L3 or L4.
Evidence ledger. List the signal that exists and grade each entry on the strength ladder in references/risk-taxonomy.md. Likes, compliments, waitlists, and market-size numbers are NOT demand. Real files, booked calls, payment, repeated manual use, or switching from an existing alternative are.
Verdict (exactly one): Build small / Validate first / Pivot first / Don’t build yet. Do not use “Kill”.
Validation step. A specific, no-code or low-code next action (talk to the ten users who do X; manually deliver the result for three of them; collect a preorder, paid call, or deposit), never generic advice like “build an MVP” or “do user research”.
Routing. Send the user to the skill that does the next piece of work (see below).

Be skeptical but useful. Always separate “can be built” from “should be built”. Do not flatter the idea or default to encouragement; do not say “this has potential” unless the path is specific.

Verdict routing

Verdict	Routes to
Build small	`define-problem-statement`, then `deliver-prd` / `deliver-user-stories`
Validate first	`define-hypothesis`, then `measure-experiment-design`
Pivot first	`foundation-lean-canvas` (re-frame the model)
Don’t build yet	stop; or `discover-competitive-analysis` / `discover-market-sizing` for an evidence check
Several competing requests	`define-prioritization-framework`

Full map, including the per-risk routing: references/routing-map.md.

Output Format

A single Build Risk Review artifact, built from references/TEMPLATE.md. Section order: decision header (verdict + one-line rationale), the biggest risk (R1), supporting risks, demand level (feature mode), evidence ledger, validation plan, routing, Sources. A fully worked case is in references/EXAMPLE.md.

Attribution

Adapted from bin1874/before-you-build-skill (Apache-2.0), repositioned PM-neutral. The source skill’s external case-memory API call and translate-to-user-language behavior are removed.

Output Template

Build Risk Review:

Authoring notes are in blockquotes; delete them in the final artifact. Fill every non-optional section. Keep it short: a Build Risk Review is a gate, not a report.

Mode: <Pre-build | Feature-change> | Date:

Verdict

Exactly one: Build small / Validate first / Pivot first / Don’t build yet. Then one sentence of rationale. Do not use “Kill”.

Biggest risk

Exactly one primary risk, R1, tagged from references/risk-taxonomy.md. Then at most three to five supporting risks. Do not produce a long inventory.

R1 : <the single assumption most likely to make this fail, stated concretely.>
R2 :
R3 :

Demand level

Feature-change mode only. Place the request on L0 through L4 and say why. For pre-build mode write “n/a: new idea”.

L<0-4> - . <Why this level: founder anxiety, one ask, repeated asks, a workflow blocker, or a revenue/retention blocker?>

Evidence ledger

What signal actually exists, each graded on the strength ladder (references/risk-taxonomy.md). Be honest: likes, waitlists, and market-size are not demand. Mark counter-signal too.

Signal	Strength	What it does or does not prove
	<weak / medium / strong>

Validation plan

Specific, no-code or low-code next actions with a concrete bar. Never “build an MVP” or “do user research”.

<action with a pass/fail bar.>
<action.>

Routing

The next skill to run, from references/routing-map.md.

-> ().

Sources

Real, cited facts only. Mark every invented number [fictional].

Output contract: one artifact; one R1; exactly one verdict; one demand level in feature-change mode; a graded evidence ledger; a no-code next step; a named routing target; no code or implementation design.

Example Output

Example: Build Risk Review (feature-change mode)

A worked case showing the full artifact. The scenario is a B2B ecommerce platform whose sales team is pushing to build single sign-on (SSO) after two enterprise prospects raised it. All merchant and deal specifics are [fictional].

Scenario

The input the skill received.

“Two enterprise prospects asked about SSO in the last month, and Sales says we’ll lose them without it. They want me to put SSO on next sprint. We’re a 140-merchant B2B catalog platform; most of our paying accounts are mid-market. Should we build SSO now?”

Prompt

“Run a build risk review on this SSO request before I commit a sprint.”

Build Risk Review: SSO for enterprise merchant accounts

Mode: Feature-change | Date: 2026-06-22

Verdict

Validate first. SSO is a plausible enterprise requirement, but the current signal is two prospects raising it in calls, not a confirmed deal-blocker. Committing a sprint now would build on an L2 signal and pull capacity from the activation work that the data says actually moves retention.

Biggest risk

R1 feature-fit: the request is being read as an L4 deal-blocker when the evidence only supports L2 (repeated asks, no behavior proof). Neither prospect has put “no SSO = no deal” in writing, and no current paying merchant has churned over its absence. Building on that is the feature-treadmill trap: it feels urgent because Sales is loud, not because the data says it changes who pays.
R2 distribution: even if built, SSO does not by itself reach more enterprise buyers; the constraint upstream is a thin enterprise pipeline [fictional: 2 active prospects], which a feature does not fix.
R3 trust: SSO is a trust-tier feature (identity, provisioning), so a thin first version that mishandles SCIM or de-provisioning would do more reputational harm than not having it, raising the real cost above the sprint estimate.

Demand level

L2 - repeated asks, no behavior proof. Two prospects mentioned SSO in sales calls [fictional]. That is more than one ask (above L1) but neither has made it a contractual go/no-go, and zero of 140 paying merchants [fictional] have raised or churned over it. It is not yet an L3 workflow blocker (merchants complete the core catalog job today without SSO) or an L4 revenue blocker (no signed dependency).

Evidence ledger

Signal	Strength	What it does or does not prove
Two enterprise prospects raised SSO in calls `[fictional]`	medium	real interest from the target segment; not a commitment
Sales says “we’ll lose them without it”	weak	a forecast, not a written requirement; Sales is incentivized to unblock deals with product
”Enterprise buyers expect SSO” (category articles)	weak	a category norm, not proof for these two deals
0 of 140 paying merchants cite SSO `[fictional]`	counter-signal	no retention or activation pressure from the existing base
Activation A/B in flight shows onboarding checklist lifts week-2 retention `[fictional]`	strong (for the alternative)	the capacity SSO would consume has a measured return elsewhere

Validation plan

Make the deal dependency real. Ask both prospects to confirm in writing that SSO is a go/no-go requirement with a target date. Pass bar: at least one returns a signed contingency. If neither does, the L4 framing is false and this drops to Defer.
Price the trust tier. Time-box a half-day spike on the SCIM / de-provisioning surface to replace the sprint estimate with a real one; a trust-tier feature is rarely a one-sprint build.
Hold the line on activation. Do not pause the in-flight activation A/B; it has a measured retention return that the SSO request does not.

Routing

-> define-hypothesis to frame “SSO unblocks >= $X enterprise ARR this quarter” as a testable claim with a metric and a date, then define-prioritization-framework to rank it against the activation work once the spike gives a real cost. If a signed contingency comes back, re-run this review; a confirmed L4 flips the verdict to Build small and routes to define-problem-statement -> deliver-prd.

Sources

All merchant counts, prospect details, and experiment results are [fictional] and illustrative.
Demand-level and evidence-strength definitions: references/risk-taxonomy.md.

Why not the other verdicts

Included here for teaching; a real artifact does not need this section.

Build small would be right at L3/L4 - if a prospect signs an SSO contingency, or a paying merchant churns over it. Today neither is true.
Don’t build yet would be too strong: the segment interest is real and SSO is a normal enterprise requirement, so the wedge is not wrong, only unproven.
Pivot first does not apply: nothing here questions the product’s direction, only the timing of one feature.

Real-World Examples

See this skill applied to three different product contexts:

Storevine (B2B): Storevine B2B ecommerce catalog platform - whether to build a native bulk price-update tool requested by mid-market merchants

Prompt:

“Run a build risk review on a native bulk price-update tool before I scope the sprint.”

Output:

Build Risk Review: native bulk price-update tool

Mode: Feature-change | Date: 2026-06-22

Brainshelf (Consumer): Brainshelf consumer PKM app - whether to build AI auto-tagging as a new bet before validating demand

Prompt:

“Should I build AI auto-tagging into Brainshelf? Pour cold water on it first.”

Output:

Build Risk Review: AI auto-tagging

Mode: Pre-build | Date: 2026-06-22

Workbench (Enterprise): Workbench enterprise collaboration platform - whether to build a broad AI knowledge base, where the wedge is crowded and needs narrowing

Prompt:

“Is the enterprise AI knowledge base worth building? Give me a verdict.”

Output:

Build Risk Review: enterprise AI knowledge base

Mode: Pre-build | Date: 2026-06-22

Quality Checklist

Exactly one primary risk is named (R1) and tagged from the taxonomy.
Feature-change mode places the request on L0 through L4.
Every evidence entry is graded; no like, waitlist, or market-size number is counted as demand.
Exactly one of the four verdicts is returned.
The next step is specific and low or no-code, not generic advice.
A routing target is named.
No code, stack recommendation, or implementation design is produced (the hard gate held).