kelegele/oh-my-pm

PRD生成

機能アイデアから構造化されたプロダクト要求仕様書を生成します。

このスキルの機能

非形式な機能リクエストを、ユーザーストーリー、受け入れ基準、機能要件、成功指標、コンプライアンスガイダンスを含む完全なPRDに変換します。出力は、エンジニアリングチームが実装し、ステークホルダーがレビューできる準備が整った状態です。

使用タイミング

以下の場合にこのスキルを有効にしてください：

• ユーザーが新機能やプロダクトアイデアを文書化したい場合
• 「PRDを書いて」「要件を作成して」「この機能を文書化して」といったフレーズを使用する場合
• プロダクトレビュー、ステークホルダー調整、エンジニアリング引き継ぎの準備をする場合
• ユーザーがユーザーストーリー、受け入れ基準、成功指標に言及する場合
• 漠然としたアイデアを構造化された文書に形式化する必要がある場合

シナリオ検出（重要 - 最初のステップ）

PRDコンテンツを生成する前に、シナリオを特定する必要があります。

AskUserQuestionを使用して、該当するシナリオを特定します。

Q: PRD生成シナリオを選択してください

オプション	説明
イテレーション更新	既存機能に基づいて反復的に最適化する
新機能	既存プロダクトに新しいモジュールを追加する
0-1新規プロダクト	ゼロから新しいプロダクトを計画する

シナリオ別のコンテキスト収集

シナリオが特定されたら、必要なコンテキストを収集します。

シナリオ	必要な情報	収集方法
イテレーション更新	1. 現在の機能の説明2. UIの状態（スクリーンショット/HTML/リンク）3. イテレーションの目標	ユーザー入力 + UI状態オプションのAskUserQuestion
新機能	1. プロダクト全体のアーキテクチャ2. デザイン仕様（コンポーネントライブラリ/インタラクションパターン）3. エントリポイントの位置	docs/product/から読み取り、またはユーザー入力
0-1新規プロダクト	1. プロダクトの背景とターゲットユーザー2. リソース制約3. 参考プロダクト	ユーザー入力 + 競合分析

イテレーション更新のUI状態収集: ユーザーが「イテレーション更新」を選択した場合、現在のUI状態をどのように提供するか尋ねてください。

• スクリーンショット - ユーザーがスクリーンショットを提供する。mcp__zai-mcp-server__ui_to_artifactまたはmcp__4_5v_mcp__analyze_imageを使用する。
• HTMLファイル - ユーザーがローカルHTMLパスを提供する。Readツールを使用してDOM構造を解析する。
• オンラインリンク - ユーザーがURLを提供する。mcp__web_reader__webReaderを使用する（ログイン不要）。

ステップ0.5: 情報ギャップ分析とPRDプラン（重要 - ハードゲート）

ハードゲート: このステップが完了し、ユーザーがプランを承認するまで、業界ベンチマークチェックやPRD生成に進まないでください。

明示的スキッププロトコル（ユーザーが明示的に操作を拒否した場合）: ユーザーが明示的に質問を禁止した場合（例：「もう聞くな、直接書け」）、インタラクティブなゲートをスキップしても構いません。ただし、その場合、出力は仮定宣言ブロックで始め、行われたすべての仮定（シナリオ、選択/除外された章、ターゲットプロダクト、主要なデフォルト値）をリストアップし、ユーザーが修正できるようにする必要があります。仮定宣言は、証拠規律の完全性チェックリストとしても機能します。未確認情報には【要確認】、証拠のない主張には【未検証】（以下の証拠規律を参照）とマークし、デフォルト値を推測して埋めてはいけません。決して黙ってスキップしないでください。

シナリオ検出とコンテキスト収集の後：

1. ギャップ分析: ユーザーが提供した情報を、このシナリオの「コンテキスト要件」と比較します。欠落している必須フィールドをすべてリストアップします。また、既存の認識データ（market-analysis.json、competitive-analysis、user-research.json、positioning.md）についてdocs/product/を確認します。

2. 一度に一つの質問: 欠落している各項目について、AskUserQuestionを使用して選択肢付きの質問をします。複数の質問を一度のメッセージにまとめないでください。

   欠落項目	質問例
   UIスクリーンショット	「現在の機能のインターフェース状態はどのように提供しますか？」→ A. スクリーンショットがある B. HTMLファイルがある C. オンラインリンクがある D. まだない、スキップする
   競合製品リスト	「どの競合製品を分析する必要がありますか？」→ 複数選択 + 「その他」
   ターゲットユーザー	「ターゲットユーザーは？」→ A. 定義されたペルソナがある B. 口述するので整理してほしい C. まずユーザー調査が必要
   参考プロダクト	「参考にするプロダクトはありますか？」→ A. ある、説明する B. 業界ベンチマークを検索してほしい C. 不要

