foundation-build-risk-review

ビルドリスクレビュー

まだ作り始めないでください。まず、失敗する可能性が最も高い前提を 1 つ挙げてください。

foundation-build-risk-review は、プロダクトの意思決定に向けた、迅速なコミット前ゲートです。アイデア、機能リクエスト、またはスコープ変更が与えられると、ビルドリスクレビューを返します。すなわち、最大のリスク、その根拠、判定、そしてコードを書かずに実行できる具体的な検証ステップを示し、次に取り組むべき作業を行うスキルへとルーティングします。これは基盤ハブであり、その役割はトリアージと振り分けであり、より深いスキルを重複させることではありません。

厳格なゲート

コードを書いたり、プロジェクトを雛形化したり、スタックを推薦したり、実装を設計したりしないでください。まず次の 3 点に答えてください。これは作るべきか、失敗する可能性が最も高いのは何か、コミットする前に何を検証しなければならないか。

ユーザーがその作業は学習、ポートフォリオ、または社内練習のためだと言った場合、市場基準で判断しないでください。それでもスコープと明確さのリスクは指摘してください。

使用する場合

• プロダクトのアイデア、MVP、または新しい賭けが、これからビルド作業に変わろうとしている。
• 機能リクエストやスコープ変更が届き、本当の需要と、丁寧な要望、創業者の不安、または競合の模倣とを切り分ける必要がある。
• PRD、ロードマップの行、またはチケットが存在する前に、手早く「これは作るべきか?」という判定を誰かが求めている。

使用しない場合

依頼がこちらに該当する場合	代わりに使うもの
ローンチ済みプロダクトのピボットか継続かの判断で、利用状況や市場データを重視する	iterate-pivot-decision
前提を選んだうえで、その検証を設計する必要がある	define-hypothesis
確認済みの問題をチームや経営層向けに組み立てる	define-problem-statement
単一リスクの読みではなく、9 ブロック全体のビジネスモデル	foundation-lean-canvas
多くの機能や施策を互いに比較して優先順位付けする	define-prioritization-framework

最も重要な境界線: このスキルは将来志向でコミット前(データが少ない、または皆無)です。iterate-pivot-decision は振り返り的でローンチ後(すでに出荷済みのものに対する市場のフィードバックを重視する)です。

モード (まずルーティングし、冒頭でモードを明示する)

1. Pre-build - まだ作られていない新しいアイデア、プロダクト、または MVP。通常の主要リスク: 需要と流通。
2. Feature-change - 進行中のプロダクトに対する機能リクエスト、スコープ拡大、要件変更、または競合の模倣。ここでの主要なツールは需要ヒエラルキーです。

プロダクトがすでにローンチ済みで、方向転換すべきかという問いである場合は、iterate-pivot-decision に引き継いでください。リクエストが責任をもってレビューするには広すぎる場合は、明確化の質問を正確に 1 つだけ行い(文を完成させてください: 「これは [誰] が [状況] で [問題] を解決するためのものです」)、その後進めてください。長いアンケートを決して行わないでください。制約されたレビューの前に、せいぜい 2 つの質問までです。

レビュー（契約）

以下の項目を含むビルドリスクレビューを作成します。

1. 最大のリスク（R1）。 references/risk-taxonomy.md からタグ付けした主要リスクを必ず1つ挙げます。長い一覧にはしません。補足的なリスク（R2、R3 など）は最大3〜5件まで追加できます。
2. 需要レベル（機能変更モード）。 次の階層に当てはめます。L0 創業者の不安、または「競合にはある」；L1 1人のユーザーから要望があった；L2 要望は繰り返しあるが、行動による証拠はない；L3 ワークフローを妨げている；L4 収益または継続率を妨げている。通常、今すぐ作る判断が妥当なのはL3またはL4のみです。
3. エビデンス台帳。 あるシグナルを列挙し、各項目を references/risk-taxonomy.md の強度基準に照らして評価します。「いいね」、称賛、ウェイトリスト、市場規模の数値は需要ではありません。実際のファイル、予約済みの通話、支払い、繰り返しの手作業での利用、既存の代替手段からの乗り換えは需要の証拠です。
4. 判定（次のいずれか1つのみ）：小さく作る ／ まず検証する ／ まず方向転換する ／ まだ作らない。「やめる」は使わないでください。
5. 検証ステップ。 具体的なノーコードまたはローコードの次のアクション（Xをしているユーザー10人と話す、3人に手作業で結果を提供する、先行予約・有料相談・デポジットを募るなど）を示します。「MVPを作る」や「ユーザー調査をする」のような一般的な助言は避けてください。
6. ルーティング。 次の作業を行うスキルにユーザーを案内します（下記を参照）。

懐疑的でありながら、役に立つレビューにしてください。「作れる」ことと「作るべき」ことは必ず分けて考えます。アイデアをおだてたり、安易に応援したりしないでください。具体的な道筋がない限り、「可能性があります」とは言わないでください。

判定のルーティング

判定	ルーティング先
小さく作る	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	believe / for / will / as-measured-by の形式による、検証可能な仮説を1つ
measure-experiment-design	3行の実験案：1つの意思決定指標、必要なサンプル数または期間、実施前に定める成功／失敗の判定基準
define-problem-statement	2文で示す課題の枠組み：誰が、どの状況で、何によって行き詰まっているか
foundation-lean-canvas	最もリスクの高い3項目のみ：課題、顧客セグメント、不公平な優位性
define-prioritization-framework	実際に判断を決める1つの基準に基づく、単一の優先順位リスト
discover-competitive-analysis	最も近い代替手段を2つと、それぞれに対して現時点で劣る1つの軸
discover-market-sizing	ボトムアップの推定を1つ提示：到達可能なアカウント数 × 現実的な導入率 × アカウントあたりの年間収益。それぞれが情報源に基づくか、仮定かを明記します。3つすべての要素が必要です。アカウント数 × 導入率は顧客数であり、市場規模ではありません。
deliver-prd	課題、ベースラインを伴う1つの成功指標、明示的に対象外とするもの
deliver-user-stories	リスクを担う3つのストーリー。それぞれに、失敗し得る受け入れ基準を1つ付けます。

次のステップをユーザーが実行できない判定は、完成したレビューではありません。ルーティング先の環境では続行できない場合、欠けているものを明示し、必要最小限の内容を提示する方が常に適切です。

出力形式

references/TEMPLATE.md をもとに作成した、単一の Build Risk Review 成果物です。セクションの順序：判断ヘッダー（結論＋1行の根拠）、最大のリスク（R1）、補足リスク、需要レベル（機能モード）、エビデンス台帳、検証計画、ルーティング、Sources。完成例は references/EXAMPLE.md にあります。

品質チェックリスト

• 主要なリスクは1つだけ（R1）を挙げ、分類体系からタグ付けします。
• 機能変更モードでは、リクエストをL0からL4までのいずれかに位置付けます。
• すべてのエビデンス項目を評価します。「いいね」、ウェイトリスト、市場規模の数値は需要として数えません。
• 4つの結論のうち、ちょうど1つを返します。
• 次のステップは具体的かつ低コードまたはノーコードであり、一般論的な助言ではありません。
• ルーティング先を明記します。
• コード、技術スタックの推奨、実装設計は提示しません（ハードゲートを維持します）。

帰属

bin1874/before-you-build-skill（Apache-2.0）を改変し、PMに中立的な形に再構成しました。元のスキルにあった外部ケースメモリーAPIの呼び出しと、ユーザーの言語への翻訳機能は削除しています。