authoring-prd

authoring-prd — SKILL.md

バリアント： standard · 使用するタイミング： プロダクトのアイデアから、後続の開発計画を立てられる品質基準を満たす、包括的な PRD を作成（または修正）する場合。

概要

このスキルは、優れた包括的なプロダクト要件定義書（PRD）の書き方を示すものです。これは、セクションの一覧ではなく、作成者が適用する判断基準です。2 つの共同作業者を想定しています。セクションの構成を提供する PRD テンプレートツールと、各セクションを根拠に基づいて作成するための詳細な調査機能です。作成者にはプロダクトのアイデア（および上流のコンテキスト文書）が渡され、それを PRD に詳しく展開する必要があります。一般的な定型文を出力してはいけません。目指すべき基準は、完成した PRD が計画可能であることです。つまり、エンジニアがそこからマイルストーンとタスクを導き出せる必要があります。このスキルは reviewing-prd と情報源を一本化しています。Step-5 の自己チェックはレビュー担当者の 12 項目の基準そのものであり、作成者とレビュー担当者の判断に食い違いが生じないようにします。

起動するタイミング

• プロダクトのアイデアや概要から新しい PRD を作成する場合。
• 内容の薄いアイデアを、包括的な要件文書（プロダクトまたは大規模な機能）に展開する場合。
• 既存の PRD をバージョン管理された差分として修正する場合（新規または変更された要件、スコープの変更など）。Step 6 を参照してください。
• PRD テンプレートに、調査に基づいた、判断が完了した内容を記入する場合。

次の場合は起動しないでください：

• 完成した PRD をレビューまたは評価する場合 → reviewing-prd を使用してください。
• 別の種類の文書（feature-spec、technical-design、runbook、wireframes）を作成する場合 → その文書タイプのスキルを使用してください。PRD では WHAT（何を）と WHY（なぜ）を記述します。HOW（どのように）は後続の feature-spec（機能ごとの動作）と technical-design（エンジニアリング設計）で扱います。
• 要件文書を必要としない、1 行のメモや些細な変更の場合。

入力

プロダクトのアイデアに加え、計画によって渡されたすべての文書、つまり depends_on の一式（discovery によって上流に配置された分析文書。たとえば problem-statement、market/competitor scan、business case、user research）を読み、それらに基づいて PRD を作成します。入力を固定的に想定してはいけません。このスキルで挙げる一般的な上流文書は、方法の指針であり、受け取る文書を限定するものではありません。自己完結させてください。実際に受け取ったコンテキストがどのようなものであっても、それを使って文書を作成します。想定していた参考文書がない場合は、手元の情報で進め、不足を明示的な仮定として示してください。不足を埋めるために内容を捏造してはいけません。文書を包括的かつ網羅的にするために、利用可能であれば調査機能（deep-research）を使用してください。テンプレートを埋めるだけで終わらせてはいけません。修正する場合は、既存の PRD と変更依頼も入力に含めます（Step 6）。

機能のコンテキスト（提供される場合）： 呼び出し元から capability_record（capability-map.yaml product_capabilities のレコード）が渡された場合は、Step 1 の前にそれを読んでください。これはスコープの境界を定義します。owns = 対象とするエンティティ、refs = 参照するが所有しないエンティティ、publishes/consumes = 表面化させるイベント、entry_points/exit_points = ユーザーの流入と離脱の経路、has_ui/has_api/has_persistence = 該当するサーフェスです。提供された場合は、これを厳格な制約として扱い、定義された境界から逸脱しないでください。

ワークフロー

Step 1: 構成はテンプレートツールから取得する — アウトラインを独自に作らない

PRD テンプレートツールからセクションの構成（comprehensive バリアント）を取得してください。ここでセクション一覧を言い換えたり、再導出したりしてはいけません。このスキルが示すのは、それらのセクションを適切に埋める方法です。テンプレートを利用できない場合は、包括的な PRD の構成を入手する（依頼する、作成する、または標準的な PRD セクション一式を使う）などしてから、先に進んでください。

