identify-assumptions-existing

identify-assumptions-existing skill の概要

identify-assumptions-existing は、既存プロダクトに対する機能アイデアを、設計や実装に着手する前にストレステストするためのプロダクト発見スキルです。Value、Usability、Viability、Feasibility の観点から、提案の裏にあるリスクの高い前提を洗い出し、組み込みの devil’s advocate の視点で検証を促します。

このスキルは、磨き込まれた戦略資料ではなく、素早い前提整理が欲しいプロダクトマネージャー、デザイナー、エンジニア、創業者に向いています。機能を進める価値があるか判断したいときや、すでに有望に見えるアイデアの隠れた失敗ポイントを見つけたいときに、identify-assumptions-existing は特に相性が良いです。

主な価値は意思決定の質にあります。「なんとなく良さそう」から「これが成立するために何が真実である必要があるのか」へ、会話を引き上げます。そのため、Strategic Planning、ロードマップの取捨選択、事前リサーチでのリスクレビューに特に役立ちます。

identify-assumptions-existing は何のためのスキルか

すでに機能アイデアがあり、それを現実の制約に照らして圧力テストしたいときに identify-assumptions-existing skill を使います。市場、ユーザー体験、事業、実装のどこでそのアイデアが崩れうるかを明らかにするよう設計されています。

どんな人がインストールすべきか

ラフなプロダクトアイデアを、検証可能な前提に落とし込む作業が多いなら identify-assumptions-existing をインストールしてください。機能提案がチケット、仕様、実験計画になる前に、毎回同じやり方で疑い直したいチームに最も向いています。

何が違うのか

一般的なブレインストーミング用プロンプトと違い、identify-assumptions-existing は PM、デザイナー、エンジニアの 3 役で考えるようモデルに求めます。こうしたクロスファンクショナルなフレーミングにより、盲点を早く見つけやすくなり、各前提に対してより実行可能なテストを引き出せます。

identify-assumptions-existing skill の使い方

インストールして起動する

ソースに示されている repo コマンドから、identify-assumptions-existing install の流れを使います。

npx skills add phuryn/pm-skills --skill identify-assumptions-existing

そのあと、既存プロダクト向けの機能アイデアを添えてスキルを呼び出します。入力が具体的であるほど、前提のリストは精度が上がります。

スキルに適切な入力を与える

identify-assumptions-existing usage のパターンは、次を含めると最も効果的です。

• product または feature 名
• 対象ユーザーセグメント
• 期待する成果
• 機能アイデアそのもの
• platform、timeline、compliance、dependencies などの制約

弱いプロンプトの例: “Analyze my feature.”
強いプロンプトの例: “Stress-test a dashboard export feature for SMB finance admins in our B2B app. Goal: reduce support tickets. Constraints: web only, two engineers, no new data warehouse.”

ソースは正しい順番で読む

identify-assumptions-existing guide を読むときは、まず SKILL.md から始めてください。リポジトリが後から拡張された場合は、追加の文脈として README.md、AGENTS.md、metadata.json、そして rules/、resources/、references/、scripts/ の各フォルダも確認します。この repo では、SKILL.md が主な信頼ソースです。

より良い出力を得るためのワークフロー

実用的な identify-assumptions-existing usage の流れは次のとおりです。

1. プロダクトの文脈と機能アイデアを説明する。
2. Value、Usability、Viability、Feasibility ごとに前提を出すよう依頼する。
3. 各前提について、確信度とテスト方法を求める。
4. 出力を使って、どこから検証するかを決める。

Strategic Planning に使うなら、市場セグメント、事業目標、リリース制約も含めてください。そうすることで、スキルが戦略上のリスクと UX／エンジニアリング上のリスクを切り分けやすくなります。

identify-assumptions-existing skill の FAQ

identify-assumptions-existing は既存プロダクト専用か

はい、それが想定された用途です。このスキルは、ゼロからの自由なコンセプト発想ではなく、既存プロダクト内の機能アイデアをストレステストするよう調整されています。

普通のプロンプトと何が違うのか

普通のプロンプトでも長所と短所は挙げられます。ですが identify-assumptions-existing skill は、リスクを 4 つのカテゴリに整理し、何がうまくいかない可能性があるのか、どの程度確信があるのか、どう検証するのかまで掘り下げます。そのため、次のアクションにつなげやすい出力になります。

identify-assumptions-existing は初心者向けか

はい。プロダクト、対象ユーザー、機能を平易な言葉で説明できるなら使えます。形式的な assumption-mapping フレームワークを知らなくても問題ありませんが、モデルがトレードオフを現実的に判断できるだけの文脈は必要です。

使わないほうがよいのはどんなときか

詳細な UX コピー、実装コード、最終的なリリース計画が必要なら identify-assumptions-existing は使わないでください。これはリスクを特定するためのスキルなので、実装判断の前段で使うのが最適です。

identify-assumptions-existing skill を改善するには

文脈をもっと鋭くする

identify-assumptions-existing の品質を最も左右するのは、ユーザー像と事業目標の具体性です。「AI 検索を追加したい」だけでは、スキルが推測しすぎます。「サポート担当者向けに AI 検索を追加し、繰り返し問い合わせの回答時間を短縮したい」と伝えれば、前提はぐっと実用的になります。

懸念だけでなくテストも求める

ソースでは、何がうまくいかないかだけでなく、それをどうテストするかまで含めるよう指示されています。だからリスクの列挙で止めないでください。インタビュー、プロトタイプテスト、ログレビュー、社内 dogfood チェックのような軽量な検証アイデアも合わせて求めると、出力が批評ではなく計画資料になります。

プロダクトリスクと実行リスクを分ける

最も有用な identify-assumptions-existing skill の出力は、ユーザー価値、導入の摩擦、事業制約、技術的実現性をきちんと分けています。プロンプトがそれらをひとまとめにした曖昧な依頼だと、回答の意思決定性は下がります。制約を明示し、どの前提が最も危険かを優先順位づけできるようにしてください。

最初の結果のあとで絞り込む

まずは 1 回目の結果でスコープを絞り、そのうえでより焦点を絞った機能断片に対してもう一度スキルを実行します。たとえば、1 回目で usability と integration のリスクが出たなら、次は onboarding フローだけ、あるいは data-sync dependency だけを再依頼します。Strategic Planning の議論を鋭くするには、これが最短ルートであることが多いです。