PRD ライター

構造化された PRD 作成のためのスキル集。

逆説的なルール（通常のルールより優先）

これら 5 つのルールは早期に適用され、実際のレビュー サイクルで PRD が却下される最も一般的な理由を先制します。機能リストへの直結の誘惑よりも優先されます。

1. 却下理由書を最初に書く。 下書き前に、実際のステークホルダー（経営陣、エンジニアリング リード、コンプライアンス、ファイナンス、GTM）がこの PRD を却下する理由を 3～5 つ列挙します。それぞれに明示的に対処するように PRD を設計します。これは /write-prd フェーズ 0.5 パート A で実装されます。
2. 広いビジョンの前に MVP 要求を絞る。 最小限の検証可能なスコープを最初に定義します。後のフェーズは conditional_on_phase_1_learnings です。約束ではありません。
3. 機能の前に終了基準を設計する。 機能がスコープから切り離された場合に PRD の目的を破壊せずにきれいに削除できない場合、その価値主張は弱い可能性があります。
4. 磨きではなく決定的な証拠にエンジニアリング予算を割り当てる。 「仮説は本当か？」に答える粗いプロトタイプ 1 つは、コア仮定に触れない細心に作られた機能 3 つに勝ります。
5. フォールバック ナラティブを事前に定義する。 主要 KPI がパフォーマンスを下回る場合、セカンダリー値（保持、コスト削減、学習）を事前に指定し、作業が遡及的に失敗と判定されないようにします。

各ルールの改善前後の例は references/counterintuitive-prd.md を参照してください。

サブスキル

スキル	説明
/write-prd	5 フェーズ PRD ワークフロー：コンテキスト読み込み、製品タイプ ルーティング、証拠パック、実装詳細境界、審問、前提条件チェック、下書き（条件表、例外カバレッジ、インライン ダイアグラム、エクスポート プロファイル付き）、グリル駆動型レビュー
/prd-refine	クイック PRD ポーリッシング — 直ちに編集、詳細を保持、計画なし
/opus-prd-polish	公開前の最終トップティア ポーリッシング パス（利用可能な最高の推論モデルを使用）
/grill-me	執拗な審問を通じて計画やアイデアをストレステスト
/prd-score	Ready-to-Dev ルーブリック、実装リーク、原子圧力、条件統合、例外カバレッジ、証拠カバレッジ、ダイアグラム整合性、エクスポート準備に対して PRD をスコアリング
/prd-split	PRD をオーディエンス固有の要件ドキュメントに分割。ゲーム プロジェクトは GDD/TDD/Art/BD を使用できます。非ゲーム プロジェクトはエージェント スペック、評価計画、ワークフロー スペック、権限マトリックス、メトリック辞書、API コントラクト サマリー、実験ブリーフなどのパックを使用します

デザイン ルール

• RTP、オッズ、規制上の事実、市場データを発明しない
• 仮定を確認済みの事実と分離する
• アート/デザイン要件は独自のセクションに留める
• 長い PRD はチャットではなくファイルに書く
• 不確実な事実には to_be_confirmed または pending_math_table でマークする
• PRD は実装設計ではなく製品契約を説明します。デフォルトでは semantic_contract_only を使用します。Redis、データベース スキーマ、キャッシュ/キュー設計、サービス境界、フレームワーク選択、SDK 選択、デプロイメント トポロジを回避します。ユーザーがこのアーティファクトに属することを明示的に確認しない限り。
• 原子的な実装言語を避けます。ユーザーに見える結果、決定ルール、受け入れ基準の代わりに説明します。内部タスク分解を強制しないでください。
• 複雑な判断ロジックを決定テーブルに統合します。同じ条件をネストされたバレットまたは複数のセクションに分散させないでください。
• すべてのコア フローは通常パスと例外パスが必要です。障害、復旧、ユーザーに見えるメッセージングを含みます。
• 下書き前に product_type を検出して記録します。サポートされているファーストクラス タイプ：game_interactive、ai_agent、b2b_saas_ops、data_analytics、platform_marketplace、consumer_growth、content_learning、mixed。
• ユーザーがインタビュー、チケット、アナリティクス、市場ノート、競合ページ、スクリーンショット、Confluence/Jira/Slack 参照、またはその他の証拠を提供する場合は、research_pack を記録します。
• ダイアグラムはインライン Mermaid のみです。フロー、シーケンス、ワイヤーフレーム、アーキテクチャ、ジャーニー マップ、権限マップ、決定ループ、評価ループ、成長ループはすべて ```mermaid コード フェンスに入ります。外部ダイアグラム ツールは不要です。
• output_profile を obsidian_md、word_docx、pdf、confluence、または multi として記録します。Markdown はソースの真実のままです。エクスポートは見出し、表、Mermaid ソース ブロック、ソース参照を保持する必要があります。

言語ポリシー（2 段階）

1. プロズ + セクション タイトル — ユーザー設定に従う（中文 / English / その他）。強制されません。
2. 変数、状態、イベント、設定フィールド、API 識別子 — 常に英語 です。プロズの言語に関わらず。これは譲歩できません。これにより、PRD は複数のチームで実装可能な状態に保たれます。

中国語 PRD の例：

功能需求

• 状態機：idle → spinning → settling → payout
• 事件：on_spin_start、on_reel_stop
• 配置字段：reel_count、rtp_target

依存関係

バンドル済み（このリポジトリに含まれる）：

• write-prd、prd-refine、opus-prd-polish、grill-me、prd-score

外部（別途インストール）：

• gstack — ヘッドレス ブラウザ QA、デザイン レビュー、デプロイメント検証

フェーズ 3.5 ダイアグラムはインライン Mermaid のみを使用します（GitHub、Obsidian、VS Code でネイティブレンダリング）。Word/PDF/Confluence ユーザーは Obsidian から レンダリングされたダイアグラムをエクスポートするか、エクスポートされた静止画像の横に Mermaid ソースを保持できます。外部ダイアグラム スキルは不要です。