to-prd

name	to-prd
description	こんなときに使う: 現在の会話内容をもとに、実装・エージェント発注に直結する PRD を作りたいとき。 追加のインタビューはせず、すでに会話に出ている内容だけから構成する。 情報が不足している場合は捏造せず「未確定」として明示する。
disable-model-invocation	true

To PRD

このスキルは、現在の会話コンテキスト（およびリポジトリがあればその理解）をもとに PRD を作成する。

こんなときに使う

• すでに会話に出ている内容だけから、実装・発注に直結する PRD を作りたいとき
• 追加のインタビューをせずに、会話の内容だけで要件を整理したいとき
• 情報が不足している場合でも、捏造せずに未確定として明示したいとき
• リポジトリの実装状況に合わせて、PRD の粒度と制約を揃えたいとき

大原則：書いてよいのは「会話に根拠がある内容」だけ

• 追加のインタビューはしない。すでに会話に出ている内容だけで構成する
• 会話に出ていない機能・ユーザーストーリー・判断を発明しない。網羅性より正確性を優先する
• 会話から推論した内容を書く場合は、文末に「（推定）」と付ける
• 決まっていないことは、決まっているかのように書かず「未確定」として明示する
• セクションを埋めるために内容を水増ししない。書くことがなければ「該当なし」「未確定」と書く

ワークフロー:

Step 0 — 入力充足チェック（ゲート）

PRD を書き始める前に、会話に以下の3点が存在するか確認する。

• 誰の、どんな問題を解決するのか
• 解決策の方向性
• 何ができたら成功なのか（受け入れ条件の素材）

1つでも欠けている場合：欠けている点を列挙してユーザーに提示し、 「このまま未確定として PRD 化する」か「先に happy-core@interview-me などで会話を深める」かを選んでもらう。 勝手に埋めて先に進んではならない。

Step 1 — コンテキストに接地する（リポジトリがある場合のみ）

• まだ実施していない場合は、リポジトリを探索しコードベースの現在状態を理解する
• プロジェクトのドメイン用語集・既存の設計判断（ADR 等）があれば、PRD 全体でそれに従う
• リポジトリがない・アクセスできない場合はこのステップをスキップし、Notes に「コードベース未確認」と記す

Step 2 — テスト境界を決める

• その機能をどの境界でテストするかを先に概略化する
• 新しい境界よりも既存の境界を優先する。可能な限り高い境界を使う
• 境界は少ないほどよい。理想は1つ
• この境界がユーザーの期待と一致しているか、会話内容と照合する。会話に根拠がなければ「未確定」とする

Step 3 — テンプレートを埋める

• 各項目は短く、実装に直結する文章にする
• ファイルパスと具体的なコードスニペットは書かない（すぐに古くなる）
  • 例外：プロトタイプ由来のステートマシン・スキーマ・型の形状など、文章より正確に判断を表現するものは、プロトタイプ由来であることを明記した上でインラインに含めてよい

Step 4 — 出荷前チェックリスト（全項目必須）

• すべてのユーザーストーリー・実装判断が、会話内容に根拠を持つ（推定には「（推定）」が付いている）
• 各 Acceptance Criteria が、外部から観測可能な振る舞いで書かれており、合格/不合格を機械的に判定できる
• 未確定事項がすべて Notes に列挙されている（本文に「決定」として紛れていない）
• ファイルパス・コードスニペットが混入していない（プロトタイプ例外を除く）
• Out of Scope が空でない（「今回やらないこと」が1つも言えない PRD はスコープ検討不足）

Step 5 — 次工程へ渡す

• issue / plan / design へそのまま受け渡せる形で残す
• Issue トラッカーとトリアージラベルの語彙が事前に提供されている場合のみ、Issue として公開しラベルを適用する
• 未確定事項が1つでも残っている PRD には、エージェント自動着手系のラベル（ready-for-agent 等）を付けない。人間のレビューを挟む

生成テンプレート

Problem Statement

ユーザーが直面している問題を、ユーザー視点で 1-2 文で書く。

Solution

その問題に対する解決策を、ユーザー視点で 1-2 文で書く。

User Stories

会話で議論された範囲を漏れなく反映する。会話に出ていないストーリーを追加しない。

1. As a , I want , so that

Acceptance Criteria

• 観測可能な振る舞いで書く（内部実装に言及しない）
• 各項目は合格/不合格が一意に判定できる粒度にする

Implementation Decisions

会話・プロトタイプで決定済みの実装方針のみを列挙する。

• 構築・変更されるモジュールとそのインターフェース
• アーキテクチャ上の判断、スキーマ変更、API 契約

Testing Decisions

• テスト境界（Step 2 の結論）
• 良いテストの定義：実装詳細ではなく、外部から見える振る舞いをテストする
• コードベース内の類似テストの先行事例（あれば）

Out of Scope

• 今回の PRD で扱わないことを箇条書きで書く

Notes

• 未確定事項（必須。なければ「なし」と明記）
• 前提・制約・コードベース未確認などの注記

注意点

• 追加のインタビューをしない前提で、会話の根拠がない内容を勝手に補完しないでください。
• 未確定事項は本文に混ぜず、Notes へ明示してください。
• PRD の空欄を埋めるために、推測でストーリーや条件を増やさないでください。

アンチパターン（やってはいけないこと）

アンチパターン	正しい挙動
「網羅的に」を目指してストーリーを発明する	会話に出た範囲だけを漏れなく書く
未確定な点を自然な文章で「決定」風に書く	Notes に「未確定」として隔離する
テンプレートの空欄を埋めるために推測で書く	「該当なし」「未確定」と書く
情報不足のまま黙って PRD を出力する	Step 0 で不足を提示し、ユーザーに選ばせる
未確定入りの PRD をエージェントに自動発注する	人間レビューを挟んでから発注する