3. 不足資産の処理: ユーザーが「後でスクリーンショットを提供します」または「スキップ」と言った場合、どの項目が保留中かを記録し、PRDプランで【後日追加】とマークします。

4. PRDプランの生成: PRDプランの構造を準備します（ただし、まだ表示しないでください）。以下の表はデフォルト選択を含むテンプレートを示しています。

   ### 生成予定のPRD章
   | 章 | 概要 | 選択 | 依存状態 |
   |:---|:-----|:-----|:---------|
   | 第0章 業界ベンチマーク分析 | X個のベンチマークプロダクトを調査 | ✅ | 完了 / 【後日追加】 |
   | 第1章 プロジェクト概要 | ユーザーの説明に基づいて展開 | ✅ | 完了 |
   | 第2章 ビジネス分析 | ターゲットユーザー X、ペインポイント Y | ✅ | 完了 / 【後日追加】 |
   | 第3章 機能要件 | 【主要機能リスト】 | ✅ | 完了 |
   | 第4章 非機能要件 | 業界標準要件 | ✅ | 自動生成 |
   | 第5章 ユーザーエクスペリエンスフロー | 機能から推論 | ✅ | UI情報が必要 |
   | 第6章 プロジェクトリスク | 機能の複雑さに基づく | ✅ | 自動生成 |
   | 第7章 コンプライアンス推奨事項 | データタイプに基づく | ❌ | 自動生成 |
   | 第8章 プロトタイプデザイン | 【プロトタイプリンク】 | ❌ | - |
   | 第9章 成功指標 | 目標から推論 | ❌ | 自動生成 |
   
   ### 除外リスト（以下のコンテンツは生成しない）
   - 技術ソリューション / アーキテクチャ設計 — PRDはプロダクト要件文書であり、技術実装の詳細は含まない
   - APIインターフェース定義 / エンドポイント仕様 — 開発チームが技術ソリューションで別途作成する
   - データベーステーブル構造設計 — プロダクト要件の範囲外
   

   注: 上記の表はデフォルトの選択を使用しています。実際の「選択」値は、ステップ4.5でユーザーの章選択の応答に基づいて入力されます。この表をまだユーザーに提示しないでください。

4.5. 章の選択（ハードゲート - PRDプランを提示する前）:

AskUserQuestionをmultiSelectで使用して、章の選択をユーザーに提示します。4つの選択肢の制限があるため、3つの連続した質問に分割します。応答からselected_chaptersとexcluded_chaptersリストを構築し、それに応じてPRDプランテーブルの「選択」列を更新します。

質問1 - コア章（第0-3章）:

オプション	デフォルト	説明
第0章 業界ベンチマーク分析	✅ 選択	ベンチマークプロダクトとベストプラクティスを調査
第1章 プロジェクト概要	✅ 選択	プロジェクトの背景、目的、範囲
第2章 ビジネス分析	✅ 選択	ターゲットユーザー、ペインポイント、市場分析
第3章 機能要件	✅ 選択	機能リスト、ユーザーストーリー、詳細要件

質問2 - 拡張章（第4-7章）:

オプション	デフォルト	説明
第4章 非機能要件	✅ 選択	パフォーマンス、セキュリティ、可用性、互換性
第5章 ユーザーエクスペリエンスフロー	✅ 選択	ユーザージャーニー、ページフロー図
第6章 プロジェクトリスク	✅ 選択	プロジェクトリスクと軽減戦略
第7章 コンプライアンス推奨事項	⬜ 非選択	コンプライアンスガイドラインとリスクカテゴリ

質問3 - オプション章（第8-9章）:

オプション	デフォルト	説明
第8章 プロトタイプデザイン	⬜ 非選択	プロトタイプリンクとデザインノート
第9章 成功指標	⬜ 非選択	ノーススター、プロセス、アウトカム指標

恒久的な除外（選択リストになく、絶対に生成しない）:

• 技術ソリューション / アーキテクチャ設計 — PRDは技術実装の詳細を含まない
• APIインターフェース定義 — インターフェース文書は開発チームが別途作成する
• データベーステーブル構造設計 — プロダクト要件の範囲外

選択収集後: PRDプランテーブルの「選択」列を、ユーザーの選択を反映するように更新します（選択は✅、除外は❌）。

