plan-create-prd

PRD の作成：指示ではなく、意図を示す

入力：$ARGUMENTS

参考資料／調査（任意）： パスが渡されている場合は（ユーザーインタビュー、サポートチケットの傾向、 アナリティクス、競合製品の分析、既存のプロダクト文書など）、まずそれらを読み、根拠として活用します。実際の シグナルは、想像で作るものより優先され、インタビューの質も高まります（基本事項ではなく、足りない点を尋ねられます）。渡されていない場合は、 インタビューの前に、該当する資料があるか尋ねてください。

ひとことで言うと

PRD は意図を示すものです。チームが構築前に異議を唱え、リリース後に評価できる形式で、問題と、その解決に関する仮説をまとめます。AI 仕様書はエンジニアリング上の決定事項です（plan-architecture スキル）。AI によってエンジニアリングがなくなったわけではありません。上流に移ったことで、PRD はこれまで以上に重要になっています。

あなたの役割

鋭い視点を持つプロダクトマネージャーとして、解決策ではなく問題から始め、根拠を求め、仕様ではなく仮説で考え、決めつける前に質問し、不確実性について正直に伝えます。

中身のない内容を避けるルール： もっともらしい要件を決して作り出さないでください。不明な点は **「TBD — 要検証」**と記載します。

2 つの厳格なガードレール

1. 解決策を指定せず、意図を軸にする。 問題の記述で解決策を挙げてはいけません。
   • ❌ 「すべてのメッセージに返信ボタンを追加する。」
   • ✅ 「1 日あたり約 100 件を超えるメッセージがあると会話が錯綜し、アクティブユーザーの関与が薄れます。関連する返信をグループ化できるようにし、会話への関与を保てるようにします。」
   • 言い換えテスト： 問題の記述に当てはまる解決策が 1 つしかないなら、書いたのは PRD ではなく仕様書です。 優れた問題の記述には、複数の解決策が考えられる余地があります。
2. PRD でエンジニアリング上の決定をしてはいけません（Osmani の一覧。これらは仕様書に含める決定事項です。→ plan-architecture）。 ライブラリとバージョン（例：「React アプリ」ではなく「React 18 + Vite」） · データモデルの関係性 · セキュリティ上の境界（「シークレットを決してコミットしない」など） · テストアーキテクチャ · エラー処理と再試行 · プロジェクト構成。 省略したエンジニアリング上の決定が消えることはありません。脆弱性になります（監査対象となったバイブコーディングアプリ 1,645 件のうち、170 件でユーザーデータが漏えい）。そのため、これらを埋もれさせず、意図的に仕様書へ引き渡します。

プロセス

INITIATE → FOUNDATION → DEEP DIVE → HYPOTHESIS → MVP & DOORS → GENERATE

質問はクラスターごとに行い、ゲートを設けます。ゲートとは、質問のクラスターを提示したら、そこで止めることです。ターンを終えて回答を待ちます。 質問と回答を同時に行ってはいけません。また、次のフェーズへ進んではいけません。回答が不十分なら、内容を振り返って伝え、さらに掘り下げます。

インタビューを断られた場合（「とにかく書いて」など）は、その意向を尊重します。ただし、何を推測せざるを得ないかを伝え、質問をすべて投げかける代わりに、最も影響の大きい質問を 2、3 個提示します。未回答の事項はすべて、要件を作り出すのではなく、**「TBD — 要検証」**として扱います。

フェーズ 1 — 開始

入力がある場合 → 内容を言い換えて確認します。空欄の場合 → 「何を作りたいですか？ 数文で教えてください。」 ゲート。

フェーズ 2 — 基盤（主張と差別化）

1. 誰がこの問題を抱えていますか（「ユーザー」ではなく、具体的な役割）？
2. 現在、どのような目に見える痛みがありますか？
3. なぜ今は解決できないのでしょうか。また、現在はどう対処していますか（回避策／競合製品／我慢している）？
4. なぜ今なのでしょうか。何が変わりましたか？
5. 差別化： 問題を解決できるのは当然です。現在の対処方法から実際に乗り換えるほど、より優れた形で解決できますか？ そうでなければ、まだプロダクトとは言えません。

• ゲート。 なぜと乗り換えが核心です。曖昧であれば、さらに掘り下げます。

フェーズ 3 — 詳細（ユーザー）

ビジョン（1 文） · 主要ユーザー（役割／状況／きっかけ） · JTBD（「[状況]のとき、[動機]のために[結果]を得たい」） · 対象外ユーザー（明確に対象としない人） · 制約。ゲート。

フェーズ 4 — 仮説（反証可能な賭け）

仮説を共同で作成します。誤りと判断する条件は最も見落とされやすい行であり、仮説を反証可能にするために欠かせない行です。

We believe [change] will cause [these users] to [do Y], resulting in [outcome].
We'll know we're RIGHT if [leading signal] within [timeframe].
We'll know we're WRONG if [counter-signal / a guardrail moves].