すべての capability レコード（product_capabilities リスト）が渡されている場合：有効な L1 capability リストを PRD のスコープの骨格として使用し、capability ごとに 1 つのセクションを設けてください。分類の archetype.primary と domain.primary に基づいて構成してください。

Step 2: アイデアとコンテキストを読み込み、アーキタイプを特定し、不足情報を洗い出す

プロダクトのアイデアと、上流のコンテキストを読み込みます。プロダクトのアーキタイプ（コンシューマー向け／B2B エンタープライズ／社内ツール／プラットフォーム API／データ・ML／規制対象）を特定します。アーキタイプによって、どのセクションを重視するかが決まるためです（references/archetype-and-amend.md を参照）。ドラフトを作成する前に、知識の不足を埋めます。コアとなる問題、成功指標、ユーザー、制約について不明な点を特定し、解消します（質問する、調査する、または明示的な仮定を示す）。各セクションの内容は、一般的なテンプレートを埋めるのではなく、必ずこのアイデアとそのユーザーに基づくものにします。アイデアの情報が不足している場合は、仮定を明示し、決して暗黙のうちに一般論で補わないでください。コアとなる問題について信頼できる仮定さえ立てられない場合は、ドラフトの作成を中止し、Step-5 の「アイデアの情報不足」ブロッカーを提起してください。

Step 3: 各セクションの根拠となる調査を行う

詳細な調査を行い、問題、ユーザー、市場・競合の状況、指標のベースラインをエビデンスに基づいて整理します。重要な箇所には出典を記載してください。「PRD 全般」ではなく、アイデアに固有の領域を調査します。調査機能を利用できない場合は、エビデンスや引用を捏造しないでください。問題、ユーザー、指標を、仮定であることを明示したうえで記載し、「構築前に検証する項目」に列挙してください。

Step 4: セクションごとの方法を適用する

テンプレートの各セクションに、次の方法を適用します。

