prd

PRD ジェネレーター

明確で実行可能な、実装に適した詳細なプロダクト要件ドキュメント（PRD）を作成します。PRDの確認後、/to-issues を使用して Issue に分解し、必要に応じてその前に /prd-to-spec を使って技術設計を行います。

---

作業内容

1. ユーザーから機能の説明を受け取ります
2. 重要な曖昧さを解消するため、確認の質問をします。質問数は固定ではなく、複雑さに応じて調整します（ステップ 1 を参照）
3. 回答に基づいて、構成された PRD を生成します
4. PRD をユーザーに提示してレビューを依頼します — 「PRD を確認してください。修正が必要な場合はお知らせください。問題なければ OK と返信してください。」
5. 修正を反映し、tasks/prd-[feature-name].md に保存します
6. 次のステップを提案します（ステップ 3 を参照）

---

重要： 実装を開始しないでください。PRD の作成のみを行います。

---

ステップ 1：確認の質問

最初のプロンプトに曖昧な点がある場合に限り、重要な質問をします。質問数は機能の複雑さに応じて調整してください。目標は固定数に達することではなく、重要な曖昧さを解消することです。

• シンプルで範囲が明確な機能： 2～3 個の質問
• 一般的な機能： 3～5 個の質問
• 複雑な機能（複数のユーザーロール、システム間連携、大きな曖昧さがある場合）：6～8 個の質問

ユーザーの入力からすでに明確な点は質問せず、数合わせのための質問は避けてください。次の点に注目します。

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

質問の形式：

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」のように回答できるため、すばやくやり取りできます。選択肢にはインデントを付けてください。

---

エッジケースとフォールバック

シナリオ	対応
ユーザーが確認の質問を省略する（例：「なんでもいい」「とにかく書いて」と返信する）	妥当なデフォルトを設定し、PRD 内で [Assumption] を付けて明示し、レビュー時にユーザーへ確認を促します
ユーザーの入力が曖昧すぎる（例：「機能を追加して」）	具体的な内容を一度質問します。それでも曖昧な場合は、プロジェクトのコンテキストから推測し、前提を明記します
tasks/ ディレクトリが存在しない	tasks/ ディレクトリを自動作成します
入力から feature-name を特定しにくい	ユーザーに直接「PRD のファイル名案は prd-XXX.md です。確認するか、変更してください」と尋ねます
レビュー後にユーザーが PRD の変更を希望する	確認の質問の手順をやり直さず、変更を反映して再保存します
PRD が 500 行を超える	複数のサブ機能の PRD に分割することを検討するよう提案します
ユーザーが続行を希望しない	PRD のみを保存します。ユーザーは後で /to-issues を実行できます
後で Issue の作成が必要になった	保存した PRD ファイルを指定して /to-issues を実行するよう提案します

---

ステップ 2：PRD の構成

次のセクションを含む PRD を生成します。

1. はじめに／概要

機能と、それが解決する問題を簡潔に説明します。専門用語を避けるか、使う場合は説明してください。読者がジュニア開発者や AI エージェントである可能性を想定します。

2. 目標

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

3. ユーザーストーリー

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

• タイトル： 簡潔で説明的な名前
• 説明： 「[ユーザー]として、[メリット]を得るために[機能]を使いたい」
• 受け入れ条件： 「完了」の定義を示す、検証可能なチェックリスト

番号付けのルール： US-001、US-002、US-003…（3桁で、001から開始）。各USは個別に実装でき、1回の集中したエージェントセッションで完了できる程度の小ささにしてください。

必須のE2Eテストストーリー： すべてのPRDに、最後のユーザーストーリーとして、エンドツーエンド（E2E）テストのユーザーストーリーを1つ含める必要があります。このストーリーでは、独立した単体テストではなく、ユーザーの操作からUI、API、データレイヤーまで、スタック全体にわたる機能の一連の流れを検証します。受け入れ条件には、実際のユーザーが機能の主な目的を達成するまでの正常系の一連の操作に加え、少なくとも1つの重要なエッジケースまたは失敗経路を記述し、すべてを自動E2Eテストで検証します（例：UIにはPlaywright/Cypress、バックエンドのみの機能にはAPIレベルの統合テスト）。このストーリーは他のすべてのストーリーに依存し、機能が全体として動作することを確認します。

受け入れ条件のセルフチェック用テンプレート： 各条件は、以下の少なくとも1つを満たす必要があります。満たさない場合は「曖昧」とみなされ、書き直す必要があります。

• 観察可能：具体的なUI状態またはAPIレスポンスを記述している（例：「ボタンを押すと確認ダイアログが表示される」）
• テスト可能：明確な入力と出力の組み合わせがある（例：「空のメールアドレスを入力すると赤い警告が表示される」）
• 検証可能：ツールで確認できる（例：「型チェック／lintがパスする」）
• ❌ 悪い例：「正しく動作する」「優れたユーザーエクスペリエンス」「優れたパフォーマンス」→ 検証できません

形式：

### US-001: [Title]
**Description:** As a [user], I want [feature] so that [benefit].

**Acceptance Criteria:**
- [ ] Specific verifiable criterion
- [ ] Another criterion
- [ ] Typecheck/lint passes
- [ ] **[UI stories only]** Verify in a browser (e.g., via the `run` skill)

E2Eストーリーの形式：

### US-NNN: End-to-end test of [feature] flow
**Description:** As a QA engineer, I want an automated end-to-end test covering the full [feature] journey so that we catch regressions across the entire stack.

**Acceptance Criteria:**
- [ ] Automated E2E test simulates the full happy path (user action → UI → API → data → visible result)
- [ ] Covers at least one critical edge/failure path (e.g., invalid input, empty state, permission denied)
- [ ] Test runs in CI and passes
- [ ] Test is independent and repeatable (sets up and tears down its own data)

