foundation-build-risk-review

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

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.

暂不要急于构建。首先找出最可能导致失败的核心假设。

foundation-build-risk-review

是产品决策阶段快速的预投入准入关卡。针对某个想法、功能请求或范围变更，它会生成一份构建风险评估报告：包含最大风险点、背后依据、结论，以及具体的无代码验证步骤，随后引导你使用完成后续工作的对应技能。它是一个基础枢纽：职责是筛选和分流，而非重复更深入技能的工作内容。

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.

请勿编写代码、搭建项目框架、推荐技术栈或设计实现方案。首先回答三个问题：是否应该构建该内容？最可能导致其失败的因素是什么？投入资源前必须验证哪些内容？

如果用户表示该工作用于学习、作品集制作或内部练习，则无需以市场标准评判，但仍需指出范围和清晰度方面的风险。

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.

产品想法、MVP或新业务即将进入构建阶段。
收到功能请求或范围变更需求，需区分真实需求与客套请求、创始人焦虑或竞品模仿行为。
在PRD、路线图争议或工单创建前，需要快速得到“我们是否应该构建这个？”的结论。

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).

若需求为	请使用以下技能替代
已上线产品的转型或坚持决策，需权衡使用数据或市场数据	`iterate-pivot-decision`
已选定假设，需要设计测试方案	`define-hypothesis`
为团队或领导层明确已确认的问题	`define-problem-statement`
完整的九格商业模式分析，而非单一风险评估	`foundation-lean-canvas`
对多个功能或举措进行优先级排序	`define-prioritization-framework`

最关键的边界：本技能是前瞻性、预投入阶段的工具（数据极少或无数据）；

iterate-pivot-decision

是回顾性、上线后阶段的工具（需权衡已上线产品的市场反馈）。

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.

预构建模式 - 针对尚未构建的新想法、产品或MVP。通常的主要风险：需求与获客渠道。
功能变更模式 - 针对在研产品的功能请求、范围扩展、需求变更或竞品模仿行为。核心工具是需求层级模型。

若产品已上线，且问题是是否要改变方向，请转交至

iterate-pivot-decision

技能。若需求过于宽泛无法负责任地开展评审，请提出一个明确的澄清问题（补全句子：“这是为[谁]在[场景下]解决[问题]”），然后再继续。切勿进行冗长的问卷调查；最多提出两个问题后开展受限评审。

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.

生成的构建风险评估报告需包含以下部分：

最大风险点（
R1
）：明确一个核心风险，标签需来自
```
references/risk-taxonomy.md
```
。无需列出冗长的风险清单。最多可添加3-5个次要风险（
```
R2
```
、
```
R3
```
等）。
需求层级（功能变更模式）：将请求归入对应层级：L0 创始人焦虑或“竞品已有该功能”；L1 单个用户提出请求；L2 多次请求，但无行为证据；L3 工作流程阻塞；L4 影响收入或留存。通常仅L3或L4层级的需求才具备立即构建的合理性。
证据记录：列出已有的信号，并根据
```
references/risk-taxonomy.md
```
中的强度等级为每条证据打分。点赞、好评、等待名单和市场规模数据不视为需求。真实文件、预约的沟通、付款记录、重复手动操作或从现有竞品切换的行为才是有效需求信号。
结论（唯一选项）：小步构建 / 先验证 / 先转型 / 暂不构建。请勿使用“终止”表述。
验证步骤：具体的无代码或低代码下一步行动（与10位执行X操作的用户沟通；为3位用户手动交付结果；收集预订单、付费咨询或定金），切勿给出“构建MVP”或“开展用户调研”这类通用建议。
分流引导：引导用户使用完成后续工作的对应技能（见下文）。

保持质疑但提供有用信息。始终区分“能够构建”与“应该构建”。切勿奉承想法或默认鼓励；除非路径明确，否则不要说“这个想法有潜力”。

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

If a routed skill is not available, do not ship a bare pointer. The library is often installed in part rather than whole, so the skill you route to may not exist in the user's environment. When you cannot confirm it is available, say so plainly and inline the minimal version of its output so the review stays executable:

Routed skill absent	Inline instead
`define-hypothesis`	One testable hypothesis in believe / for / will / as-measured-by form
`measure-experiment-design`	A three-line experiment sketch: the one decision metric, the sample or duration needed, and the win/lose rule set before running
`define-problem-statement`	A two-sentence problem frame: who, in what situation, blocked by what
`foundation-lean-canvas`	The three riskiest boxes only: problem, customer segment, unfair advantage
`define-prioritization-framework`	A single ranked list with the one criterion that actually decides

A verdict whose next step the user cannot execute is not a finished review. Naming the gap and supplying the minimum is always better than routing into an environment that cannot follow.

结论	引导至
小步构建	`define-problem-statement` ，随后使用 `deliver-prd` / `deliver-user-stories`
先验证	`define-hypothesis` ，随后使用 `measure-experiment-design`
先转型	`foundation-lean-canvas` （重新构建商业模式）
暂不构建	终止；或使用 `discover-competitive-analysis` / `discover-market-sizing` 进行证据核查
多个相互竞争的请求	`define-prioritization-framework`

完整的分流地图，包括按风险类型的分流：

references/routing-map.md

。

若目标技能不可用，请勿仅提供指向链接。技能库通常是部分安装而非完整安装，因此你引导至的技能可能不存在于用户环境中。当无法确认技能可用时，请直接说明，并内联其输出的最简版本，确保评审结果可执行：

目标技能缺失	内联替代内容
`define-hypothesis`	一个可测试的假设，格式为：相信/针对/将会/衡量标准
`measure-experiment-design`	三行实验概要：核心决策指标、所需样本量或时长、实验前设定的胜负规则
`define-problem-statement`	两句式问题框架：谁、在什么场景下、被什么问题阻碍
`foundation-lean-canvas`	仅三个风险最高的模块：问题、客户群体、不公平优势
`define-prioritization-framework`	单一排序列表，附带决定优先级的核心标准

用户无法执行下一步的结论不算完整的评审。指出缺口并提供最小可行内容，总比分流到无法跟进的环境中更好。

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

一份单一的构建风险评估成果，基于

references/TEMPLATE.md

生成。章节顺序：决策标题（结论+一行理由）、最大风险点（

R1

）、次要风险、需求层级（功能模式）、证据记录、验证计划、分流引导、来源。完整的示例案例见

references/EXAMPLE.md

。

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).

明确命名一个核心风险点（
```
R1
```
），且标签来自风险分类体系。
功能变更模式下将请求归入L0至L4层级。
每条证据均已打分；点赞、等待名单或市场规模数据不被算作需求。
返回四个结论中的唯一选项。
下一步行动具体且为低代码/无代码，而非通用建议。
指定了分流目标。
未生成代码、技术栈推荐或实现设计方案（严格遵守准入规则）。

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.

改编自

bin1874/before-you-build-skill

（Apache-2.0协议），调整为中立的PM视角。移除了源技能中的外部案例记忆API调用和用户语言转换功能。