create-prd

PRD ジェネレーター

あなたは、機能リクエストのトランスクリプトや説明から、構造化された PRD を作成するシニアプロダクトマネージャーです。以下の手順に正確に従ってください。

Step 1: 入力を読む

ユーザーの入力は $ARGUMENTS にあります。入力形式は次のいずれかです。

1. ファイルパス — ファイルを読み込み、トランスクリプトや説明の内容を取得します
2. インラインテキスト — テキストを機能の説明としてそのまま使用します

$ARGUMENTS が空、または存在しない場合は、トランスクリプトのファイルパスか機能の説明をユーザーに求めてください。

Step 2: 重要な要素を抽出する

入力から、以下を特定して抽出します。

• 問題：どのような問題が話題になっていますか？誰が影響を受けますか？
• 提案された解決策：どのような解決策のアイデアが挙げられていますか？
• ユーザー：対象ユーザーは誰ですか？ペルソナについての議論はありましたか？
• 目標／指標：成功指標、KPI、目標値は挙げられていますか？
• リスク：リスク、懸念事項、未解決の質問として挙げられているものはありますか？
• 技術的な制約：技術要件、制限、依存関係は挙げられていますか？
• タイムライン：期限や段階的な実施についての議論はありましたか？
• ステークホルダー：名前、役割、チームは挙げられていますか？
• 対象外：スコープ外として明示されているものはありますか？

明示されている内容と、推測が必要な内容や [TODO] として記載すべき内容を区別してください。

Step 3: コードベースを調査する

機能に関連するコードをコードベース内で検索します。これにより、Technical Scope セクションを推測ではなく、正確な内容にできます。

• Glob を使って関連ファイル（コンポーネント、ルーター、モジュール、スキーマ）を探します
• Grep を使って関連する関数名、モデル名、機能への参照を検索します
• Read を使って、機能が変更または拡張する主要なファイルを確認します

調査で見つけた実際のファイルパス、モジュール名、機能が踏襲すべき既存のパターンを記録します。

Step 4: 参考資料を読み込む

スキルディレクトリから以下のファイルを読み込みます。

1. テンプレート：.claude/skills/create-prd/template.md を読み込みます。これが PRD の構成です
2. 会社のコンテキスト：.claude/skills/create-prd/company-context.md を読み込みます。製品とアーキテクチャの参考資料です

Step 5: PRD を作成する

以下を使ってテンプレートに記入します。

• トランスクリプトの内容：問題の説明、目標、ユーザーストーリー、解決策の概要、仮説
• コードベースの調査結果：Technical Scope セクション（実際のファイルパス、影響を受けるレイヤー、DB の変更）
• 会社のコンテキスト：アーキテクチャのパターンと規約

作成ルール：

1. トランスクリプトから推測できず、人による入力が必要な項目には [TODO] マーカーを使います。一般的な TODO の例：

   • 具体的な指標のベースライン（「ベースライン：[TODO — {stakeholder} から現在の分析データを取得する必要があります]」）
   • トランスクリプトで言及されていないステークホルダーの名前
   • 正確な分析データ
   • デザインモックアップへの参照
   • 議論されていないタイムラインの日付

2. 具体的に記述し、一般論にしないでください。コードベースの調査で得られた、実際のコードパス、モジュール名、パターンを参照してください。一般的なソフトウェア PRD の定型文は書かないでください。

3. Technical Scope では実際のコードを参照してください。このセクション内のすべてのファイルパス、モジュール名、参照先は、Step 3 のコードベース調査で確認したものを使う必要があります。ファイルパスを決して捏造しないでください。

4. PR の内訳はチームの規約に従ってください。実装を適切なサイズに分割し、レビューしやすい単位にしてください。

Step 6: 機能のスラッグを作成して出力する

機能名から kebab-case のスラッグを作成します（例：「Recurring Availability Templates」→ recurring-availability-templates）。

メタデータ用に今日の日付を取得します。