重要：

• 受け入れ条件は曖昧ではなく、検証可能でなければなりません。「正しく動作する」は不適切です。「削除前にボタンを押すと確認ダイアログが表示される」は適切です。
• UIに変更があるストーリーでは必ず、「ブラウザーで確認する」を受け入れ条件に含めてください（例：run スキルを使用）。これにより、フロントエンドの作業を視覚的に検証できます。

4. 機能要件

具体的な機能を番号付きのリストで記述します。

• 「FR-1：システムはユーザーが…できるようにする必要があります」
• 「FR-2：ユーザーがXをクリックしたとき、システムは…する必要があります」

FRの仕様： 各FRは FR-N:（Nは1から順に増加）で始め、「system must / system shall」に相当する表現を使い、1つの具体的な動作を記述します。1つのFRに複数の動作を「および」で結び付けないでください。

5. 非目標（対象外）

この機能に含まれないものを記述します。スコープの管理に不可欠です。

6. 設計上の考慮事項（任意）

• UI/UX要件
• モックアップがある場合はそのリンク
• 再利用する関連既存コンポーネント

7. 技術上の考慮事項（任意）

• 既知の制約または依存関係
• 既存システムとの統合ポイント
• パフォーマンス要件

8. 成功指標

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

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

9. 未解決の質問

確認が必要な未回答の質問または領域。

---

出力

• 形式： Markdown（.md）
• 場所： tasks/
• ファイル名： prd-[feature-name].md（ケバブケース）

---

ステップ3：次のステップ

PRDを保存した後、ユーザーに次を提案します。

✅ PRD saved to tasks/prd-[feature-name].md

Next steps:
  /prd-to-spec  →  Generate technical SPEC (optional — for complex features)
  /to-issues    →  Decompose into Issues and create tickets

Or go straight to implementation:
  /to-issues    →  Create Issues, then /goal to implement

ユーザーが進めることを希望する場合は、対応するスキルを呼び出します。

---

PRDの例

# PRD: Task Priority System

## Introduction

Add priority levels to tasks so users can focus on what matters most. Tasks can be marked as high, medium, or low priority, with visual indicators and filtering to help users manage their workload effectively.

## Goals

- Allow assigning priority (high/medium/low) to any task
- Provide clear visual differentiation between priority levels
- Enable filtering and sorting by priority
- Default new tasks to medium priority

## User Stories

### US-001: Add priority field to database
**Description:** As a developer, I need to store task priority so it persists across sessions.

**Acceptance Criteria:**
- [ ] Add priority column to tasks table: 'high' | 'medium' | 'low' (default 'medium')
- [ ] Generate and run migration successfully
- [ ] Typecheck passes

### US-002: Display priority indicator on task cards
**Description:** As a user, I want to see task priority at a glance so I know what needs attention first.

**Acceptance Criteria:**
- [ ] Each task card shows colored priority badge (red=high, yellow=medium, gray=low)
- [ ] Priority visible without hovering or clicking
- [ ] Typecheck passes
- [ ] Verify in a browser (e.g., via the `run` skill)

### US-003: Add priority selector to task edit
**Description:** As a user, I want to change a task's priority when editing it.

**Acceptance Criteria:**
- [ ] Priority dropdown in task edit modal
- [ ] Shows current priority as selected
- [ ] Saves immediately on selection change
- [ ] Typecheck passes
- [ ] Verify in a browser (e.g., via the `run` skill)

### US-004: Filter tasks by priority
**Description:** As a user, I want to filter the task list to see only high-priority items when I'm focused.

**Acceptance Criteria:**
- [ ] Filter dropdown with options: All | High | Medium | Low
- [ ] Filter persists in URL params
- [ ] Empty state message when no tasks match filter
- [ ] Typecheck passes
- [ ] Verify in a browser (e.g., via the `run` skill)

### US-005: End-to-end test of task priority flow
**Description:** As a QA engineer, I want an automated end-to-end test covering the full priority journey so that we catch regressions across the entire stack.

**Acceptance Criteria:**
- [ ] E2E test creates a task, sets its priority via the edit modal, and asserts the badge color updates on the card
- [ ] Test applies a priority filter and asserts only matching tasks remain visible
- [ ] Covers edge case: filtering to a priority with no tasks shows the empty state message
- [ ] Test runs in CI and passes
- [ ] Test sets up and tears down its own task data

## Functional Requirements

- FR-1: Add `priority` field to tasks table ('high' | 'medium' | 'low', default 'medium')
- FR-2: Display colored priority badge on each task card
- FR-3: Include priority selector in task edit modal
- FR-4: Add priority filter dropdown to task list header
- FR-5: Sort by priority within each status column (high to medium to low)

## Non-Goals

- No priority-based notifications or reminders
- No automatic priority assignment based on due date
- No priority inheritance for subtasks

## Technical Considerations

- Reuse existing badge component with color variants
- Filter state managed via URL search params
- Priority stored in database, not computed

## Success Metrics

- Users can change priority in under 2 clicks
- High-priority tasks immediately visible at top of lists
- No regression in task list performance

## Open Questions

- Should priority affect task ordering within a column?
- Should we add keyboard shortcuts for priority changes?

---

チェックリスト

PRDを保存する前に、以下を確認してください。

• 選択肢に文字を付けて、明確化のための質問をした
• ユーザーの回答を反映した
• ユーザーストーリーが小さく、具体的である
• 最後のユーザーストーリーとして、必須のエンドツーエンド（E2E）テストストーリーを含めた
• 機能要件に番号が付いており、曖昧さがない
• 非目標セクションで明確な境界を定義した
• tasks/prd-[feature-name].md に保存した
• 次のステップとして /prd-to-spec（任意）と /to-issues を提案した