• 課題 — 課題の根拠となる証拠（データ、調査、兆候）を示すことから始め、誰がその課題を抱え、現状どのようなコストが生じているかを明記します。「[状況]のとき、[動機]があるので、[成果]を得たい」という**達成すべき仕事（job-to-be-done）**として表現し、実際の仕事に基づいた課題にします。機能の必要性を先に決めつけた、根拠のない課題の主張は、PRDで最もよくある失敗です。
• 目標と成功指標 — 測定可能な成果を2～4件設定し、それぞれに目標値と測定方法／トラッキングの仕組みを定めます。これらは開発前に定義します。先行指標（入力）と遅行指標（成果）を組み合わせます。また、主要指標が操作しやすい、または別の側面に悪影響を与える可能性がある場合は、ガードレール指標／反対指標を明記します。適切な指標を絞り込むためにフレームワーク（North Star／OKR／HEART／AARRR）を活用します。フレームワークはツールであり、成果物ではありません。指標を羅列するのではなく、明快な箇条書きをいくつかに絞ります。（詳細：references/nfr-and-metrics.md。）
• ユーザーとペルソナ — 実際のニーズや利用シナリオに基づく具体的なペルソナを作成し、「私は…として、…したい。そうすれば…できる」というユーザーストーリーを記載します。
• スコープ：MVPと対象外 — 初回リリースに必須の項目と後回しにする項目を分け、対象外の項目とリリース基準を明記します。スコープの拡大を防ぐ主な手段は、対象外／実施しない項目のリストです（有用であれば、機能の予算や期限も設定します）。優先順位は、根拠を示せる方法で決定します（補助としてRICE／MoSCoW／Kanoを使用します）。
• 要件 — 機能要件（テスト可能で、ユーザー視点のもの）と非機能要件を、名称を付けたカテゴリー体系として扱います。重要なカテゴリーにはそれぞれ、数値または検証可能な目標値を設定します。パフォーマンス（p95レイテンシー、スループット）、可用性／信頼性（SLO）、セキュリティ、プライバシー／データ取り扱い、アクセシビリティ（WCAG 2.2 AAを最低基準とする）、スケーラビリティ、保守性、互換性、ローカライズ／国際化、コンプライアンスを含めます。要件はプロダクトの類型に応じた範囲にし、意図的にベストエフォートとする非機能要件は、その旨を明記します。（カテゴリー体系と数値基準：references/nfr-and-metrics.md。）
• ユーザーストーリーと受け入れ基準 — 各ストーリーに、完了を個別にテストできる受け入れ基準（Given／When／Then形式またはルールベース）を付けます。
• トレーサビリティ — つながりを保ちます。すべての機能を目標に結び付け、すべての目標に少なくとも1つの機能を割り当て、すべての指標を目標に結び付け、すべてのストーリーに受け入れ基準を設定します。軽量なアジャイル方式として小さなマトリックスを使い、重厚なRTMツールは使いません。目標に結び付かない機能も、機能のない目標も残さないでください。
• 依存関係 — チーム間および外部の依存関係（サービス、データ、サードパーティ、必要な承認）を個別の項目として明記します。これらは後続の作業順序を左右します。
• リスク — 発生可能性／影響度と緩和策を記載します。「6か月後に失敗していたとしたら、その理由は何か」という短いプレモーテムで、検討を深めます。
• 前提、未解決の質問、意思決定ログ — 不明点を明示します。更新を続けるPRDでは、重要な決定（内容／時期／理由）を記録します。
• 部門横断の準備状況（必要に応じた補助項目であり、必須セクションではありません） — 実現可能性の承認を促し、プロダクトの類型に応じて、GTM／ローンチ／サポート／アナリティクスについても確認します。必要な項目だけを含め、すべてのPRDにGTMセクションを追加しないでください。
• 全体を通じて — 部門横断の読者に向け、正確で、専門用語を避け、曖昧さのない言葉を使います。各項目の名称は統一してください。

ステップ 5：引き継ぐ前に、計画可能性の基準を満たしているか自己チェックする

該当する項目がすべて満たされていることを確認します（これは reviewing-prd が定めるものと同じ 12 条件の基準です）。

1. 根拠のある問題 — 根拠（または明示された仮定）に裏付けられ、ジョブとして定義されています。断定だけではありません。
2. ユーザーの定義 — 具体的なニーズを持つ主要なペルソナが少なくとも定義されています。
3. 測定可能な成功 — 目標値と測定方法をそれぞれ備えた指標が 2～4 個あります。主要指標が明らかに操作可能で、その結果、明示された目標を損なう場合はガードレールも設けます。
4. 妥当な MVP の境界 — 対象範囲と対象外／非目標、およびリリース基準が定義されています。
5. 具体的な機能 — マイルストーンやタスクを導き出せるだけの具体性を備えた機能と受け入れ基準があります。
6. 根拠に基づき、仮定に頼らない（捏造なし） — 問題と指標が根拠に基づいています。仮定には明示的に印を付け、「着手前に検証する項目」として列挙します。数値を捏造しません。
7. リスク、依存関係・背景、未解決の質問を明示 — 隠されていません。
8. 明確で曖昧さがない — 専門用語を避け、用語を一貫させています。要件の代わりに曖昧な形容詞を使いません。
9. NFR の分類 — アーキタイプにおいて重要な NFR カテゴリーが含まれ、それぞれに数値化・確認可能な目標値（または最善努力で対応する旨の明記）があります。
10. 追跡可能 — 孤立した機能がありません。すべての目標に機能が対応し、指標は目標に結び付けられ、ストーリーには AC があります。
11. 依存関係を明記 — チーム間・外部の依存関係と承認を明示します（ない場合は「なし」と記載します）。
12. 改訂の整合性（改訂時）— ステップ 6 を参照してください。

