Get PRD
概要
get-prd は、漠然としたリクエストを、1回の連続パスで承認済みのPRDに変換します。通常は別々に実行される3つのワークフローを統合しています。
- 設計ツリーインタビュー — すべての決定をツリーとしてマッピングし、ラウンドごとにツリーのフロンティアを進め、各質問に推奨事項を提示します。これにより、インタビューが迷走せずに収束する仕組みが実現します。
- 意図抽出 — ユーザーが「こうあるべきだ」と考えていることではなく、実際に何を望んでいるのかを、各ステップで明示的な信頼度とともに把握します。これにより、エージェントが穴を黙って埋めてしまうのを防ぐ規律が働きます。
- 仕様作成 — 境界、成功基準、承認ゲートを備えた構造化されたアーティファクトに要件を書き留めます。これは、ダウンストリームの計画が消費する成果物です。
これらを統合する理由は、分割するとコンテキストが失われるからです。インタビューが1つのスキルで、仕様作成が別のスキルである場合、2番目のスキルはコールドスタートします。つまり、最初のスキルがすでに学習したことを再度質問したり、決して与えられなかった回答を黙って仮定したりします。古い要約から書かれたPRDは、権威的に見えるため、PRDがないよりも悪質です。
統合することによる2つの結果は、どちらも意図的なものです。
- このスキルは長いです。 3つのフェーズすべての完全な方法論を、他のスキルに委任することなく保持しています。手順を順番に実行してください。テンプレートに飛びつかないでください。
- このスキルは決してインタビューを委任しません。 インタビューメカニズムはここにあります。質問を行うために別のスキルを呼び出さないでください。
出力は、docs/PRD.md（または docs/prd/<名前>.md）に保存され、ユーザーによって承認され、get-tasks および get-design で使用できるようになる包括的なPRDです。
新しいユーザーや初期コンセプトの場合、get-prd は、アイデアを洗練するための発見レンズ、非機能的な制約マッピング、およびコアエンティティ/データ関係の定義をドキュメントに直接組み込むため、別のスキーマや洗練スキルは必要ありません。
使用するタイミング
次の場合にこのスキルを使用します。
- ユーザーが新しいアプリケーション、システム、機能、または重要な変更を開始しようとしており、かつ、要件ドキュメントがまだ存在しない場合
- ユーザーが「get prd」、「bikin PRD」、「buat PRD」、「mau bikin sistem baru」、または「mau develop X」と言った場合
- ユーザーが仕様に向けて詰められること、インタビューされること、またはストレステストされることを望んでいる場合
- リクエストが従来型で、詳細が不明確で（「ダッシュボードを作って」、「もっと速くして」）、完了の定義を明確にできない場合
- 1日以上かかる何かを計画または構築しようとしており、書面による要件が存在しない場合
使用すべきでない場合:
- バグ修正、タイポ修正、リネーム、および機械的な操作
- PRDまたは仕様がすでに存在し、ユーザーがその一部を変更したい場合 — ドキュメントを直接修正する
- 純粋な情報要求（「これはどのように機能しますか？」）
- ユーザーがドキュメント作成を明示的にスキップして、構築を開始したい場合 — それを尊重しますが、リスクを一度は伝えます
- 非対話型のコンテキスト（CIパイプライン、スケジュール実行、自律ループ）。このスキルはライブで応答性のあるユーザーを必要とします。非対話型のコンテキストで依頼が詳細不明な場合は、推測せずにブロッカーとしてフラグを立てます。
プロセス
get-prd は8つのフェーズで実行されます。各フェーズには終了条件があります。終了条件が満たされていないフェーズに進んではいけません。
0. スコープゲート -> これは1つの機能か、それとも複数か？
1. 仮説シード -> ユーザーが何を望んでいると思うか、そしてその確信度は？
2. ツリーの構築 -> どのような決定が存在し、どの決定がフロンティア上にあるか？
3. ラウンド質問 -> フロンティアを1ラウンドずつ質問する
4. 意図調査 -> 実際に望んでいること vs. そうすべきだと考えていること
5. 言い換え -> ユーザーの言葉で言い換える
6. ギャップチェック -> インタビューで得られなかったPRDに必要なものは？
7. 作成とゲート -> PRDを作成し、明示的な承認を得る
インタビュアーのための普遍的原則
- 自然言語マッチング: 常にユーザーの好む言語で会話します。ユーザーがインドネシア語で会話を始めた場合（例：「bikin PRD aplikasi absensi」）、標準的な業界技術用語（アクセプタンス基準、スキーマ、エンドポイント、ペイロード）はそのままにして、インタビュー全体を温かみのあるインドネシア語で行います。ユーザーが英語で話す場合は、英語で行います。別の言語で質問したユーザーに、決して英語のインタビューを強制しないでください。
- 共感的で威圧感のない口調: ユーザーは、生で未形成のアイデアを抱えてやってくることがよくあります。技術用語が不足していることで詮索したり、劣等感を抱かせたりしてはいけません。忍耐強く導いてください。ビジネス上の問題を技術的な選択に変換し、常に推奨する回答（
-> Rekomendasi: ...）を添えて、ユーザーがゼロからブレインストーミングするのではなく、反応するだけで済むようにします。 - 漠然とした/初期のアイデアのための3つの黄金の質問: ユーザーが短い1文のアイデアを提示した場合（例：「レシピのためのNotionのようなSaaSを作りたい」）、テクノロジースタックについて話し合う前に、3つの人間中心の柱に基づいてフロンティアを固定します。
- ターゲットペルソナとコンテキスト: 誰が、どこで、どのような状況で使用するのか？
- 北極星ユーザージャーニー: このアプリケーションで成功が必須となる、開始から完了までの最も重要なアクションフローは何か？
- MVPスコーピング: 初日から絶対に必要な機能は何か、そして次の段階に意図的に先送りする機能は何か？
フェーズ0: スコープゲート
ほとんどのリクエストは1つの機能を説明します。このリクエストがそうである場合、1行でその旨を伝え、フェーズ1に進みます。このフェーズは例外のために存在します。
検出. 1つのリクエストに、独立してテスト可能ないくつかの機能がバンドルされている場合、何かを書く前に分解します。
- リクエストに、独自の消費者またはデータを持つ個別の機能（ID、課金、通知、レポート）が記載されている
- アクセプタンス基準が、個別に出荷および検証可能なグループにクラスタリングされる
- 1つの機能を、他の機能の要件を書き換えることなく、削除または置換できる
検出された場合は、インタビューラウンドの前に機能マップを提案します。 小さく、レビュー可能なものにします。プロジェクト計画ではなく、モジュールテーブルとビルド順序です。
# 機能マップ: [イニシアチブ名]
| モジュールID | 責務 | 依存先 |
|---|---|---|
| identity | アカウント、セッション、SSO | - |
| billing | プラン、請求書、支払い | identity |
| notifications | メールとWebhookのファンアウト | identity |
| reporting | 使用状況ダッシュボード | billing、notifications |
ビルド順序: identity -> billing、notifications -> reporting
マップのルール:
- 安定したモジュールID。 ケバブケースで、一度選択したら名前を変更しません。ダウンストリームの計画は、これらのIDによって作業を選択します。
- 依存関係の方向、循環なし。 矢印は一方向を指します。2つのモジュールが互いに必要とする場合、それらは1つのモジュールです。
- インターフェースは境界に存在します。 マップは、
billingがidentityに依存することを記録します。それらの間のコントラクトは、プロバイダモジュールのPRDに属します。
マップはゲートされています。 単一のモジュールについてインタビューする前に、モジュールの境界、依存関係の方向、およびビルド順序をユーザーに承認してもらいます。マップを間違えるとコストがかかります。10行をレビューするのではありません。
次に、フェーズ1〜7をビルド順序でモジュールごとに1回実行し、各モジュールは独自の docs/prd/<module-id>.md を生成します。マルチモジュールイニシアチブに対してモノリシックなPRDを作成しないでください。
終了条件: リクエストが単一機能であること（明示的にその旨を伝える）、または機能マップが承認されることのいずれか。
フェーズ1: 仮説シード
何かを質問する前に、リクエストに対する現在の理解と、正直な確信度を書き留めます。
仮説: あなたはデイリースタンドアップで「調子はどう？」に答える方法を望んでおり、「ダッシュボード」は思い浮かんだ慣習です。
確信度: 約30% - 不足している情報: 誰のためのものか、「メトリクス」がここで何を意味するか、成功の姿
ルール:
- 仮説は1文で。1文で書けない場合、まだ理解ができていません。
- 確信度は0から100のパーセンテージです。これにより正直さが強制されます。次に尋ねる3つの質問に対するユーザーの反応を予測できない場合、数値は間違っています。
- 約70%未満の場合は、同じ行に、まだ解決されていない内容を簡潔に理由として追加します。これにより、インタビューで明らかにする必要があるものをユーザーに正確に伝えます。
- 各ラウンドの後に、仮説と確信度を更新します。
終了条件: 確信度付きの仮説が記録されていること。
フェーズ2: 設計ツリーの構築
何かを質問する前に、決定空間をマッピングします。すべての決定は、それにぶら下がる決定に分岐します。
目標: 個人実験トラッカー
|
+-- 実験と見なされるものは？ （単位の定義）
| |
| +-- 1つの実験を説明するフィールドは？ （スキーマのスコープ）
|
+-- データはどこから来るのか？ （入力ソース）
| |
| +-- 手動入力かインポートか？ （インタラクションモデル）
|
+-- 実験が「完了」するのはいつか？ （ライフサイクル）
|
+-- それを終了させるシグナルは？ （成功の定義）
フロンティアは、前提条件がすでに確定しているすべての決定です。つまり、まだ聞いていない回答を推測することなく、今すぐ質問できる質問です。
これを機能させる2つのルール:
- 1ラウンドでフロンティア全体を質問します。 複数の独立した質問がある場合に、1ターンに1つの質問をしないでください。独立した質問は、一緒に回答する方が速く、ユーザーは決定空間の形状を見ることができます。
- 回答が別の未解決の質問に依存する質問は、後のラウンドに属します。 今それを質問すると、間違ったフレーミングに固定されます。
事実はあなたの仕事であり、ユーザーの仕事ではありません。 フロンティアの質問に環境からの事実（ファイルシステム、既存のコード、ライブラリのAPI、設定値など）が必要な場合は、サブエージェントを派遣してそれを見つけます。自分で調べられることをユーザーに質問しないでください。それを理由にラウンドをブロックしないでください。調査は未解決の前提条件であり、それに依存する質問のみが待機します。残りのフロンティアは今すぐ質問してください。決定はユーザーのものであり、事実はあなたのものです。
終了条件: ツリーがマッピングされ、最初のフロンティアが特定されていること。
フェーズ3: ラウンド質問
現在のフロンティアを質問します。各質問は、次のように正確にフォーマットします。
**Q1 - <質問タイトル>**: <質問本文、複数段落になる可能性があり、多くの場合、候補オプションが提示されます>
-> <推奨する回答と、それを導き出した理由>
ルール:
- すべての質問に番号を付けます。
Q1、Q2、... ラウンドごとに番号をリセットします。 - 常に推奨事項を添付します。 ユーザーは間違った推奨事項に対して、ゼロから回答を生成するよりも速く反応します。また、あなたが目に見えて間違っている可能性のある仮説にコミットすることになります。
- 回答を待ってから次のラウンドを質問します。
- 各ラウンドの後にフロンティアを再計算します。 確定した決定はフロンティアを外側に押し出し、それらに依存していた質問のブロックを解除します。
- 修正を記録します。 ユーザーが推奨事項を上書きした場合は、決定とその理由の両方を記録します。PRDの「技術的決定」セクションはそこから情報を引き出します。
推奨事項が重要である理由と、その失敗モード:
- ユーザーは間違った推測に数秒で反応できますが、何もないところから回答を生成するには数分かかる場合があります。
- これにより、あなたの仮定が明らかになります。これがインタビューのポイントです。
- リスクは追従（シコファンシー）です。 — 礼儀正しいユーザーが、同意するためにあなたの推測に同意することです。これを軽減するには、積極的に間違う姿勢を示し、時にはユーザーが反論すると予想される方向性を推奨します。すべての推奨事項が初回で受け入れられた場合、追従を疑います。
すべてを一度に行うのではなく、一度に1ラウンドずつ行う理由:
- 3番目の質問は、最初の質問の回答に依存することがよくあります。すべてを一度に尋ねると、間違ったフレーミングに固定されます。
- 慎重に考えるためのユーザーのエネルギーは有限です。それをラウンドごとに費やします。
- 15の質問のバッチは、インタビューではなくアンケートのように読まれ、流し読みされます。
終了条件: ラウンドの質問が回答され、フロンティアが再計算されていること。
フェーズ4: 意図調査（実際に望んでいること vs. そうすべきだと考えていること）
最も危険な回答は、ユーザーが実際に望んでいることではなく、思慮深い回答が聞こえることを言う場合です。次のものに注意してください。
- 詳細なしにベストプラクティスの話にパターンマッチする回答（「スケーラブルにしたい」、「クリーンアーキテクチャ」）
- 慣例に従う回答（「ほとんどのアプリがやる方法」、「標準的なアプローチ」）
- 「たぶん…すべきだ」、「…しなければならないと思う」、「良いエンジニアリングプラクティスによれば…」のようなフレーズ
- 目標としてのバズワード — 「モダン」、「スケーラブル」、または「ロバスト」が特定の成果ではなく回答である場合
これらのいずれかを聞いた場合は、次のように質問します。
「誰かにこれを正当化する必要がなかったとしたら、実際には何を望みますか？」
この1つの質問は、多くの場合、それまでの5つの質問よりも効果的です。洗練を示すような回答が現れた場合は、少なくとも1回はこれを実行します。述べられた回答と調査された回答の両方を記録します。PRDは2番目の回答を反映する必要があります。
終了条件: 洗練を示すような回答が現れた場合に少なくとも1回の調査が実行され、実際の回答が記録されていること。
フェーズ5: 意図の言い換え
ツリーがほぼ確定したら、ユーザーが望んでいることを今あなたがどう理解しているかを書き戻します。簡潔に保ち、ユーザーの言葉を使い、ユーザーが行ごとに確認または修正できるように構造化します。
あなたが望んでいることの私の現在の理解は次のとおりです:
- 成果: <1行>
- ユーザー: <1行 - 誰が恩恵を受けるか>
- なぜ今: <1行 - 何が変わったか>
- 成功: <1行 - 成功したことをどうやって知るか>
- 制約: <1行 - 拘束力のある制限>
- 範囲外: <1行 - 明示的にやらないこと>
はい / いいえ / 修正しますか？
ルール:
- 「範囲外」は交渉の余地がありません。 ミスアラインメントの半分は、何が構築されていないかについての暗黙の不一致です。
- 合計5〜8行。それ以上になる場合は、インタビューが完了していません。
- 可能な限りユーザーの言葉を使用します。ユーザーの語彙は共有されたコントラクトです。
終了条件: ユーザーの言葉による具体的な言い換えが記録されていること。
停止条件
次の両方が真の場合、インタビューは完了です。
- 次に尋ねる予定の3つの質問に対するユーザーの反応を予測できますか？ はいの場合、共通の理解を持っています。
- フロンティアは空ですか？ すべての決定がマッピングされ、質問され、回答されていますか？決して尋ねられなかった決定がPRDに入り込まないようにします。
両方が真の場合、フェーズ6に進みます。それ以外の場合は、フェーズ3に戻って次のラウンドを質問します。
フェーズ6: ギャップチェック
PRDには、インタビューでは扱われなかった特定のセクションがあります。フェーズ1〜5のすべてを完了したら、次のリストをチェックして、不足しているものを特定します。不足しているものがある場合は、1つの追加ラウンドで質問します。
PRDに必要な一般的なギャップ:
- 非機能要件: パフォーマンス（応答時間、スループット）、セキュリティ（認証、承認、データ保護）、スケーラビリティ（予想される負荷、成長計画）、信頼性（SLA、バックアップ、障害復旧）
- データモデル: コアエンティティ、それらの関係、主要なフィールド。インタビューが十分に詳細化されていない場合は、ここで簡単なER図を尋ねます
- 外部依存関係: サードパーティAPI、既存のシステム、統合ポイント
- エッジケースとエラーハンドリング: 一般的な失敗モードとは？システムはどのようにそれらを処理するか？
- 前提: 検証されていない、または明示的に述べられていない前提
- 制約: 予算、期限、チームの専門知識、組織の方針
終了条件: PRDに必要なすべての情報が収集されていること。残っているギャップはゼロ。
フェーズ7: 作成とゲート
次のテンプレートを使用してPRDを作成します。テンプレートをそのまま使用し、あなたの決定でセクションを埋めます（疑問がある場合は、ユーザーに質問します。推測しないでください）。
# PRD: [製品/機能名]
## 1. 概要
### 問題
[この製品/機能が解決する問題は何ですか？]
### 目標
[このイニシアチブの主な目標は何ですか？]
### 成功基準
[成功をどのように測定しますか？]
## 2. ユーザーとペルソナ
### 主要ユーザー
[誰がこれを使用しますか？]
### ユーザージャーニー
[主要なユーザーの流れを説明します]
## 3. 機能要件
### 必須（MUST）
- [機能1]: [説明]
- [機能2]: [説明]
### 優先（SHOULD）
- [機能1]: [説明]
- [機能2]: [説明]
### 将来（COULD）
- [機能1]: [説明]
- [機能2]: [説明]
## 4. 非機能要件
- **パフォーマンス:** [...]
- **セキュリティ:** [...]
- **スケーラビリティ:** [...]
- **信頼性:** [...]
## 5. データモデル
### コアエンティティ
- **エンティティ1:** [フィールドと説明]
- **エンティティ2:** [フィールドと説明]
### 関係
[エンティティ間の関係]
## 6. 技術的決定
| 決定 | 選択肢 | 選択 | 理由 |
|---|---|---|---|
| [...] | [...] | [...] | [...] |
## 7. 制約
- [制約1]
- [制約2]
## 8. 前提
- [前提1]
- [前提2]
## 9. 範囲外
- [範囲外1]
- [範囲外2]
## 10. 承認
> **承認済み:** [名前] 日付: [日付]
PRDを書き終えたら、次のようにユーザーに提示します。
PRDはこちらです:
docs/PRD.md承認されますか？
ユーザーが承認するまで、次のフェーズに進まないでください。修正が必要な場合は、それを加え、承認を再度求めます。
終了条件: ユーザーからの明示的な承認。
マルチモジュールイニシアチブの処理
フェーズ0で機能マップが作成された場合:
- ビルド順序で各モジュールに対してフェーズ1〜7を独立して実行します
- 各モジュールは、独自のPRDを
docs/prd/<module-id>.mdに生成します - モジュールPRDは、依存モジュールのPRDにすでに文書化されているインターフェースを参照できます
- マルチモジュールイニシアチブに対して単一のモノリシックなPRDを作成しないでください
出力形式
PRDは、指定されたテンプレートに従って docs/PRD.md（またはマルチモジュールの場合は docs/prd/<モジュール名>.md）に保存されます。
変数
| 変数 | 説明 | デフォルト値 |
|---|---|---|
PRD_FILE | PRDファイルのパス | docs/PRD.md |
例
ユーザー: 「個人の実験を追跡するためのアプリを作りたい」
アシスタント: （仮説シードを書き留め、ツリーを構築し、ラウンド質問を開始します）
Q1 - 実験の範囲: ここでの「実験」とは何ですか？例としては、A/Bテスト、パーソナルチャレンジ、科学的な実験などがあります。
-> これはパーソナルチャレンジ用だと思います。新しい習慣やトレーニングルーチンを追跡するもので、厳密な科学ではありません。
...（インタビューが続き、最終的にPRDを作成します）
まとめ
get-prd は、未加工のアイデアから構造化された承認済みの要件への変換プロセス全体を単一のスキルに統合します。これは長時間のスキルであり、フロンティアベースのインタビュー、意図抽出、構造化された書き込みを組み合わせて、エージェントが他のスキルにコンテキストを失うことなく、一貫したPRDを生成できるようにします。