| name | product-discovery |
| description | 要求定義 (PM フェーズ) を進め、ユーザの「やりたい / 困っている」を Outcome > Output で言語化して Lean PRD を docs/prd/<slug>.md に書き出す skill。INSPIRED の 4 リスク (value / usability / feasibility / viability)、Continuous Discovery Habits の Opportunity Solution Tree と Riskiest Assumption Test、Escape the Build Trap の outcome 重視・feature factory 回避を doctrine とする。顧客が自分自身であるパターンも一級扱いし、自己ヒアリングのバイアス除去プロトコルを内蔵する。発火例 — 「〜を作りたい」「〜が欲しい」「アイデアがある」「〜って作るべき?」「PM 視点で整理して」「要求まとめて」「PRD 書いて」「PRD ドラフト」「discovery 回したい」「opportunity 整理」「outcome 何にする?」「riskiest assumption は?」「自分用ツール作りたい」。要件定義 (spec / 要件) を直接書く依頼、実装方針の検討、UI 仕様の確定、コード生成、API 設計、データモデル詳細は本スキル範囲外で、それぞれ requirements skill / design / data-modeling skill 等に委ねる。ドラフト後は別 agent の prd-review skill にレビューを渡し、合意済み PRD を入力に requirements skill を起動する想定。アドホックに要求整理するより本スキルを優先する理由は、build trap を防ぎ outcome / opportunity / assumption の三層を欠落なく PRD に揃え、下流レビュー・要件定義への引き継ぎ品質を担保するため。 |
| allowed-tools | ["Read","Write","Edit","Glob","Grep","Bash","WebFetch","WebSearch","AskUserQuestion","TaskCreate","TaskUpdate","TaskList","Agent"] |
product-discovery
要求定義（要件定義の前段、PM フェーズ）を進める skill。ユーザの発話を起点に Outcome → Opportunity → Assumption の三層に整理し、最終的に Lean PRD を docs/prd/<slug>.md として書き出す。下流の prd-review skill（別 agent）でレビューを受けて revise し、合意後に requirements skill（要件定義）を起動するハンドオフを前提にする。
なぜこの skill が必要か: 開発の失敗のほとんどは「要件 (spec) の精度不足」ではなく「要求 (request) の段階で outcome と opportunity を捉え損ねたこと」に起因する。INSPIRED / Continuous Discovery Habits / Escape the Build Trap の 3 書はいずれも、build trap（output 中心の量産）を抜けるには discovery を独立した工程として持てと説く。本 skill はその discovery を 1 セッション内で再現する PM 補助線である。
詳細レイヤ:
references/inspired-cdh-build-trap.md — 3 書を本 skill 用に蒸留した doctrinereferences/customer-is-self.md — 顧客が自分自身のパターンの bias 除去プロトコルreferences/triage-decision.md — 起動 / 別 skill へ振る判定木references/handoff-protocol.md — prd-review / requirements への引き渡し仕様assets/prd-lean.md.tpl — PRD テンプレート
いつ使うか
以下を強くトリガとする:
- 「〜を作りたい / 欲しい / 試したい」「アイデアがある」「ぼんやり構想中」
- 「これって作るべき?」「やる価値ある?」「PMF ありそう?」
- 「PM 視点で整理して」「要求 / requirement をまとめて」「PRD 書いて / ドラフト」
- 「discovery 回したい」「opportunity 整理」「outcome 何にする?」
- 「riskiest assumption は?」「value risk チェックして」
- 「自分用ツール作りたい」「自分が困ってるから」（顧客=自分自身）
- slash command
/product-discovery または明示で本 skill 名を呼ばれた時
使わない場面:
- 既に PRD / 要求が固まっており、仕様 (spec / 要件) を書きたい —
requirements skill
- PRD を書き終え、レビューにかけたい —
prd-review skill
- 単なる実装着手の段取り — feature-dev / design 系
- 単純な事実調査・ライブラリ比較 —
research-practices skill
- テスト・コード品質の話 —
test-review / simplify 等
迷う境界は §Phase A の triage で振り分ける。
入力
- ユーザの自然文発話（「〜したい」「〜で困っている」「〜って作るべき?」など断片で可）
- 任意: 既存 PRD, ノート, Linear issue リンク, 音声書き起こし などの素材
- 任意: 顧客タイプ指定（外部 / 自分自身 / 混在）。未指定なら Phase A で確認
PRD 出力先は 常に docs/prd/<slug>.md（Linear など外部ツールへの転記はユーザが手動 or 将来の Linear MCP 連携拡張で行う想定。本 skill は file-based に閉じる）。
ワークフロー
[Phase A: triage] ── 顧客 / 起動可否 / 既存 PRD diff か新規か
↓
[Phase B: outcome framing] ── 動かしたい outcome を 1 つに絞る (Build Trap 防御)
↓
[Phase C: opportunity] ── OST 軽量版で 2〜4 の opportunity を立てる
↓
[Phase D: assumption] ── 4 リスク + riskiest assumption + 直近で打つテスト
↓
[Phase E: synthesis] ── assets/prd-lean.md.tpl に流し込み docs/prd/<slug>.md に書く
↓
[Phase F: handoff] ── prd-review skill 起動を提案、合意後 requirements 案内
Phase A: triage（ユーザ対話 1 回）
AskUserQuestion を 冒頭で 1 回だけ 使い、以降は本文に [ASSUMED: ...] [TO_VALIDATE: ...] を埋めて完走する（discovery の勢いを切らさない）。
冒頭 1 回で揃えるべき情報は以下。複数の問いを 1 ターンに束ねる:
- change_type 相当: 新規プロダクト / 新規機能 / 既存機能の改善 / 既存 PRD の改訂 のいずれか
- 顧客タイプ: 外部ユーザ / 自分自身 / 混在
- 不可逆性 / blast radius: 本人のサンドボックス / 個人公開ツール / 業務影響あり
- 既存素材の有無: ノート, 音声, 過去 PRD, 競合プロダクトのリンクなど
判定の詳細は references/triage-decision.md。triage 結果が「本 skill 範囲外」なら（例: 仕様レベルの要件を書きたい、テストレビューをしたい）速やかに該当 skill を案内して終了する。
triage 結果は PRD §Meta に記録する。
Phase B: outcome framing（Build Trap 防御）
「何を作るか」を聞く前に「何を動かしたいか」を聞く。これを飛ばすと build trap に直行する。
確認する観点:
- 動かしたい指標 / 状態変化（「自分が週 3 回やっていた手作業を 0 にする」「家族が翌日にも料理を再現できる」など、観測可能な行動 or 数値）
- 現状値 / 直近の悲しさ
- 戦略・大方針との接続（個人プロジェクトなら「自分の今の生活で何を優先しているか」でも可）
- もし何もしなかったら 3 ヶ月後どうなるか（do-nothing baseline）
「outcome が thin」（output を言い換えただけ）と検出したら Phase B で停滞させて深掘りする。代表アンチパターン:
- 「Slack bot を作りたい」→ 動かしたい outcome は? 何を Slack 経由で速くしたいのか
- 「ダッシュボードが欲しい」→ どの意思決定を速くしたいのか
- 「LLM agent を組みたい」→ 結果として何を 5 分から 30 秒にしたいのか
詳細な doctrine は references/inspired-cdh-build-trap.md の §Build Trap 節。
Phase C: opportunity shaping（OST 軽量）
Continuous Discovery Habits の Opportunity Solution Tree を 軽量版 で適用する。書き出すのは PRD ではなく頭の中の枝分かれ。
- desired outcome（Phase B 結果）の下に opportunity を最大 4 件 並べる（多すぎたら統合 / 落とす）
- 各 opportunity に対し solution candidate を 1〜3 件 ずつ持つ
- 「このソリューションがダメなら次に何を試すか」が言える状態にする（早期固定の回避）
opportunity の良し悪しの目安:
- specific instance から導かれている（「家族が前にこう困った」のような 具体痛点 が起点）
- 動かしたい outcome に明確に紐づく
- 顧客が今すでにやっている代替行動が観察できている（CDH の「customer は今何をして埋め合わせているか」）
アンチパターン:
- opportunity が「機能名」になっている（それは solution）
- opportunity が複数 outcome を兼ねている（細分化しろ）
Phase D: assumption + riskiest test
INSPIRED の 4 リスクで未検証前提を棚卸しする:
| リスク | 問い |
|---|
| value | 顧客はそもそも欲しがるか / 使ってくれるか |
| usability | 使いこなせるか / 認知負荷は越えられているか |
| feasibility | 技術的に作れるか / 期間内に出せるか |
| viability | プロダクト全体・ビジネス・自分の生活で成立するか（個人なら維持コスト含む） |
各リスクで「現時点で 検証されていない 一番痛い前提」を 1 つずつ書く。さらに:
- riskiest assumption: 上記から「これがウソなら全体が崩れる」を 1 つ選ぶ
- 直近で打つテスト: その前提を 1 週間以内に falsify するなら何をするか（簡易プロトタイプ / 自己観察ログ / 紙芝居 / インタビュー 1 人）
CDH の Assumption Mapping を圧縮した形。詳細は references/inspired-cdh-build-trap.md §Assumption Mapping。
顧客=自分自身の場合、ここで bias check を必ず通す（次節 + references/customer-is-self.md）。
Phase E: synthesis（PRD 起こし）
assets/prd-lean.md.tpl を読み込み、Phase A〜D の内容を埋めて docs/prd/<slug>.md に書き出す。
<slug> は input から kebab-case で 2〜4 語の識別子を AI が生成（例: weekly-recipe-bot）- 既存ファイルがある場合は 改訂モード: 既存内容を読んで diff として書き、§Decision log にエントリを追加
- 抽象度を要求レベルに保つ: 関数シグネチャ, API 仕様, データスキーマ, 画面遷移詳細などの spec / 設計詳細 を本文に書かない（要件定義 / 設計フェーズの仕事）
- 不明点は
[TO_VALIDATE: 具体的な質問] で本文に残す（要件定義へ持ち越す）
- §Anti-goals（「これが見えたら逆効果」）を必ず 1 件以上書く（success metric の hack 防止）
Phase F: handoff
完了報告でユーザに以下を渡す:
- 生成 / 更新した artifact path（
docs/prd/<slug>.md）
- 要約 3 点（outcome / 上位 opportunity / riskiest assumption）
- 次の動き:
prd-review skill にレビューを依頼する案内（別 agent で起動する想定。本 skill からは自動起動しない）- レビュー指摘で revise が必要なら本 skill を再起動 → §Decision log に追記
- PRD が approved になったら
requirements skill を起動して要件定義へ
- 残った
[TO_VALIDATE] の数（あれば内容）
ハンドオフ仕様の詳細は references/handoff-protocol.md。
ユーザターン最小化の原則
- ユーザに尋ねるのは Phase A の triage 1 回のみ が既定
- 例外: triage 結果が本 skill 範囲外（→ 別 skill 案内のための確認）/ 既存 PRD と矛盾する入力 / 上限超過の
[TO_VALIDATE]
- それ以外は Phase A→B→C→D→E→F を 1 ターンで完走 して完了報告
- 不明点は
[ASSUMED: ...] [TO_VALIDATE: ...] を本文に埋め、上限内（Lean PRD なら [TO_VALIDATE] 上限 5 件）なら自動進行
顧客=自分自身モード
個人プロダクト・社内ツール・実験コードなど、顧客が自分自身（または家族・身近な少人数）であるケースはむしろ多数派として扱う。「customer interview しろ」式の杓子定規を持ち込まず、自己観察のままで rigor を担保する。
最低限の bias check（詳細プロトコルは references/customer-is-self.md）:
- specific instance: 直近 2 週間で「実際に起きた瞬間」を最低 1 つ書ける
- inversion: 「自分でない別の人だったらこの outcome を欲しがるか」を仮定で答え、答えが no ならスコープを「自分専用」と Meta に明記
- alternative observed: 今すでにやっている代替行動を 1 つ以上挙げる
- viability self-check: 維持コスト（自分が運用できるか / 半年後も触るか）を 1 行で書く
これらが埋まらない PRD は §Self-check を weak とマーキングして prd-review に渡す。
出力
| パス | 条件 | 内容 |
|---|
docs/prd/<slug>.md | 常時 | Lean PRD（assets/prd-lean.md.tpl 由来） |
| ユーザへの完了報告 | 常時 | artifact path / 3 点要約 / handoff 案内 |
PRD 自体に self-check ブロックを内蔵する（prd-review が読む契約）。
このスキルがやらないこと
negative space は 動詞ではなく成果物 で書く（skill-builder の dual-meaning-verb-by-action 原則）:
- 要件 (spec) ファイル
z/{task}/requirements.md 相当 を生成しない（→ requirements skill）
- 設計ドキュメント / 関数シグネチャ / API 定義 / Prisma schema を本文に書かない（→ design / data-modeling）
- コード / テスト / config を生成しない
prd-review skill を自動呼び出ししない（別 agent で明示起動する設計; 自動チェーンは討論の独立性を壊す）- Linear / Notion / Jira への直接書き込みを行わない（本 skill は file-based。MCP 連携が必要なら拡張で）
- discovery を打ち切る判断（「やめる」）を skill 単独で出さない — riskiest assumption が崩れた時の判断はユーザに委ねる
連携 skill
| skill | 役割 | 起動タイミング |
|---|
prd-review（別 agent / 別 skill） | PRD のレビュー（must / imo） | 本 skill 完了後ユーザが明示起動 |
requirements | 要件定義（spec, EARS, 影響範囲） | PRD approved 後にユーザ起動 |
research-practices | 競合 / 先行事例 / ライブラリ調査 | Phase B/C/D で外部根拠が必要なときのみ |
skill-builder | 本 skill の trigger / quality 改善 | 本 skill の改修時 |
prd-review / requirements は本 skill から自動起動しない（auto mode 親和とレビュー独立性のため）。
言語
CLAUDE.md に従い、ユーザとのやり取りおよび PRD 本文は 日本語。slug と frontmatter / メタキーは英小文字 + ハイフン。
リファレンス
references/inspired-cdh-build-trap.md — 3 書の doctrine 蒸留references/customer-is-self.md — 顧客=自分自身パターンの bias 除去references/triage-decision.md — Phase A 判定木と別 skill への振り分けreferences/handoff-protocol.md — prd-review / requirements への引き継ぎ仕様assets/prd-lean.md.tpl — Lean PRD テンプレートevals/product-discovery-trigger.json — trigger eval 雛形（skill-builder Mode B で利用）