アイデアが不十分な場合のゲート： 根本的な問題に根拠がなく、信頼できる仮定さえ立てられない場合は、仮定で取り繕わず、「仕様化するにはアイデアが不十分 — 発見が必要」というブロッカーとして明示します。

ステップ 6：既存の PRD をバージョン管理された差分として改訂する（反復時）

入力が既存の PRD と変更内容である場合（新規アイデアではない場合）：

• 変更範囲を定める — この改訂で変更する箇所と、意図的に変更しない箇所を明示します。
• 書き換えず、既存箇所を編集する — 影響を受ける要件・目標・指標・範囲の行だけを変更します。PRD 全体を再生成しないでください（再生成すると由来が失われ、気付かないうちに内容がずれるおそれがあります）。
• バージョンと変更履歴 — PRD 自体のドキュメントバージョンを上げ、変更履歴に変更した人／日時／変更内容／理由（および変更を依頼した人）を記録します。
• 置き換えられた内容に印を付ける — 古くなった要件・指標は、理由を添えて置き換え済みと明示します。黙って削除しないでください。
• 影響範囲を分析する — 変更の波及範囲を追跡します。どの受け入れ基準、指標、その他の要件、後続ドキュメント（feature-spec、technical-design）が古くなったかを確認します。影響を受ける項目を明示するか、理由を添えて「後続への影響なし」と記載し、追跡可能性の連鎖が途切れないようにします。

（改訂手順の全文：references/archetype-and-amend.md。）

ルール

必ず守るルール（例外なし）：

• 問題の根拠を示します。 根拠または明示して注意喚起した仮定なしに、問題を断定してはいけません。
• 指標は測定可能にします。 すべての成功指標に目標値と測定方法を設定し、見栄えだけの目標や測定不能な目標は退けます。主要指標が操作されやすい場合は、ガードレール指標を追加します。
• NFR には数値目標を設定します。 重要な非機能要件には、定量化できる目標を明記します。「高速であるべき」「安全であるべき」は要件ではありません。
• 曖昧な表現は使いません。 「速い」「直感的」「簡単」「スケーラブル」などの主観的な言葉を、「p95 < 200ms」「タスクを ≤ 3 回のクリックで完了」などの定量化できるベンチマークに置き換えます。
• 根拠を捏造してはいけません。 統計、調査の数値、引用を作り出してはいけません。出典のない主張は、明示して注意喚起した仮定として記載し、「着手前に検証」とします。数値を捏造するより、仮定であることを正直に示すほうが重要です。
• MVP の境界を明確にします。 対象範囲、後回しにするもの、対象外を必ず明記します。「MVP = すべて」としてはいけません。
• ストーリーには受け入れ基準を設定します。 確認可能な受け入れ基準のないユーザーストーリーは、完了と見なしません。
• 追跡可能性を保ちます。 どの機能にも対応する目標があり、すべての目標に少なくとも 1 つの機能があるようにします。
• 重複させず、組み合わせます。 セクション構成はテンプレートツールを使い、このスキルはその構成を埋めるための方法として使います。
• 提示されたアイデアを具体化します。 PRD の具体的な内容は、アイデアと調査に基づくものとし、汎用的な定型文にしてはいけません。
• 書き直すのではなく、修正します。 既存の PRD を変更する場合は、その場で編集し、バージョンと変更履歴を記録します。黙って再生成してはいけません。
• 計画に落とし込めなければ未完了です。 エンジニアがマイルストーンを導き出せない PRD を引き渡してはいけません。
• ケイパビリティの境界を守ります（capability_record が提供されている場合）。 ドキュメントの出力範囲を、そのレコードに定義された境界に合わせます。境界外の内容を作成すること（refs エンティティを所有対象として扱う、exit_point を越えるフローを設計するなど）は、仕様にない内容を捏造するのと同等の範囲違反です。

