pm-idea-to-plan について
pm-idea-to-plan は、アイデアを開発可能な計画にまとめるプロダクトマネージャー向けのオーケストレーションスキルです。問題設定、ディスカバリー、ユーザー定義、リスク検証、優先順位付けを経て仕様を作成し、計画をプロダクトレビューに引き継ぎます。
主な機能
- 01段階に沿った計画スキルの編成
- 02問題設定とディスカバリーの先行
- 03最もリスクの高い仮説の検証
- 04検証済みリスクに基づく優先順位付け
- 05証拠を集めてから仕様を作成
- 06計画をプロダクトレビューへ引き継ぎ
活用シーン
- 01初期アイデアを開発可能な計画にする
- 02開発前に導入意向や支払い意向を検証する
- 03新製品で最初に作る範囲を決める
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/インストール後、Claude Code で/pm-idea-to-planを入力して読み込まれたか確認します。
詳細
アイデア → プラン（PM 作成オーケストレーター）スキル
このスキルの動作（最初にお読みください）
これは生のアイデアをビルド可能なプランへと昇華させるための正面玄関であり、
ux-design-from-scratch の PM 版です。pm-product-review が検証の方向
（生成 → 監査）をオーケストレーションするのに対し、このスキルは構成の方向
（生成 → 生成）をオーケストレーションします。すなわち PM のスコープのはしごを順に進めます —
問題 → ディスカバリー → ユーザー → 最もリスクの高い仮説の検証 → 優先順位付け → 仕様 → 指標 —
作業が必要とする各スキルをその都度呼び出し、その結果を検証のために pm-product-review へ引き渡します。
これは docs/orchestration-policy.md の構成オーケストレーションのセクション（§9）を
PM に適用した実行可能な形です。このスキルの役割は、まさにこのスキルが解決するために作られた
失敗を避けることだけです: PRD としては過剰に作り込まれ、リスクを低減したプロダクトへの賭けとしては
不十分なプラン — 検証されていない市場と、試されていない支払い意欲の上に載った、
磨かれた仕様です。仕様は最後の段であり最初の段ではなく、その下にある
エビデンスの段より前に実行されることはありません。
このスキルを存在価値のあるものにする唯一のルール: 仕様より先にエビデンス。 Claude のデフォルトは、 「アイデアからプランを」と求められると、もっともらしく見える PRD — 要件、 ストーリー、指標 — へと突き進み、それを検証されていない問題とゼロの採用エビデンスの上に築きます。その文書は 完全に見える、だからこそ危険なのです: チームはそれを基にビルドします。このオーケストレーターは 問題、ディスカバリーのエビデンス、そして最もリスクの高い仮説の検証を最初に来るよう強制し、 仕様がプランを飲み込んでしまうのを許さず、仕様を釣り合いの取れたものに保ちます。
このスキルを使わない場合:
- 名前の付いた単一の成果物 — 「PRD を書いて」「この問題をフレーミングして」「優先順位付けの マトリクスを作って」。そのスキルを直接トリガーさせてください。明示的なスコープはオーケストレーションより優先されます。
- 戦略 / ローンチのアーク — ビジョンと戦略、競合分析、ロードマップ、GTM、ローンチ
実験。それは別の構成のアークです（
pm-vision-strategy、pm-competitive-analysis、pm-roadmap、pm-gtm-plan、pm-experimentation-ab、pm-analytics）。このスキルは検証済みでビルド可能なプランで止まります。ここで戦略アークを 生み出すのではなく、そこへ続くよう提案してください。
ステップ 0 — コンテキストプロファイルを確立する（1 回だけ）
ユーザーが与えたものから推測してください。実行内容を実質的に変える 1、2 の質問だけを尋ねてください。 進める前提を述べ、その後、順番に構築します。これをセッションの残りの間保持してください — 再質問しないでください。
- アイデアを一行で — 何が、誰のために提案されているか。これを言い返すことは 最初の整合性チェックでもあります（解決策としてしか述べられないなら、問題はまだフレーミングされていません）。
- ビルド判断のステークスと可逆性 — 安価で可逆的な実験は、高コストで 元に戻しにくい賭けよりもはるかに少ないエビデンスで済みます。これはどれだけのディスカバリーと検証の 厳密さが正当化されるかを決めます（可逆的な判断を過剰に検証するのは、大きな判断を過少に検証するのと同じくらい間違いです）。
- ステージ — 問題がまだ未証明なのか（誰か気にするのか？）、解決策が未解決の 問いなのか（使えるか / 乗り換えるか？）、それとも実行可能性／規模なのか（支払うか、 持続するか？）。これは各段を適切な深さに向けます。
- 市場の成熟度 — これは混雑したカテゴリか？ もしそうなら、最もリスクの高い仮説はほとんど
決して「作れるか」ではありません — スイッチングコストと採用です（なぜ既存製品を離れるのか？）。
これを早くにフラグ立てしてください。最初に検証される仮説が変わり、
pm-competitive-analysisが有効な提案となります。 - すでに手元にあるエビデンス — 既存のリサーチ、データ、顧客との接点。ユーザーがすでに 行ったディスカバリーを再実行しないでください。その上に構築してください。
ステップ 1 — はしごを組み立て、各段でゲートする
はしごを順番にたどります。各段でスキルを core(今すぐ適用)/ offer(名前を挙げるだけで、自動構築しない)/ skip(他所が所有している、またはすでに完了) に分類します — デフォルトで全てのスキルを最大深度で適用しないでください(それは作成側のバンドワゴンです)。
子スキルは、インストール可能なスキル
nameで指定します。インストール済みの場合のみ合成してください。指定されたスキルが存在しない場合は、その段の意図をコアのベストプラクティスとともにインラインで適用し、ブロックするのではなくギャップを記録してください。
段 1 — 問題を特定する · pm-problem-statement (core、最初)
問題を エビデンスを伴うギャップ として固定し、症状や解決策から切り離します(問題 + 結果 + 目標)。これが成立するまで、下流のものは何も信頼できません。ユーザーがエビデンスを提供できない場合は、続行しますが 問題を未検証の仮定としてマーク し、段 3 で解消されるべきものとします — ごまかさないでください。
段 2 — ディスカバリーでリスクを低減する · pm-discovery (core — 仕様書に飛ばないでください)
これは PRD を急ぐデフォルトが飛ばしてしまう段であり、それを飛ばすことがまさに、弱い賭けに対して強い仕様書を生み出す原因です。ディスカバリーは 誰が実際に採用するのか、それが現在のワークフローにどう適合するのか、乗り換えるのか、そして支払うのか を確立します — これが計画の根拠となるエビデンスです。ステップ 0 の重要度に比例させてください(可逆的な判断には軽量な継続的接触、大きく不可逆的な判断にはより深い調査)。ただし 仕様書の前に必ず実施してください。競争の激しい市場では、ここから乗り換えコストのエビデンスが得られます。
段 3 — ユーザーを定義する · pm-personas-jtbd (core)
対象ユーザーをディスカバリーのエビデンスに基づいて根拠づけます — ジョブ・トゥ・ビー・ダンと実際の不満、あらゆる詳細が意思決定に寄与するものとします。人口統計上のフィクションは不要です。この段は段 2 のアウトプットを 消費 します。ディスカバリーがスキップされた場合、ペルソナは推測であり、そのようにラベル付けされるべきです。
段 4 — 最もリスクの高い仮定を検証する · pm-assumption-testing (core — かつ前面に出す)
信念の飛躍 を明らかにします — それが偽であればアイデアが沈むもの — 反証可能な形で表現し、成功基準を事前に設定した、それを答えられる最も安価なテスト を設計します。実現可能性/望ましさのテストを前面に出し、仕様書の下に埋もれさせないでください。 ほとんどのアイデア→計画のケースでは、最もリスクの高い信念は 「対象としている人々が実際にこれを採用し、支払う/乗り換える」 です — したがって コードを 1 行も書く前に実際の行動を確認するペインテッドドア、コンシェルジュ、またはプレセールテスト が、明示的なビルド/ノービルドのゲートとしてここに属するのが通常です。このテストを PRD の埋もれたサブセクションとして位置づける計画は、この段に失敗しています。
段 5 — 最初に何を作るかを優先順位付けする · pm-prioritization (core)
最初のスライスを、戦略/成果にトレースでき、トレードオフを露呈させる 手法で決定します — 見せかけの精密なスコアではなく。優先順位付けは最もリスクの高い仮定が特定された 後 に来ます — ウィッシュリストに対してではなく、検証済みのリスクに対して優先順位付けするのです。
段 6 — 計画を書く · pm-product-spec (core、最後 — かつ比例させる)
ここで初めて仕様書/PRD を書き、その下にあるエビデンスに比例させてください。すべての要件は検証可能に、完全なフロー(ハッピーパスではなく)、明示的なスコープ外、依存関係/制約/仮定のセクション、そして 各仮定が検証済み(段 4)かまだオープンかをトレースする こと。仕様書の役割は、エビデンスとオープンなリスクを 引き継ぐ ことであり、磨かれた要件でそれらをごまかすことではありません。pm-user-story はこの段が所有します(それに委ねてください)。
ラング 7 — 成功を定義する · pm-okrs-kpis (提案 → 指標が重視される場合はコア)
pm-product-spec にはすでに成功指標のセクションが含まれています。計画が第一級の成果指標を必要とする場合は
pm-okrs-kpis を引き込んでください — バニティ指標ではなく、ベースライン/ターゲット + ガードレールを伴う成果です。
これを提案し、ユーザーが成功指標を求めた場合、または仕様の指標に真の厳密さが必要な場合はコアにしてください。
一貫性ルール: 意思決定はラダーを上へ伝播します。ラング 1 で枠組み化された問題、ラング 2 からの エビデンス、そしてラング 4 からの検証済み/未検証の前提は、その上のすべてのラングで再利用されます — 仕様の中でそれらを再審議しないでください。これがアイデアを下から積み上げる全体の要点です。
ステップ 2 — プロダクトレビューによる検証
計画が存在するようになったら、それを pm-product-review（インストールされている場合）に渡してください。これは監査ポリシーを適用します。すなわち、pm-assumption-rigor-audit を自動実行し（常に関連するレンズ — 最もリスクの高い前提がターゲットにされ、反証可能であり、事前に設定された基準を持つ適切な忠実度の手法と一致していたか?）、成果物の種類に応じてルーティングします — 仕様 → pm-spec-quality-audit、指標 → pm-okr-metric-validity-audit、優先順位付け → pm-prioritization-rigor-audit、そしてビルド/ノービルドの判断には pm-decision-quality-audit が提案されます。これは監査ごとに 1 つではなく、優先順位付けされ重複排除された1 つのレポートを返します。指摘事項があれば、ステップ 0 の意思決定に向けて解決してください。pm-product-review がインストールされていない場合は、存在する監査スキルを直接実行するか、ポリシーに照らしてセルフレビューしてください。
ステップ 3 — 戦略 / ローンチのアークを提案する（自動実行しないでください）
検証済みの計画は引き継ぎポイントであり、ゴールではありません。計画がレビューを通過したら、促されずに生成するのではなく、戦略のアークへと続行することを提案してください。すなわち、プロダクトビジョンと戦略（pm-vision-strategy）、競合分析（pm-competitive-analysis — 競争の激しい市場ではこれを強い提案にしてください。スイッチングコストはこのアークが担う戦略的問いであるため）、ロードマップ（pm-roadmap）、市場投入（pm-gtm-plan）、そしてローンチ実験 + アナリティクス（pm-experimentation-ab、pm-analytics）です。次のアークを名指しすることがサービスであり、それを自動生成することは便乗です。
よくある やるべき/やってはいけない パターン
| ❌ やってはいけない | ✅ やるべき |
|---|---|
| アイデアを渡されたらすぐに PRD に飛びつく | まず問題を枠組み化し、仕様の前にディスカバリーでリスクを低減する |
| アイデアに「明らかに」市場があるからとディスカバリーを省く | ステークスに見合ったディスカバリーを実行する — 採用、ワークフロー適合、スイッチングコスト、支払い意欲 |
| 検証テストを PRD のサブセクションとして埋もれさせる | 最もリスクの高い前提のテスト（多くの場合コンシェルジュ/プレセール）を明示的なビルドゲートとして前面に出す |
| 仕様を計画全体にしてしまう | 仕様を最後の、比例したラングとして保ち、エビデンスを引き継がせる |
| 「彼らは支払うか/乗り換えるか」を些細なこととして扱う | 競争の激しい市場では、スイッチングコストを最もリスクの高い前提とし、最初にテストする |
| 機能のウィッシュリストを優先順位付けする | 検証済みのリスクに基づいて優先順位付けし、戦略にトレースし、トレードオフを明示する |
| 単一の指定された成果物のためにこのオーケストレーターを実行する | そのスキルを直接トリガーさせる（明示的なスコープが優先） |
| ビジョン/競合/ロードマップ/GTM を自動生成する | 検証済みの計画で止め、次に戦略のアークを提案する |
| 生成したら完了と宣言する | pm-product-review に渡し、統合された重要度評価済みのレポートを 1 つ受け取る |
ポリシーとの関係
このスキルは、docs/orchestration-policy.md の構成的オーケストレーションのセクション（§9）を PM 業務向けに実行可能な形にしたものです。その検証の相棒は pm-product-review であり、その UX の対応物は ux-design-from-scratch です。このスキルとポリシーが乖離した場合は、ポリシーが支配します — このスキルをポリシーに合わせて更新してください。
出典レッスン（Uxcel）
これはオーケストレーターであり、その実質のほとんどは構成するスキルの中にあります（pm-problem-statement、pm-discovery、pm-personas-jtbd、pm-assumption-testing、pm-prioritization、pm-product-spec、pm-okrs-kpis の出典レッスンを参照してください）。ステージングそのもの、つまりアイデア → 計画であり、構築の前にエビデンスと定義を伴うものは、以下に基づいています。