prd について
PRD Generatorは、機能の説明を実装に使えるプロダクト要件文書にまとめるスキルです。選択肢付きの確認質問を行い、要件と受け入れ基準を構成してtasks/に保存します。
主な機能
- 01選択肢付きの重要な確認質問
- 02目標とユーザーストーリーの整理
- 03機能要件と対象外項目の定義
- 04検証可能な受け入れ基準の作成
- 05PRDをMarkdown形式でtasks/に保存
活用シーン
- 01曖昧な機能依頼の明確化
- 02開発者向けの範囲を定めた要件準備
- 03UIやロジック作業の受け入れ基準作成
- 04成功指標と未解決事項の記録
インストール
コマンドをコピーしてターミナルで実行します。
$
npx skills add https:/ / github.com/ ralphcrisostomo/ nuxt-development-skills --skill prdインストール後、Claude Code で/prdを入力して読み込まれたか確認します。
詳細
PRD ジェネレーター
明確で実行可能な、実装に適した詳細なプロダクト要件定義書を作成します。
役割
- ユーザーから機能の説明を受け取ります
- 重要な確認質問を3~5個尋ねます(選択肢には文字を付けます)
- 回答に基づいて、構成されたPRDを作成します
tasks/prd-[feature-name].mdに保存します
重要: 実装を始めないでください。PRDを作成するだけです。
ステップ1:確認質問
最初のプロンプトに曖昧な点がある場合に限り、重要な質問をしてください。次の点に重点を置きます。
- 課題/目標: どのような課題を解決しますか?
- 中核となる機能: どのような操作ができますか?
- 範囲/境界: 何を対象外としますか?
- 成功基準: 何をもって完了と判断しますか?
質問の形式
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」のように回答でき、やり取りをすばやく進められます。選択肢はインデントすることを忘れないでください。
ステップ2:PRDの構成
次のセクションでPRDを作成します。
1. はじめに/概要
機能と、解決する課題について簡潔に説明します。
2. 目標
具体的で測定可能な目標を箇条書きで示します。
3. ユーザーストーリー
各ストーリーには以下が必要です。
- タイトル: 短く内容がわかる名前
- 説明: 「[ユーザー]として、[メリット]を得るために[機能]を使いたい」
- 受け入れ基準: 「完了」の条件を確認できるチェックリスト
各ストーリーは、1回の集中した作業で実装できる規模にしてください。
形式:
### 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 browser using dev-browser skill
- [ ] **[AWS/GraphQL stories only]** Use nuxt-terraform skill
- [ ] **[Stories with testable logic]** Write tests using vitest-testing skill
重要:
- 受け入れ基準は曖昧ではなく、確認可能な内容にしてください。「正しく動作する」は不適切です。「削除前にボタンで確認ダイアログを表示する」は適切です。
- UIを変更するストーリーでは必ず、「dev-browserスキルを使ってブラウザーで確認する」を受け入れ基準に含めてください。 これにより、フロントエンドの作業を視覚的に確認できます。
- テスト可能なロジック(コンポーザブル、サービス、ユーティリティ、Lambdaハンドラー)を含むストーリーでは必ず、「vitest-testingスキルを使ってテストを書く」を受け入れ基準に含めてください。
4. 機能要件
具体的な機能を番号付きリストで示します。
- 「FR-1:システムはユーザーが……できるようにする必要があります」
- 「FR-2:ユーザーがXをクリックしたとき、システムは……する必要があります」
明確かつ曖昧さのない記述にしてください。
5. 非目標(対象外)
この機能に含めない内容を記載します。範囲を管理するうえで重要です。
6. デザイン上の考慮事項(任意)
- UI/UXの要件
- 利用可能な場合はモックアップへのリンク
- 再利用する関連既存コンポーネント
7. 技術上の考慮事項(任意)
- 既知の制約や依存関係
- 既存システムとの統合箇所
- パフォーマンス要件
8. 成功指標
成功をどのように測定するかを記載します。
- 「Xの完了にかかる時間を50%短縮する」
- 「コンバージョン率を10%向上させる」
9. 未解決の質問
残っている質問や、明確化が必要な項目を記載します。
初級開発者向けの書き方
PRDを読むのは、初級開発者やAIエージェントかもしれません。そのため、次の点に注意してください。
- 明確かつ曖昧さのない記述にする
- 専門用語を避けるか、説明を加える
- 目的と中核となるロジックを理解できるだけの詳細を記載する
- 参照しやすいように要件に番号を付ける
- 役立つ場合は具体例を挙げる
出力
- 形式: Markdown(
.md) - 保存先:
tasks/ - ファイル名:
prd-[feature-name].md(kebab-case)
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
- [ ] Write tests using vitest-testing skill
### 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 browser using dev-browser 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 browser using dev-browser 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 browser using dev-browser skill
- [ ] Write tests using vitest-testing skill
## 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を保存する前に、次の項目を確認してください。
- 文字付きの選択肢を使って確認質問をした
- ユーザーの回答を反映した
- ユーザーストーリーが小さく、具体的である
- 機能要件に番号が付いており、曖昧さがない
- 非目標セクションで範囲が明確に定義されている
-
tasks/prd-[feature-name].mdに保存した
コメント
Markdown 対応