推奨事項（必要に応じて変更可能）：

• 「包括的」とは、出力の目指す水準を定めるものであり、分量に比例させます。網羅性とは意思決定が網羅されていることであり、文章量ではありません。アイデアが簡素であれば、不要なセクションは正当に省略できます（単純なツールに NFR マトリクスを設けない、依存関係がなければその記載を省くなど）。
• 目標と指標は 2～4 項目にまとめ、長いリスク表より短いプレモーテムを優先します。
• フレームワーク（North Star／OKR／HEART、RICE／MoSCoW／Kano）は、適切な指標や優先順位を選ぶための補助として使います。対象の類型に合うものを選び、無理に当てはめてはいけません。

注意点

• 根拠のない問題提起。 「ユーザーは X に苦労している」と根拠なく述べると、権威があるように見えても、ほとんどの PRD で最も弱い部分になります。根拠を示すか、仮説であることを明記してください。
• 見栄えだけの指標。 「ユーザーに気に入られるでしょう」「エンゲージメントが高まる」は指標ではありません。指標では、何を測るのか、目標値、そして追跡方法を明示します。
• ガードレールのない指標。 不正に操作しやすい主要指標（例：「送信メッセージ数」）に、そこから生じる害（スパム）を防ぐものが何もないと、指標の操作を招きます。対抗指標を明記してください。
• 形容詞で表した NFR。 「高速で安全であるべきです」ではなく、カテゴリに応じた数値目標（p95、SLO、WCAG 2.2 AA）に置き換えてください。目標はアーキタイプに見合ったものにします。
• 孤立した機能／宙ぶらりんの目標。 明示された目標に役立たない機能（または機能を伴わない目標）は、プランナーが頼りにするつながりを断ちます。対応関係をたどるか、削除してください。
• 曖昧な MVP の境界。 対象に含めるもの／含めないものの明確な区分とリリース基準がなければ、スコープは際限なく膨らみます。対象外の項目を明記してください。
• アウトラインの言い直し。 テンプレートの各セクションを判断を交えて埋める代わりに、PRD の本文でセクション一覧を再構成すること。
• 汎用的な内容で埋める。 どの製品にも当てはまる内容では、アイデアではなくテンプレートを詳しくしただけです。
• 反射的な GTM 追加。 アーキタイプ（例：社内ツール）上、必要のない PRD に GTM／ローンチのセクションを付け足すこと。準備状況の確認項目は状況に応じた補助であり、すべての PRD に必要なセクションではありません。
• 変更時に説明なく全面書き換え。 要件を 1 つ変更するたびに PRD 全体を再生成すると、変更履歴が失われ、内容のずれも生じかねません。その場で編集してください。

対比例 — 汎用的（表面上は要件を満たしている）と根拠のある内容（自己チェックに使ってください）：

セクション	汎用的／根拠なし（却下）	根拠あり（採用）
問題	「フリーランサーは請求書の追跡に苦労しています。」	「［実際の調査に基づく］フリーランサーの X% が四半期ごとに 1 回以上の支払い遅延を報告しました。課題はデータ入力ではなく、支払いの催促です。」（数値は実際の情報源に基づく必要があります。決して捏造しないでください。調査していない場合は、仮説であることを明記して「検証する」と書いてください）
指標	「支払い遅延を減らす。」	「請求書の支払いタイムスタンプで追跡し、90 日以内に支払いまでの日数の中央値を 21 日から 14 日に短縮する。ガードレール：ユーザーあたりのサポートチケット数がベースライン以下であること。」
NFR	「支払いは高速で信頼性が高いべきです。」	「支払いステータスの Webhook が 60 秒以内に反映される（p95）。ローリング 30 日間の配信率は 99.9%。」
受け入れ基準	「ログインが機能する。」	「有効な認証情報を持つ登録済みユーザーがログインフォームを送信すると、2 秒未満でダッシュボードに到達する。認証情報が無効な場合は、フォーム内にエラーを表示する。」

