mcpField
P
prd

prd

github.com/github開発40.5k24.1k 回インストール1 日前に更新
リポジトリ

prd について

プロダクト目標と技術実行をつなぐ要件定義書（PRD）を作成するスキルです。定められた構成に沿って、ヒアリング、スコープ設定、ユーザーフロー、測定可能な基準、技術仕様、リスクを整理します。

主な機能

  1. 01課題と制約を確認するヒアリング
  2. 02ユーザーフローと対象外事項の整理
  3. 03測定可能な要件と成功基準
  4. 04技術仕様とリスクの構成

活用シーン

  1. 01プロダクトや機能開発の開始
  2. 02アイデアの仕様化
  3. 03関係者間でのプロジェクト範囲の共有

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/github/awesome-copilot --skill prd

インストール後、Claude Code で/prdを入力して読み込まれたか確認します。

詳細

製品要求仕様書 (PRD)

概要

ビジネスビジョンと技術的実行のギャップを埋める、包括的で本番品質の製品要求仕様書 (PRD) を設計します。このスキルは現代のソフトウェアシステムに対応し、要求が明確に定義されることを保証します。

使用する場面

以下の場合にこのスキルを使用します:

  • 新しい製品または機能の開発サイクルを開始するとき
  • 曖昧なアイデアを具体的な技術仕様に落とし込むとき
  • AI を活用した機能の要求を定義するとき
  • ステークホルダーがプロジェクトスコープの統一された「信頼できる唯一の情報源」を必要としているとき
  • ユーザーが「PRD を書いて」「要求を文書化して」「機能を計画して」と依頼したとき

運用ワークフロー

フェーズ 1: ディスカバリー (ヒアリング)

PRD を一行も書く前に、知識のギャップを埋めるためにユーザーに必ず質問してください。コンテキストを仮定してはいけません。

以下について尋ねます:

  • 核心的な問題: なぜ今これを構築するのか?
  • 成功指標: うまくいったかどうかをどうやって知るのか?
  • 制約: 予算、技術スタック、または期限は?
フェーズ 2: 分析とスコーピング

ユーザーの入力を統合します。依存関係と隠れた複雑さを特定します。

  • ユーザーフローを洗い出します。
  • スケジュールを守るために非目標を定義します。
フェーズ 3: 技術的ドラフト作成

以下の厳格な PRD スキーマを使用してドキュメントを生成します。

PRD 品質基準

要求の品質

具体的で測定可能な基準を使用してください。「高速」「簡単」「直感的」といった表現は避けてください。

# Vague (BAD)
- The search should be fast and return relevant results.
- The UI must look modern and be easy to use.

# Concrete (GOOD)
+ The search must return results within 200ms for a 10k record dataset.
+ The search algorithm must achieve >= 85% Precision@10 in benchmark evals.
+ The UI must follow the 'Vercel/Next.js' design system and achieve 100% Lighthouse Accessibility score.

厳格な PRD スキーマ

出力にはこの正確な構造に必ず従ってください:

1. エグゼクティブサマリー
  • 問題提起: 課題について 1～2 文。
  • 提案する解決策: 修正について 1～2 文。
  • 成功基準: 3～5 個の測定可能な KPI。
2. ユーザーエクスペリエンスと機能
  • ユーザーペルソナ: これは誰のためのものか?
  • ユーザーストーリー: As a [user], I want to [action] so that [benefit].
  • 受け入れ基準: 各ストーリーの「完了」定義の箇条書き。
  • 非目標: 何を構築しないのか?
3. AI システム要件 (該当する場合)
  • ツール要件: どのようなツールと API が必要か?
  • 評価戦略: 出力の品質と精度をどのように測定するか。
4. 技術仕様
  • アーキテクチャ概要: データフローとコンポーネントの相互作用。
  • 統合ポイント: API、DB、認証。
  • セキュリティとプライバシー: データの取り扱いとコンプライアンス。
5. リスクとロードマップ
  • 段階的ロールアウト: MVP -> v1.1 -> v2.0。
  • 技術的リスク: レイテンシ、コスト、または依存関係の障害。

実装ガイドライン

すべきこと (常に)
  • テストを定義する: AI システムの場合、出力品質をどのようにテストし検証するかを明記します。
  • 反復する: ドラフトを提示し、特定のセクションについてフィードバックを求めます。
すべきでないこと (避ける)
  • ディスカバリーを省略する: 最初に少なくとも 2 つの明確化の質問をせずに PRD を書いてはいけません。
  • 制約を捏造する: ユーザーが技術スタックを指定していない場合は、尋ねるか TBD とラベル付けします。

例: インテリジェント検索システム

1. エグゼクティブサマリー

問題: ユーザーは巨大なリポジトリ内で特定のドキュメントの断片を見つけるのに苦労しています。 解決策: 出典引用付きで直接的な回答を提供するインテリジェント検索システム。 成功:

  • 検索時間を 50% 削減。
  • 引用精度 >= 95%。
2. ユーザーストーリー
  • ストーリー: 開発者として、キーワードを推測しなくて済むように、自然言語で質問したい。
  • AC:
    • 複数ターンの明確化をサポート。
    • 「コピー」ボタン付きのコードブロックを返す。
3. AI システムアーキテクチャ
  • 必要なツール: codesearch、grep、webfetch。
4. 評価
  • ベンチマーク: 開発者向けの一般的な質問 50 件でテスト。
  • 合格率: 90% が期待される引用と一致すること。

コメント

Markdown 対応