Runs a fast pre-build risk review on a product idea, feature request, or scope change, naming the single assumption most likely to make it fail and returning a clear verdict (build small, validate first, pivot first, or don't build yet) with a no-code validation step. Use before committing build effort, when triaging whether to honor a feature request, or when deciding whether to expand scope, ahead of writing a PRD. For a launched product's pivot-or-persevere decision, use iterate-pivot-decision instead.
把这段话发给 Claude Code、Codex 或 Cursor。智能体会先检查安全性，你确认后才安装。
读取 https://funcoding.ai/skills/product-on-purpose/pm-skills/foundation-build-risk-review/install.md ，按里面的步骤帮我安装这个 Skill。
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.
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.
| 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).
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.
Produce a Build Risk Review with these parts:
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, ...).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.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 | 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 |
discover-competitive-analysis | The two closest alternatives and the one axis on which you would lose to each today |
discover-market-sizing | One bottom-up estimate: reachable accounts, times a realistic attach rate, times annual revenue per account, labelling each of the three as sourced or assumed. All three factors are required: accounts times attach rate is a customer count, not a market size |
deliver-prd | The problem, the one success metric with its baseline, and what is explicitly out of scope |
deliver-user-stories | The three stories that carry the risk, each with one acceptance criterion that could fail |
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.
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.
R1) and tagged from the taxonomy.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.
anthropics/skills180kUse this skill whenever the user wants to do anything with PDF files. This includes reading or extracting text/tables from PDFs, combining or merging multiple PDFs into one, splitting PDFs apart, rotating pages, adding watermarks, creating new PDFs, filling PDF forms, encrypting/decrypting PDFs, extracting images, and OCR on scanned PDFs to make them searchable. If the user mentions a .pdf file or asks to produce one, use this skill.
文档与办公
anthropics/skills180kAfter you give a substantive answer or draft that the user may act on — advice or recommendations, drafted artifacts such as goals, plans, pitches, proposals, or emails, estimates or projections, analysis or interpretation of data, factual claims they may rely on, or a multi-step argument — invoke this skill BEFORE finalizing your reply and then, if it applies, append 2-3 short follow-up questions, each tied to something specific in what you just produced, that help the user check key facts, probe the reasoning or assumptions, and notice missing context. Do this at most once per conversation. Skip it when the user asked a trivial how-to or simple lookup, wants a purely educational explanation, asked you only to format, convert, or assemble a file from content they provided, is writing code they will run, is doing creative writing or casual chat, or already asked you to double-check, cite, or review — the skill file explains these boundaries and the exact output format.
文档与办公
anthropics/skills180kGuide users through a structured workflow for co-authoring documentation. Use when user wants to write documentation, proposals, technical specs, decision docs, or similar structured content. This workflow helps users efficiently transfer context, refine content through iteration, and verify the doc works for readers. Trigger when user mentions writing docs, creating proposals, drafting specs, or similar documentation tasks.
文档与办公
anthropics/skills180kUse this skill whenever the user wants to create, read, edit, or manipulate Word documents (.docx files) or Word templates (.dotx files). Triggers include: any mention of 'Word doc', 'word document', '.docx', '.dotx', or requests to produce professional documents with formatting like tables of contents, headings, page numbers, or letterheads. Also use when extracting or reorganizing content from .docx or .dotx files, inserting or replacing images in documents, performing find-and-replace in Word files, working with tracked changes or comments, or converting content into a polished Word document. If the user asks for a 'report', 'memo', 'letter', 'template', or similar deliverable as a Word or .docx file, use this skill. Do NOT use for PDFs, spreadsheets, Google Docs, or general coding tasks unrelated to document generation.
文档与办公
anthropics/skills180kUse this skill any time a .pptx or .potx file is involved in any way — as input, output, or both. This includes: creating slide decks, pitch decks, or presentations; reading, parsing, or extracting text from any .pptx or .potx file (even if the extracted content will be used elsewhere, like in an email or summary); editing, modifying, or updating existing presentations; combining or splitting slide files; working with templates (.potx), layouts, speaker notes, or comments. Trigger whenever the user mentions "deck," "slides," "presentation," or references a .pptx or .potx filename, regardless of what they plan to do with the content afterward. If a .pptx or .potx file needs to be opened, created, or touched, use this skill.
文档与办公
anthropics/skills180kCreate beautiful visual art in .png and .pdf documents using design philosophy. You should use this skill when the user asks to create a poster, piece of art, design, or other static piece. Create original visual designs, never copying existing artists' work to avoid copyright violations.
文档与办公