5. ユーザー承認: AskUserQuestionを使用して、PRDプラン（章の選択を含む）を提示し、明示的な承認を得ます。

   オプション	説明
   確認、この章構成でPRDを生成する	ステップ1の業界ベンチマークとステップ2のPRD生成に進む
   章の選択を調整する	生成する章を再選択する
   プランを調整する必要がある	PRDプランを修正し、再度確認する
   追加する情報がある	ステップ0.5に戻り、情報を補足し、プランを再生成する
   まず認識データを補足する	market-research / competitive-analysis を呼び出す

アンチパターン: 「十分な情報があるので、そのまま生成してください」— 禁止。ギャップが最小限であっても、プランを提示して承認を得てください。

TUI環境での画像処理ガイド

ターミナル（TUI）環境では、ユーザーは以下の方法で画像を提供できます。

方法1：ローカルファイルパス（最も簡単）

画像のローカルパスを直接提供し、Readツールを使用して読み取ります。

# ユーザーとの会話例
「このUIスクリーンショットを分析して: /Users/fh/Desktop/screenshot.png」
「現在のインターフェース: ~/Screenshots/ui-2025-03-12.png」
「参考画像: ./docs/product/images/reference.png」

サポートされるパス形式:

• 絶対パス: /Users/fh/Desktop/screenshot.png
• ホームディレクトリ省略形: ~/Screenshots/ui.png
• 相対パス: ./images/ui.png

サポートされる画像形式: PNG, JPG, JPEG, WebP, GIF

方法2：オンライン画像URL

ユーザーが画像を画像ホスティングサービス/クラウドストレージにアップロードし、URLを提供します。

# ユーザーとの会話例
「UIスクリーンショット: https://i.imgur.com/xyz.png」
「参考画像: https://s3.aws.com/bucket/screenshot.png」

mcp__4_5v_mcp__analyze_imageまたはmcp__zai-mcp-server__ui_to_artifactツールを使用してリモート画像を読み取ります。

推奨画像ホスティングサービス:

• imgur.com（無料、登録不要）
• GitHub（Issueの添付ファイルとして）
• クラウドストレージ（AWS S3、Alibaba Cloud OSS）

方法3：ターミナルスクリーンショットコマンド

ユーザーにターミナルスクリーンショットツールを使用してスクリーンショットをすばやく生成するよう案内します。

macOS:

# 選択した領域をキャプチャ（対話型）
screencapture -i ~/screenshot.png

# 全ウィンドウをキャプチャ
screencapture -w ~/screenshot.png

# 全画面をキャプチャ
screencapture ~/screenshot.png

Linux:

# ImageMagick（事前インストールが必要: sudo apt install imagemagick）
import ~/screenshot.png

# gnome-screenshot (Ubuntu/GNOME)
gnome-screenshot -a -f ~/screenshot.png

# spectacle (KDE)
spectacle -r -o ~/screenshot.png

方法4：クリップボードから直接取得（macOS）

# pngpaste ツールをインストール
brew install pngpaste

# クリップボードの画像をファイルとして保存
pngpaste ~/screenshot.png

処理フロー

ユーザーが画像を提供した後：

1. ローカルパス → Readツールを使用して直接読み取る
2. リモートURL → mcp__4_5v_mcp__analyze_imageまたはmcp__zai-mcp-server__ui_to_artifactを使用する
3. 画像コンテンツの分析 → UI構造、レイアウト、インタラクション要素を抽出する
4. PRDの生成 → 画像分析結果に基づいて要件文書を生成する

業界ベンチマークチェック

シナリオ検出、コンテキスト収集、情報明確化の後：

1. ユーザー提供のベンチマーク（優先）: ユーザー指定の参考プロダクト
2. エージェント補足検索: シナリオキーワードに基づいて業界ベストプラクティスを自動検索
3. ベストプラクティスの抽出: 3〜5のベンチマークインタラクションパターン/機能デザイン
4. PRDでの引用: 採用/差別化の根拠とともにベンチマークソリューションを参照

検索キーワードマッピング:

シナリオ	検索キーワード
イテレーション更新	「{機能名} ベストプラクティス」、「業界 {機能名} デザイン」
新機能	「{プロダクトタイプ} {モジュール名} ソリューション」、「類似プロダクト {機能}」
0-1新規プロダクト	「{業界} プロダクトフレームワーク」、「{ドメイン} プロダクトマップ」

仕組み

生成プロセスにより、完全で実行可能なPRDが保証されます。