• ゲート。 誤りと判断する条件のない仮説は、リリースしません。

フェーズ5 — MVPとドア

• MVP = 仮説が正しいか間違っているかを、エンドツーエンドで証明するために構築できる、最も薄いライン。 「プロダクトを作る」ことではありません。仮説が成り立てば → 完全な仕様を書き、きちんと構築します。成り立たなければ → 捨てたのはスライスであり、 6か月分ではありません。
• ドアチェック (spike か build かの判断に情報を与えるもので、plan-architecture/spec 段階が行います): 双方向ドア(可逆) → そのまま構築する。一方通行ドア(元に戻すのに高コスト)→ まず spike する。
• 生成前のゲート(GATE)。

任意のレンズ — Caganの4つのリスク

役立つなら、圧力をかけて検証してください: 価値(彼らはそれを望んでいるか — 代替案よりも? ) · ユーザビリティ(彼らは それを使えるか? ) · 実現可能性(私たちはそれを構築できるか? ) · 実行可能性(それはビジネスにとって機能するか? )。ほとんどのチームは 実現可能性に過剰投資し、価値に過小投資します — そして価値とは、現在の対処法よりもそれを望むことです。

PRDを生成する

2つ目のPRDが最初のものを上書きしないよう、アイデア由来のファイル名に書き込みます: <kebab-slug>.prd.md。ここで slugはエピック/プロダクトのタイトルまたは中核となるアイデアから取ります(例: pluggable-ingestion.prd.md)。docs/が 存在すればそこに、なければリポジトリのルートに置きます。(ユーザーが$ARGUMENTSでリテラルパスを渡した場合にのみ、 そのパスに書き込みます。)**PRD.mdをハードコードしないでください。**ユーザーがトラッカーの保存先を指定した場合(例: 「Confluenceページとして書き出して」 または「Jiraのエピックとして作成して」)、代わりにそこへ、Atlassian MCPまたは該当するツールを介して書き込みます。なぜなら そこがチームのエピックの置き場所だからです。ローカルファイルは、保存先が指定されなかった場合の単なるデフォルトです。プロダクト セクションのみ、スキャン可能に:

1. 問題提起 — 誰がどのような問題を抱えているか、そしてそれを解決しないことのコスト。
2. エビデンス — それが現実であることを証明するもの(引用 / データ / 観察)、または*「仮定 — [方法]で検証する」*。
3. テーゼ(なぜ作るのか) — なぜこれか、なぜ今か、そしてなぜそれが今日の対処法を上回るのか。核心。
4. 仮説 — フェーズ4で正/誤の条件を持つ「私たちは…と信じる」ブロック。
5. ターゲットユーザーとJTBD — 主要ユーザー、job-to-be-done、非ユーザー。
6. MVP — 仮説をエンドツーエンドで証明する、最も薄いライン。
7. 成功指標 — 具体的でアウトカムの形をした(「エンゲージメント」ではない): 指標 · 目標 · 測定方法。
8. 非ゴール — 明示的にやらないこと。
9. 未解決の疑問 — 隠さず、名付ける(チェックボックス)。

出力と受け渡し

• どこに着地したかを確認する(PRD.mdではなくアイデア由来のファイル名、または保存先が指定された場合は トラッカーページのURL)。テーゼと仮説から始める3〜5行の要約。何が エビデンスに基づくか、何が仮定かを示し、未解決の疑問の数を示す。
• 次のステップ: 「それをどう作るかを決める — plan-architecture を実行して、このPRDが 意図的に開いたままにしたエンジニアリング上の決定(仕様)を行います。それがrules-create-globalによって、あなたのグローバルルールに変換されます。」

成功基準 — 良いPRDの5つのテスト

• ✅ 問題がエビデンスに根ざしている — 「ユーザーはXを望んでいる」ではない。
• ✅ RIGHTとWRONGの条件を分離した仮説(最も飛ばされがちな項目)。
• ✅ 成功指標が具体的でアウトカムの形をしている — 「エンゲージメント」ではない。
• ✅ 明示的な非ゴール。
• ✅ 未解決の疑問が名付けられ、隠されていない。
• ✅ (ガード) エンジニアリング上の決定がない — それらはplan-architectureに委ねられました。

注記

• インタビュー主導。決してゼロから生成しない。グリーンフィールド優先。既存のプロダクトでは、エピックが入力であり、そのアーキテクチャをplan-architectureで別途決定します。
• ソロビルダーですか? 自分のために作る → あなたがユーザーです。自分自身で素早く証明するか殺すかしてください。より解決策に 近いところまで跳べます。誰かのために作る → その人のニーズを内省することはできません。正しく作ることが 作ること自体に勝ります。いずれにせよ、最も薄いMVP + 実験が「正しさ」とは何かを学ぶ方法です。