AgentSkillsCN

prd

生成新功能的产品需求文档(PRD)。在进行功能规划、启动新项目以及提交PRD编写请求时使用。触发条件:创建PRD、为……撰写PRD、规划此功能、制定需求、细化规格。

SKILL.md
--- frontmatter
name: prd
description: "新機能のプロダクト要求仕様書(PRD)を生成します。機能の計画、新プロジェクトの開始、PRD作成の依頼時に使用します。トリガー: create a prd, write prd for, plan this feature, requirements for, spec out."
user-invocable: true

PRD ジェネレーター

明確で実行可能な、実装に適したプロダクト要求仕様書を作成します。


やること

  1. ユーザーから機能の説明を受け取る
  2. 3〜5個の重要な確認質問をする(選択肢付き)
  3. 回答に基づいて構造化されたPRDを生成する
  4. tasks/prd-[機能名].md に保存する

重要: 実装は開始しないこと。PRDの作成のみを行う。


ステップ1: 確認質問

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

  • 課題/目標: これはどんな問題を解決するか?
  • コア機能: 主要なアクションは何か?
  • スコープ/境界: 何を含めないか?
  • 成功基準: 完了をどう判断するか?

質問のフォーマット例:

code
1. この機能の主な目標は何ですか?
   A. ユーザーオンボーディング体験の改善
   B. ユーザー定着率の向上
   C. サポート負担の軽減
   D. その他: [具体的に記載してください]

2. 対象ユーザーは誰ですか?
   A. 新規ユーザーのみ
   B. 既存ユーザーのみ
   C. すべてのユーザー
   D. 管理者ユーザーのみ

3. スコープはどの程度ですか?
   A. 最小限の実行可能なバージョン
   B. フル機能の実装
   C. バックエンド/APIのみ
   D. UIのみ

これにより、ユーザーは「1A, 2C, 3B」のように素早く回答できます。選択肢はインデントすること。


ステップ2: PRD構造

以下のセクションでPRDを生成する:

1. はじめに/概要

機能とそれが解決する問題の簡潔な説明。

2. 目標

具体的で測定可能な目標(箇条書き)。

3. ユーザーストーリー

各ストーリーに必要なもの:

  • タイトル: 短い説明的な名前
  • 説明: 「[ユーザー]として、[機能]を使って[メリット]を得たい」
  • 受け入れ基準: 「完了」を意味する検証可能なチェックリスト

各ストーリーは1回の集中作業セッションで実装できる程度の小ささにする。

フォーマット:

markdown
### US-001: [タイトル]
**説明:** [ユーザー]として、[機能]を使って[メリット]を得たい。

**受け入れ基準:**
- [ ] 具体的で検証可能な基準
- [ ] 別の基準
- [ ] 型チェック/lintが通る
- [ ] **[UIストーリーのみ]** dev-browserスキルを使用してブラウザで確認

重要:

  • 受け入れ基準は曖昧ではなく検証可能でなければならない。「正しく動作する」は悪い例。「ボタンが削除前に確認ダイアログを表示する」は良い例。
  • 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-[機能名].md(ケバブケース)

PRDの例

markdown
# PRD: タスク優先度システム

## はじめに

ユーザーが最も重要なことに集中できるよう、タスクに優先度レベルを追加します。タスクは高・中・低の優先度でマークでき、視覚的なインジケーターとフィルタリングによりワークロードを効果的に管理できます。

## 目標

- 任意のタスクに優先度(高/中/低)を割り当てられるようにする
- 優先度レベル間の明確な視覚的区別を提供する
- 優先度によるフィルタリングとソートを可能にする
- 新規タスクのデフォルトを中優先度にする

## ユーザーストーリー

### US-001: データベースに優先度フィールドを追加
**説明:** 開発者として、タスクの優先度をセッション間で保持できるようにストレージが必要です。

**受け入れ基準:**
- [ ] tasksテーブルに優先度カラムを追加: 'high' | 'medium' | 'low' (デフォルト 'medium')
- [ ] マイグレーションを生成して正常に実行
- [ ] 型チェックが通る

### US-002: タスクカードに優先度インジケーターを表示
**説明:** ユーザーとして、一目で優先度を確認して何に最初に注意を払うべきか知りたい。

**受け入れ基準:**
- [ ] 各タスクカードに色付きの優先度バッジを表示(赤=高、黄=中、グレー=低)
- [ ] ホバーやクリックなしで優先度が見える
- [ ] 型チェックが通る
- [ ] dev-browserスキルを使用してブラウザで確認

### US-003: タスク編集に優先度セレクターを追加
**説明:** ユーザーとして、タスクを編集するときに優先度を変更したい。

**受け入れ基準:**
- [ ] タスク編集モーダルに優先度ドロップダウン
- [ ] 現在の優先度が選択された状態で表示
- [ ] 選択変更時に即座に保存
- [ ] 型チェックが通る
- [ ] dev-browserスキルを使用してブラウザで確認

### US-004: 優先度でタスクをフィルター
**説明:** ユーザーとして、集中しているときに高優先度のアイテムのみを表示するようにタスクリストをフィルターしたい。

**受け入れ基準:**
- [ ] フィルタードロップダウンにオプション: すべて | 高 | 中 | 低
- [ ] フィルターがURLパラメータに保持される
- [ ] フィルターに一致するタスクがない場合の空状態メッセージ
- [ ] 型チェックが通る
- [ ] dev-browserスキルを使用してブラウザで確認

## 機能要件

- FR-1: tasksテーブルに`priority`フィールドを追加 ('high' | 'medium' | 'low', デフォルト 'medium')
- FR-2: 各タスクカードに色付き優先度バッジを表示
- FR-3: タスク編集モーダルに優先度セレクターを含める
- FR-4: タスクリストヘッダーに優先度フィルタードロップダウンを追加
- FR-5: 各ステータスカラム内で優先度でソート(高から中から低へ)

## 非目標

- 優先度に基づく通知やリマインダーはなし
- 期限に基づく自動優先度割り当てはなし
- サブタスクの優先度継承はなし

## 技術的考慮事項

- 色バリアント付きの既存バッジコンポーネントを再利用
- フィルター状態はURLサーチパラメータで管理
- 優先度はデータベースに保存し、計算しない

## 成功指標

- ユーザーは2クリック以内で優先度を変更できる
- 高優先度タスクがリストの上部にすぐに表示される
- タスクリストのパフォーマンスに悪影響がない

## 未解決の質問

- 優先度はカラム内のタスクの順序に影響すべきか?
- 優先度変更のキーボードショートカットを追加すべきか?

チェックリスト

PRDを保存する前に:

  • 選択肢付きの確認質問をした
  • ユーザーの回答を反映した
  • ユーザーストーリーは小さく具体的
  • 機能要件は番号付きで曖昧さがない
  • 非目標セクションで明確な境界を定義
  • tasks/prd-[機能名].md に保存した