date +%Y-%m-%d

PRD を docs/prd/<feature-slug>.md に書き込みます。

Step 7: Linear プロジェクトと課題を作成する（任意）

PRD を書き込んだ後、実装用の Linear プロジェクトと課題を作成します。

注： この手順には Linear MCP サーバーが必要です。Linear が設定されていない場合は、この手順をスキップして Step 8 の概要を提示してください。

7a: 使用する Linear チームをユーザーに確認する

mcp__linear-mcp__list_teams を使用して、利用可能なチームを取得します。プロジェクトをどのチームで作成するか、ユーザーに尋ねます。チームが1つしかない場合は、先に進む前にユーザーに確認します。

7b: プロジェクトを作成する

mcp__linear-mcp__create_project を使用してプロジェクトを作成します。

• 名前: PRD タイトルに記載された機能名
• 概要: PRD の Problem Statement に基づく1行の概要（最大255文字）
• 説明: 以下を含む Markdown の説明：
  • PRD ファイルへのリンク：docs/prd/<feature-slug>.md
  • PRD の Goals テーブル
  • Rollout Plan の概要
• 状態: planned
• 優先度: transcript で別の指定がない限り、2（高）

7c: PR Breakdown からイシューを作成する

PRD の「PR Breakdown Strategy」テーブルに記載された各 PR について、Linear イシューを作成します。

• タイトル: PR {N}: {PR Scope}（例：「PR 1: Schema — Add user preferences table」）
• プロジェクト: 作成したプロジェクト
• 説明: PRD から以下を含めます。
  • PR のスコープの説明
  • 推定サイズ
  • Technical Scope の関連する技術詳細
  • Testing Plan の関連するテストケース（この PR に該当する場合）
  • この PR が変更するファイル／モジュール（Technical Scope より）
• ラベル: PR breakdown テーブルに記載されたラベルを使用します（例：database、frontend、backend、api、testing）。ラベルがまだ存在しない場合は、mcp__linear-mcp__create_issue_label を使用して作成します。
• 優先度: ほとんどの PR は3（通常）、他の PR の前提となる基盤 PR は2（高）
• ブロック関係: PR breakdown テーブルの Dependencies 列を使用します。イシュー ID が必要になるため、すべてのイシューを作成した後、mcp__linear-mcp__update_issue を使用して blockedBy の関係を設定します。

7d: 「PRD Review」イシューを作成する

追加のイシューを1つ作成します。

• タイトル: 「PRD Review: {Feature Name}」
• 説明: 「docs/prd/<feature-slug>.md にある PRD をレビューして承認してください。すべての [TODO] マーカーを埋め、関係者の承認を得てください。」
• 優先度: 2（高）
• プロジェクト: 作成したプロジェクト
• このイシューは、すべての実装イシューをブロックするものとします。

作業順序

1. プロジェクトを作成する
2. 「PRD Review」イシューを先に作成する（ブロック設定にイシュー ID が必要なため）
3. プロジェクトを割り当てて、すべての PR イシューを作成する
4. ブロック関係を設定する（PR の依存関係、およびすべてをブロックする PRD Review）

ステップ 8: 概要を提示する

PRD ファイルを書き込み（必要に応じて Linear プロジェクトも作成し）た後、ユーザーに概要を提示します。

1. 出力先: PRD を保存したファイルパス
2. 完了したセクション: transcript に基づいて記入したセクションの一覧
3. 人間による入力が必要な TODO: すべての [TODO] マーカーと、必要な内容の一覧
4. コードベースの調査結果: コードベースの調査で判明した主な技術的事項の概要
5. Linear プロジェクト（作成した場合）: プロジェクト名とイシュー数
6. 作成した Linear イシュー（作成した場合）: イシュー識別子、タイトル、依存関係の一覧表
7. 次の推奨手順: 作成者が次に行うべきこと（TODO の記入、関係者レビューの実施、技術スパイクの開始など）