prd-writer
ソフトウェアシステムおよびAI搭載機能に対する高品質な製品要件書(PRD)を生成します。経営層向けサマリー、ユーザーストーリー、技術仕様書、リスク分析を含めた包括的なドキュメント作成が可能です。
description の原文を見る
Generate high-quality Product Requirements Documents (PRDs) for software systems and AI-powered features. Includes executive summaries, user stories, technical specifications, and risk analysis.
SKILL.md 本文
Product Requirements Document (PRD)
概要
ビジネスビジョンと技術実行のギャップを埋める包括的でプロダクションレディーなProduct Requirements Document(PRD)を設計します。このスキルはモダンなソフトウェアシステムに対応し、要件が明確に定義されることを保証します。
使用時機
以下の場合にこのスキルを使用してください:
- 新しいプロダクトまたはフィーチャーの開発サイクルを開始する
- あいまいなアイデアを具体的な技術仕様に落とし込む
- AI搭載フィーチャーの要件を定義する
- ステークホルダーがプロジェクトスコープの統一された「情報源」を必要とする
- ユーザーが「PRDを書く」「要件をドキュメント化する」「フィーチャーを計画する」と要求する
運用ワークフロー
フェーズ1: ディスカバリー(インタビュー)
PRDの1行目を書く前に、ユーザーに質問して知識ギャップを埋める必要があります。文脈を仮定しないでください。
以下について質問します:
- コア課題: なぜ今構築するのか?
- 成功メトリクス: どうやって成功を測定するか?
- 制約条件: 予算、技術スタック、期限は?
フェーズ2: 分析とスコーピング
ユーザーのインプットを統合します。依存関係と隠れた複雑性を特定します。
- ユーザーフローをマッピングします。
- タイムラインを保護するため非ゴールを定義します。
フェーズ3: 技術的なドラフト作成
以下の厳密なPRDスキーマを使用してドキュメントを生成します。
PRDの品質基準
要件の品質
具体的で測定可能な基準を使用します。「高速」「簡単」「直感的」は避けてください。
# あいまい(悪い例)
- 検索は高速であり、関連性のある結果を返す必要があります。
- UIはモダンに見え、使いやすい必要があります。
# 具体的(良い例)
+ 検索は10kレコードのデータセットで200ms以内に結果を返す必要があります。
+ 検索アルゴリズムはベンチマーク評価でPrecision@10 >= 85%を達成する必要があります。
+ UIはプロジェクトのデザインシステムに従い、Lighthouse Accessibilityスコア100%を達成する必要があります。
厳密なPRDスキーマ
出力の際に以下の正確な構造に従う必要があります:
1. エグゼクティブサマリー
- 問題ステートメント: ペインポイントに関する1〜2文。
- 提案ソリューション: その解決策に関する1〜2文。
- 成功基準: 3〜5個の測定可能なKPI。
2. ユーザーエクスペリエンスと機能
- ユーザーペルソナ: これは誰のためのものか?
- ユーザーストーリー:
[ユーザー]として、[アクション]したい。なぜなら[メリット]だからだ。 - 受け入れ基準: 各ストーリーの「完了」定義の箇条書きリスト。
- 非ゴール: 構築しないものは何か?
3. AIシステム要件(該当する場合)
- ツール要件: どのツールとAPIが必要か?
- 評価戦略: 出力品質と精度をどのように測定するか?
4. 技術仕様
- アーキテクチャ概要: データフローとコンポーネント間の相互作用。
- 統合ポイント: API、DB、認証。
- セキュリティとプライバシー: データハンドリングとコンプライアンス。
5. リスクとロードマップ
- 段階的ロールアウト: MVP → v1.1 → v2.0。
- 技術的リスク: レイテンシ、コスト、依存関係の障害。
実装ガイドライン
すべきこと(常に実行)
- テストを定義する: AIシステムの場合、出力品質をどのようにテストおよび検証するかを指定します。
- 反復する: ドラフトを提示し、特定のセクションに関するフィードバックを求めます。
すべきでないこと(回避する)
- ディスカバリーをスキップしない: 少なくとも2つの明確化質問をせずにPRDを書かないでください。
- 制約を創作しない: ユーザーが技術スタックを指定しなかった場合、質問するか
TBDとラベル付けします。
例: ドメイン検索フィーチャー
1. エグゼクティブサマリー
問題: ユーザーは大規模なドメイン知識ソース全体で特定の情報を見つけるのに苦労しています。 ソリューション: ソース引用を付けた直接回答を提供する検索フィーチャー。 成功基準:
- 検索時間を50%削減。
- 引用精度 >= 95%。
2. ユーザーストーリー
- ストーリー: ドメインユーザーとして、自然言語で質問したいため、正確なキーワードを推測する必要がありません。
- 受け入れ基準:
- マルチターン引用をサポートします。
- 「コピー」ボタン付きのコードブロックを返します。
3. システムアーキテクチャ
- 必要な機能: コンテンツインデックス、クエリ解析、ソース検索、引用レンダリング。
4. 評価
- ベンチマーク: 一般的なドメイン質問50件でテストします。
- 合格率: 90%が予想される引用と一致する必要があります。
ライセンス: MIT(寛容ライセンスのため全文を引用しています) · 原本リポジトリ
詳細情報
- 作者
- GustavoGutierrez
- ライセンス
- MIT
- 最終更新
- 2026/5/10
Source: https://github.com/GustavoGutierrez/engineering-skills / ライセンス: MIT