書いた内容が左の列のように、どの製品にも当てはまり、数値も情報源もないなら、まだ完成していません。

アンチパターン

• 「成功指標は、動作することです。」 測定できません。指標、目標値、測定方法を定義してください。
• 「MVP は機能一式です。」 境界がありません。必須項目と後回しにする項目を分け、非目標も明記してください。
• 「アウトラインは自分で書きます。」 テンプレートツールと重複します。構成はツールから取得してください。
• 「アイデアが薄いので、汎用的な PRD を書きます。」 代わりに仮説と未解決の質問を表に出してください。定型文だけで済ませてはいけません。
• 「調査は省きます。PRD のことは分かっています。」 調査は PRD の理論ではなく、このアイデアの問題、ユーザー、市場の根拠になります。
• 「高速で直感的であるべきです。」 要件のように見せかけた曖昧な形容詞です。定量化できるベンチマークに置き換えてください。
• 「NFR は実装の詳細です。」 NFR を早期に見落とすと、コストのかかる書き直しにつながります。PRD の作成時に目標値とともに明記してください。
• 「この変更のために PRD 全体を再生成します。」 代わりに、その場で修正し、バージョンと変更履歴を更新してください。

出力

ステップ5の計画可能性の基準を満たす**包括的なPRD（または改訂版）**です。想定する利用者は、PRDからマイルストーンやタスクを導き出す後続の計画フェーズ、このHOWを詳しく定める後続の機能仕様／技術設計、および完成したPRDが同じ12項目の基準を満たしているかを確認するレビュー担当者（reviewing-prd）です。PRDの構成はテンプレートツールが定め、このスキルは内容の品質を担います。媒体はテキスト形式のMarkdownドキュメントです（この手法は媒体に依存しません）。

関連項目

• PRDテンプレートツール（例：content-template-gateway）— このスキルで内容を補う、包括的なPRDのセクション構成を提供します。
• 詳細調査機能 — 与えられたアイデアに関するエビデンスに基づいて、各セクションの内容を作成します。
• reviewing-prd — 完成したPRDが同じ12項目の計画可能性の基準を満たしているかを確認します。作成者とレビュー担当者が同じ基準を共有することで、基準のずれを防ぎます。
• **design-review**スキル — PRDの後続にあるエンジニアリング関連ドキュメント（機能仕様／技術設計／ADR／RFC）を対象とする、関連するゲートです。別のゲートであり、PRD自体には使用しません。
• 一般的な上流のdepends_on：問題提起／市場調査／ビジネスケース／ユーザー調査（推奨事項であり、前提条件ではありません。PRDだけで完結させてください）。

段階的な情報開示

• references/nfr-and-metrics.md — NFRのカテゴリ分類と数値目標の基準、メトリクスフレームワーク（North Star／OKR／HEART／AARRR）、およびガードレール／対抗指標に関するガイダンスを記載しています。要件または目標とメトリクスを作成する際に読み込んでください。
• references/archetype-and-amend.md — アーキタイプ別のセクション重点項目（コンシューマー／B2B／社内向け／プラットフォームAPI／データ・ML／規制対象）と、完全な改訂手順（その場で編集＋バージョン管理＋影響の反映）を記載しています。アーキタイプを指定する場合や改訂する場合に読み込んでください。
• references/sources.md — 手法と品質基準の調査根拠を記載しています（ガイダンスの出典を監査する場合にのみ読み込んでください）。

本文の分量

• description：1,024文字以下（agentskills.ioの上限）。
• 本文：約500行／5,000トークン（目安。品質を優先し、700行／7,000トークンを継続的に超える場合は警告してください）。
• 分量の多い内容はreferences/に置き、必要に応じて読み込みます。