1. シナリオ検出 - AskUserQuestionを使用して、イテレーション/新機能/新規プロダクトを特定する
2. コンテキスト収集 - シナリオタイプに基づいて必要な情報を収集する
3. 情報ギャップ分析 - 不足している情報を特定し、一度に一つの質問をする
4. 章の選択 - ユーザーが生成するPRDの章を選択する（multiSelect）
5. PRDプランの提示 - ユーザー承認のために章の選択を含むプランを提示する（ハードゲート）
6. 業界ベンチマーク調査 - ベストプラクティスを検索して抽出する（ユーザー指定 + エージェント検索）
7. 要件の解析 - ユーザーの機能リクエストを主要コンポーネントに構造化する
8. コンテキストの収集 - 市場分析、競合インサイト、ユーザー調査を読む
9. セクションの組み立て - 適切な詳細度で、選択されたPRDセクションのみを構築する
10. 完全性の確認 - 品質基準（選択された章のみ）に照らしてチェックする
11. 納品前自己レビュー - PRD事前審査テールゲート（章の自己チェック + ステークホルダーパースペクティブチャレンジ）を実行する。ブロッカーを修正するか、【要確認】とマークする
12. 出力の生成 - docs/product/prd/{機能名}-{日付}-v{バージョン}.mdに書き込む（末尾に「事前審査記録」セクションを含む）

コンテンツ制約（ハードルール）:

PRDコンテンツを生成する前に、以下に注意してください。

1. ユーザーが選択した章のみを生成します。選択されていない章は完全にスキップします。
2. ユーザー入力に関係なく、以下のタイプのコンテンツは絶対に生成しないでください。
   • 技術アーキテクチャ / 実装の詳細
   • APIエンドポイントの定義または仕様
   • データベーススキーマまたはテーブル設計
3. ユーザーの機能説明に技術的な詳細が含まれている場合、それらを機能要件として要約し、実装の詳細を公開しないでください。

入力パラメータ

パラメータ	型	必須	説明
requirements	文字列	はい	文書化する機能の説明またはユーザーストーリー
target_audience	文字列	いいえ	ターゲットユーザーセグメントまたはペルソナ
context_refs	リスト	いいえ	参照する関連コンテキストファイル

証拠規律

1. 欠落情報のマーキング 【要確認】：入力やコンテキストから取得できない情報は、【要確認】とマークし、デフォルト値を推測して埋めてはいけません。
2. 証拠の追跡 【未検証】：ユーザーの要求/市場の主張については、証拠のソースを尋ねる必要があります。証拠がないものは【未検証】とマークし、必要な検証方法を明記します。
3. 完全性チェックゲート：正式な成果物を出力する前に、まず情報の完全性チェックリスト（確認済み ✅ / 要確認 ⚠️ / 未検証 ❓）を出力し、ユーザーの確認後に本文を生成します。

明示的スキッププロトコル（ステップ0.5）との関係: 証拠規律は出力規律（情報のマーキングと納品前の自己チェック）であり、明示的スキッププロトコルは対話規律（ユーザーが明示的に対話を拒否した場合のグレースフルデグラデーション）であり、両者は補完的であり競合しません。明示的スキップシナリオでは、完全性チェックリストは免除されません。「仮定宣言」とマージして出力されますが、ユーザーの確認は待ちません。「仮定宣言」内の未確認情報も、このセクションのルールに従って【要確認】/【未検証】とマークされます。

出力構造

PRDは以下の構造に従います（標準PRDテンプレートに準拠）。重要: このテンプレートはすべての可能な章を示しています。ユーザーが選択した章のみを生成します。選択されていない章は完全にスキップします。いかなる状況でも、技術アーキテクチャ、API仕様、またはデータベース設計を生成しないでください。

# [機能名] PRD

## 文書基本情報
- **文書バージョン**: v1.0
- **作成日**: YYYY-MM-DD
- **最終更新日**: YYYY-MM-DD
- **文書ステータス**: Draft/Review/Approved
- **作成者**: [ユーザー名]
- **レビューア**: 【未定】

## 改訂履歴
| バージョン | 日付 | 改訂内容 | 改訂者 |
|:----------|:-----|:---------|:-------|
| v1.0 | YYYY-MM-DD | 初期バージョン | [作成者] |

## 0. 業界ベンチマーク分析
### 0.1 参考プロダクト
| プロダクト | 主要機能 | 採用/差別化 |
|:----------|:---------|:-----------|
| [競合A] | XXX | XXXパターンを採用。理由は... |
| [競合B] | XXX | 差別化ポイントは... |

