mcpField
P
prd

prd

github.com/snarktank開発36 回インストール
リポジトリ

prd について

機能の説明から、実装に向けたプロダクト要件定義書(PRD)を作成するスキルです。要点を絞った確認質問の後、要件と受け入れ基準を整理し、文書を `/tasks/` に保存します。

主な機能

  1. 01選択肢付きの確認質問
  2. 02構造化された PRD セクション
  3. 03ユーザーストーリーと受け入れ基準
  4. 04番号付きの機能要件
  5. 05PRD を `/tasks/` に保存

活用シーン

  1. 01曖昧な機能リクエストを明確化
  2. 02開発チーム向けの実装要件を準備
  3. 03コーディング前に範囲と対象外を定義
  4. 04UI 作業の検証可能な基準を設定

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/snarktank/amp-skills --skill prd

インストール後、Claude Code で/prdを入力して読み込まれたか確認します。

詳細

PRD ジェネレーター

明確で実行可能な、実装に適した詳細な製品要件定義書を作成します。


作業内容

  1. ユーザーから機能の説明を受け取ります
  2. 重要な確認質問を 3~5 個(選択肢にアルファベットを付けて)尋ねます
  3. 回答に基づいて、構成化された PRD を作成します
  4. /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
- [ ] npm run typecheck passes
- [ ] **[UI stories only]** Verify in browser using dev-browser skill

重要:

  • 受け入れ基準は、曖昧ではなく検証可能なものにしてください。「正しく動作する」は不適切です。「削除する前に、ボタンで確認ダイアログを表示する」は適切です。
  • UI の変更を伴うストーリーでは、 受け入れ基準に必ず「dev-browser スキルを使用してブラウザーで確認する」を含めてください。これにより、フロントエンドの作業を視覚的に検証できます。
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(ケバブケース)

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
- [ ] npm run 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)
- [ ] Badge includes icon: 🔴 high, 🟡 medium, ⚪ low
- [ ] Priority visible without hovering or clicking
- [ ] npm run 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
- [ ] npm run 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
- [ ] npm run typecheck passes
- [ ] Verify in browser using dev-browser 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 → medium → 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 <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 に保存した

コメント