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
関連スキル
3-statement-model
3種類の財務諸表テンプレート(損益計算書、貸借対照表、キャッシュフロー計算書)を作成・記入・完成させることができます。モデルテンプレートの記入、既存のモデル枠組みの完成、財務モデルへのデータ入力、部分的に完成した損益/貸借/キャッシュフロー枠組みの完成、または既存テンプレート構造内での統合財務諸表の連携に対応しています。3種類の財務モデルテンプレートの記入、完成、またはデータ入力に関するご依頼で自動的に機能します。
strategic-decision
CEO・経営層向けの戦略的意思決定支援です。前提条件に異議を唱え、問題を診断し、確実な戦略を設計できます。4つのモード(AGGRESSIVE:大きな夢を見る、SELECTIVE:基盤を維持しつつ有望な拡張を厳選、DIAGNOSTIC:最大限の厳密性、VALIDATION:本質に絞る)を備えています。創業者、経営幹部、プロダクトリーダーが製品開発、成長戦略、市場戦略、技術選定、リソース配分に関する戦略的判断が必要な場面で活用できます。
value-realization
エンドユーザーが製品アイデアから明確な価値を感じるかどうかを分析します。以下の場面で活用できます:製品コンセプトの議論、機能の評価、製品改善の方向性提示、マーケティング戦略の企画、導入・継続率の問題分析、コピーが価値を伝えているかの検証、機能と利用シーンの対応付け、または製品方向性・ポジショニング・エンドユーザーの需要の有無が不確かな場合(例:「これは良いアイデアか」「この製品をどう思うか」「ユーザーは必要とするか」「この機能は何に役立つのか」「機能の価値をどう説明するか」「このコピーをどう思うか」「利用シーンを作成する手助けが欲しい」「ユーザーが継続利用しない理由は何か」「どうポジショニングすべきか」)。
creating-financial-models
このスキルは、投資判断に必要な高度な財務モデリング機能を提供します。DCF分析、感度分析、モンテカルロシミュレーション、シナリオプランニングなど、複数の分析手法を組み合わせることで、より正確で信頼性の高い財務予測が可能になります。
pestel-analysis
政治的、経済的、社会的、技術的、環境的、法的な外部要因を分析します。市場環境の変化が製品、ロードマップ、または戦略に大きな影響を与える可能性がある場合に活用できます。
chemical_safety_assessment
化学安全性評価 - 化学物質の安全性を評価します。PubChemの化合物情報、FDAの医薬品データ、ADMET予測、ChEMBLの構造警告を活用します。このスキルを使用することで、化合物名から一般情報を取得したり、医薬品名から警告および注意事項を取得したり、分子のADMETを予測したり、化合物の構造警告を検出したりできます。4つのSCPサーバーから4つのツールを統合しています。