prd

STARTER_CHARACTER = 📋

PRD ジェネレーター

PRD を生成します。

作業内容

1. ユーザーから機能の説明を受け取ります
2. リポジトリを読み、仕様の根拠を確認します
3. 選択肢にアルファベットを付けて確認の質問をします。必要に応じて、追加のラウンドで反復します
4. 回答に基づいて、構造化された PRD を生成します
5. .llmtmp/prd.md に保存します（スラッグが指定されている場合は .llmtmp/prd-<slug>.md）

注記

実装を開始しないでください。PRD を作成するだけです。

スラッグの決定

ユーザーがスラッグを指定した場合は、それを使用します。指定がない場合は、機能のタイトルから生成します。小文字の英数字とハイフンのみを使用し、20 文字以内にします。

ステップ 1：コンテキストの収集

質問をする前にリポジトリを読みます。情報に基づかない質問は、ユーザーの時間を浪費し、曖昧な仕様につながります。以下の順に確認します。

1. README.md（プロジェクトのルート）
2. CLAUDE.md（存在する場合はプロジェクトのルート）
3. .llmdocs/ 内のすべての .md ファイル
4. プロンプト内でユーザーが指定したファイル
5. 機能に関連するコード：機能の説明に含まれる用語を対象に、grep、Glob、または Serena のシンボル検索を使用します（例：認証機能の場合、認証ミドルウェア、JWT バリデーター、ID マッピングコードを探します）

何が存在するのか、どのような規約が使われているのか、リポジトリではどの用語を使用しているのか、機能によってどのファイルが影響を受けるのかを把握できるまで読みます。そうすれば、仮定に基づくのではなく、実際のコードベースに即した質問ができます。

ステップ 2：確認の質問

最初のプロンプトが曖昧な場合に限り、重要な質問をします。以下に焦点を当てます。

• 問題／目標：どのような問題を解決しますか？
• 中核となる機能：主な操作は何ですか？
• 範囲／境界：何を対象外としますか？
• 成功基準：完了したことをどう判断しますか？

追加の質問ラウンド

複数回の質問ラウンドは例外ではなく、想定されています。最初の回答後にコードをさらに読み込んだり、ユーザーの回答を受けたりすることで、新たな判断事項が見つかることがよくあります。未解決の判断事項がある場合や、ユーザーから異議があった場合は、追加の質問ラウンドをアルファベット付きで行います。PRD には最初の回答ではなく、対話を経た最終状態を反映します。

ユーザーは CLANKER に PRD の草案の修正を依頼することもあります。その場合も追加の質問ラウンドとして扱います。

質問の形式

1. What is the primary goal of this feature?
   A. Improve user onboarding experience
   B. Increase user retention
   C. Reduce support burden
   D. Other: [please specify]

2. Who is the target user?
   A. New users only
   B. Existing users only
   C. All users
   D. Admin users only

3. What is the scope?
   A. Minimal viable version
   B. Full-featured implementation
   C. Just the backend/API
   D. Just the UI

この形式にすると、ユーザーは「1A, 2C, 3B」のように回答して、すばやくやり取りできます。選択肢はインデントします。

ステップ 3：PRD の構成

PRD の読者は、ジュニア開発者または AI エージェントです。専門用語を避け、明確に説明し、要件に番号を付け、具体例を示します。

PRD は以下のセクションで構成します。

1. はじめに／概要

機能の簡潔な説明と、解決する問題を記述します。

2. 目標

具体的で測定可能な目標を箇条書きで示します。

3. ユーザーストーリー

各ストーリーには以下が必要です。

• タイトル：短く、内容が伝わる名前
• 説明：「[ユーザーの役割] は [メリット] を得るために [機能] を必要とする」の形式。[ユーザーの役割] は行為者（プラットフォーム運用者、エンドユーザー、管理者）とし、実装者にはしません
• 受け入れ基準：ストーリー固有の動作について、検証可能な機能上の要件

各ストーリーは、1 回の集中した作業で実装できる程度の規模にします。

形式：

### US-001: [Title]

**Description:** A [user role] needs [feature] so that [benefit].

**Acceptance Criteria:**

- [ ] Specific verifiable functional criterion
- [ ] Another verifiable functional criterion
- [ ] **[UI stories only]** Observable outcome verified in a browser session

注記

受け入れ基準のルール：

• ストーリー固有の動作について、検証可能な機能上の要件を記述します。「正しく動作する」は不適切です。「削除前にボタンが確認ダイアログを表示する」は適切です。
• [ユーザーの役割] はメリットを得る行為者（プラットフォーム運用者、エンドユーザー、管理者）です。実装者、CLANKER、「私たち」、「開発者」、「AI」にはしません。
• コードの品質管理（lint、テスト、型チェックの合格）は納品の前提条件であり、機能の基準ではありません。受け入れ基準には含めません。
• 各基準は単独で意味が通るものにします。ストーリー間の参照（「この実行では US-011 によって範囲が拡張された」など）は避けます。順序に関する事項は「技術的な考慮事項」に移します。
• UI の基準では、検証ツールではなく、観察可能な結果を記述します（例：「ブラウザーセッションに強制再認証画面が表示される」）。

4. 非目標（対象外）

この機能に含まれない内容を記述します。範囲の管理に不可欠です。

5. デザイン上の考慮事項

UI／UX 要件、モックアップへのリンク、再利用する既存コンポーネントを記述します。該当しない場合は「n/a」とします。

6. 技術的な考慮事項

制約、依存関係、統合ポイント、パフォーマンス要件を記載します。該当しない場合は「n/a」と記載してください。

7. 成功指標

成功をどのように測定しますか？ 例：

• 「X の完了にかかる時間を 50％短縮する」
• 「コンバージョン率を 10％向上させる」

8. 未解決の質問

残っている質問を記載します。最大 3 件までです。未解決の質問はブロッカーであり、知っておくとよい程度のものではありません。

出力

• 形式：Markdown（.md）
• 場所：.llmtmp/
• ファイル名：prd.md または prd-<slug>.md

例

記入例は references/example-prd.md を参照してください。

チェックリスト

PRD を保存する前に、次の項目を確認してください。

• 文字付きの選択肢を提示して明確化の質問をした
• ユーザーの回答を反映した
• ユーザーストーリーが小さく、検証可能な受け入れ基準を含んでいる
• 非目標のセクションで明確な境界を定めている
• 未解決の質問が最大 3 件である
• .llmtmp/prd.md（または .llmtmp/prd-<slug>.md）に保存した

いずれかの項目を満たしていない場合は、保存する前に修正して再検証してください。