### 0.2 ベストプラクティスの要約
- **インタラクションパターン**: [採用された業界標準インタラクションパターン]
- **コア差別化**: [本ソリューションの独自性]

## 1. プロジェクト概要
### 1.1 プロジェクト背景
[市場背景、競合背景、ユーザーニーズ背景]

### 1.2 プロジェクト目標
#### 1.2.1 コア目標
- [定量化可能なコア目標]

#### 1.2.2 副次目標
- [支援目標]

### 1.3 プロジェクト範囲
#### 1.3.1 含まれる範囲
- [今回のイテレーション/機能に含まれる内容]

#### 1.3.2 含まれない範囲
- [明確に今回の範囲外の事項]

## 2. ビジネス分析
### 2.1 ターゲットユーザー
| ユーザーロール | 説明 | コアニーズ |
|:-------------|:-----|:---------|
| ユーザーA | [ユーザー調査より] | XXX |
| ユーザーB | [ユーザー調査より] | XXX |

### 2.2 ユーザーペインポイント
| ペインID | ペインの説明 | 影響度 |
|:---------|:-------------|:-------|
| P-001 | XXX | 高/中/低 |
| P-002 | XXX | 高/中/低 |

### 2.3 市場分析
[業界動向、競争環境、市場機会]

## 3. 機能要件
### 3.1 コア機能リスト
| 機能ID | 機能名 | 優先度 | 説明 |
|:-------|:-------|:-------|:-----|
| F-001 | XXX | P0/P1/P2 | XXX |
| F-002 | XXX | P0/P1/P2 | XXX |

### 3.2 ユーザーストーリー
#### US-1: [機能名]
**〜として** [ユーザーロール]
**〜したい** [機能説明]
**〜できるように** [ビジネスバリュー]

**受け入れ基準**:
- Given [前提条件]
- When [操作を実行]
- Then [期待される結果]

**優先度**: P0/P1/P2
**見積もり**: X ストーリーポイント

#### US-2: [機能名]
...

### 3.3 機能の詳細
#### F-001: [機能名]
**説明**: [詳細な機能説明]

**インタラクションフロー**:
1. ステップ1
2. ステップ2
3. ステップ3

**境界ケース**:
- 正常フロー: ...
- 異常ケース: ...

## 4. 非機能要件
### 4.1 パフォーマンス要件
- ページ応答時間 < XXXms
- XXX 同時ユーザーをサポート
### 4.2 セキュリティ要件
- データの暗号化保存
- ユーザー権限制御
### 4.3 可用性要件
- システム可用性 > 99.9%
### 4.4 互換性要件
- iOS 14+, Android 10+
- 主要ブラウザとの互換性

## 5. ユーザーエクスペリエンスフロー
### 5.1 ユーザージャーニー
[主要ユーザーパスの説明]
1. ユーザーが入る → 2. 操作を実行する → 3. 目標を達成する

### 5.2 ページフロー図
[ページ遷移関係の説明]
- ページA → ページB → ページC

## 6. プロジェクトリスクと対策
> 注: このセクションにはプロダクト/ビジネスリスクのみを含みます。技術実装リスク（技術リスクは開発チームが技術ソリューションで評価）は含みません。
| リスクID | リスクの説明 | 確率 | 影響 | 対策 |
|:---------|:-------------|:-----|:-----|:-----|
| R-001 | XXX | 高/中/低 | 高/中/低 | XXX |
| R-002 | XXX | 高/中/低 | 高/中/低 | XXX |

## 7. コンプライアンス推奨事項

### 7.1 コンプライアンスの要点概要
[コンプライアンスエキスパートによるレビューの主要ポイントの要約]

### 7.2 リスク通知
| リスクカテゴリ | 説明 | 推奨事項 |
|:-------------|:-----|:---------|
| プライバシーコンプライアンス | [ユーザーデータの取り扱いに関するもの] | [コンプライアンス推奨事項] |
| コンテンツコンプライアンス | [コンテンツ審査に関するもの] | [コンプライアンス推奨事項] |
| データセキュリティ | [データ保存と転送に関する要件] | [コンプライアンス推奨事項] |
| サードパーティコンプライアンス | [依存するサードパーティサービスのコンプライアンス] | [コンプライアンス推奨事項] |

### 7.3 コンプライアンスレポート添付
- [ ] コンプライアンス分析レポートを添付（ある場合、パスを提供）
- [ ] コンプライアンスレビュー待ち（必要な場合、コンプライアンス専門家によるレビューを手配）

...

[翻訳のため省略]