prd-planner

PRD プランナー

一貫した思考を保ち、「左脳と右脳」の間でコンテキストを切り替える際に発生する問題を回避するため、永続的なファイルベースの計画を活用する PRD 作成スキルです。

このスキルが有効になるタイミング

次のような場合に、このスキルが有効になります。

• 明示的に「PRD」、「prd」、「create a PRD」、または「产品需求文档」と言う
• 「product requirements document」または「产品需求」と言う
• 「write a PRD for...」と言う
• 「PRD planning」または「PRD 设计」と言う

PRD に言及せずに「ソリューションを設計する」または「アーキテクチャを設計する」と言った場合は、代わりに architecting-solutions を使用してください。

基本理念

「PRD の作成は、コンテキストの切り替えで散逸するのではなく、追跡可能で、一貫性があり、永続的であるべきです。」

このスキルでは、次のものを組み合わせます。

• PRD の方法論（architecting-solutions より）
• ファイルベースの永続化（planning-with-files より）

コンテキストを失わない、一貫した PRD 作成ワークフローを実現します。

PRD 作成の 4 ファイルパターン

すべての PRD プロジェクトで、4 つのファイルを作成します。

SCOPE（短く、一意で、ケバブケースのスラッグ）を選び、すべてのファイルのプレフィックスとして使用します。

docs/{scope}-prd-notes.md     → Store research, requirements, findings, options
docs/{scope}-prd-task-plan.md → Track PRD creation phases and progress
docs/{scope}-prd.md           → Product requirements (what & why)
docs/{scope}-tech.md          → Technical design (how)

ファイルの用途

ファイル	用途	対象読者	更新するタイミング
{scope}-prd-notes.md	生の調査結果、要件、アーキテクチャの選択肢（A/B/C）	自分＋レビュアー	新しい情報を収集したとき
{scope}-prd-task-plan.md	進捗、フェーズ、チェックボックス、タイムスタンプを記録	PM＋開発リード	各フェーズの完了時
{scope}-prd.md	製品要件（何を、なぜ）、ユーザーフロー	PM＋ステークホルダー＋開発者	要件が明確になった後
{scope}-tech.md	技術設計（API、データフロー、実装）	開発者＋アーキテクト	アーキテクチャの決定後

ワークフロー

┌─────────────────────────────────────────────────────────────────┐
│                     PRD Creation Workflow                       │
├─────────────────────────────────────────────────────────────────┤
│                                                                 │
│  1. Initialize → Create 4 files with template                   │
│  2. Requirements → Gather to {scope}-prd-notes.md               │
│  2.5 Edge Cases → Scan codebase, infer patterns, ask smartly    │
│  3. Analysis → Research best practices, save to notes           │
│  4. Design → Propose architecture options (A/B/C), save to notes │
│  5. PRD → Write product requirements to {scope}-prd.md          │
│  6. Tech → Write technical design to {scope}-tech.md            │
│  7. Validate → Review with user, finalize                       │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘
                    ↓
           All thinking persisted to files
                    ↓
              No context switching

ステップ 1：初期化

テンプレートを使って 4 つのファイルを作成します。

{scope}-prd-task-plan.md

# PRD Task Plan: {Feature Name}

## Goal
Create a PRD and technical design for {feature description}.

## Owner
{User name/role}

## Phases
- [x] Phase 1: Initialize files ✓
- [ ] Phase 2: Gather requirements (CURRENT)
- [ ] Phase 3: Research & analysis
- [ ] Phase 4: Design solution
- [ ] Phase 5: Write PRD
- [ ] Phase 6: Write technical design
- [ ] Phase 7: Validate & finalize

## Status
**Currently in Phase 2** - Gathering requirements from user

## Progress Log
- {timestamp} - Phase 1 complete: Files initialized

{scope}-prd-notes.md

# PRD Notes: {Feature Name}

## Raw Requirements
(Add user requirements as they emerge)

## Constraints
(Add technical, business, time constraints)

## Inferred Patterns (from codebase)

| Edge Case | Source | Pattern Applied |
|-----------|--------|-----------------|
| (Filled after Step 2.5 codebase scan) | | |

## Edge Cases

### Auto-handled (following codebase patterns)
- (Filled after Step 2.5 analysis)

### Confirmed by User
- (Filled after user confirms edge case decisions)

### Open Questions
- (Track questions to ask user)

## Research Findings
(Add research on best practices, similar solutions)

## Architecture Options

- Option A: {Description}
  - Pros: {Advantages}
  - Cons: {Disadvantages}

- Option B: {Description}
  - Pros: {Advantages}
  - Cons: {Disadvantages}

- Option C: {Description}
  - Pros: {Advantages}
  - Cons: {Disadvantages}

**Selected**: Option {X}

{scope}-prd.md

# PRD: {Feature Name}

> Status: DRAFT
> Last updated: {timestamp}

## Table of Contents
- [Problem Statement](#problem-statement)
- [Goals and Non-Goals](#goals-and-non-goals)
- [Success Criteria](#success-criteria)
- [Scope](#scope)
- [Requirements](#requirements)
- [User Flows](#user-flows)
- [Implementation Plan](#implementation-plan)

---

## Problem Statement
_To be filled after requirements gathering_

## Goals and Non-Goals
### Goals
- {Specific achievable outcomes}

### Non-Goals
- {Explicit exclusions}

## Success Criteria
_To be filled with measurable criteria_

## Scope
### In Scope
- {Specific items included}

### Out of Scope
- {Specific items excluded}

... (rest of PRD sections)

{scope}-tech.md

# Technical Design: {Feature Name}

> Status: DRAFT
> Last updated: {timestamp}

## Overview
{High-level technical approach}

## Key Components
{List major components and their responsibilities}

## API Design
{API signatures, request/response formats}

## Data Flow
{How data flows through the system}

## Implementation Details
{Specific implementation notes}

## Migration Plan
{If applicable, how to migrate from existing system}

ステップ 2：要件の収集

確認のための質問をし、回答を {scope}-prd-notes.md に保存します。

質問する主な項目

1. 問題：どのような問題を解決しますか？
2. ユーザー：誰がこれを使いますか？
3. 成功：成功したと、どのように判断しますか？
4. 制約：技術、時間、予算に関する制約はありますか？

各回答を、適切なセクションに分けて {scope}-prd-notes.md に保存します。

情報収集後は、必ず {scope}-prd-task-plan.md を更新してください。

- [x] Phase 2: Gather requirements ✓
- [ ] Phase 2.5: Edge case analysis (CURRENT)
- [ ] Phase 3: Research & analysis

ステップ 2.5：コンテキストを踏まえたエッジケース分析

エッジケースについてユーザーに質問する前に、まずコードベースを調べて、既存のパターンを推測してください。これにより、同じ質問を繰り返すことを減らし、プロジェクトとの一貫性を確保できます。

詳細なリファレンス：スキャンコマンドと出力形式の詳細については、references/edge-case-analysis.md を参照してください。

簡易プロセス

1. コードベースをスキャンして既存のパターンを確認する（削除方針、エラー処理、空の状態、ページネーション）
2. 要件の種類を特定する（CRUD、状態ワークフロー、非同期、データ表示、フォーム、ファイル）
3. 妥当な仮定を導き出す — コードで見つかったパターンについては、ユーザーに確認する必要はありません
4. 必要な場合にのみ質問する — 前例がない場合、複数のパターンがある場合、またはビジネス上の判断が必要な場合

ユーザーに質問する条件

条件	対応
コードベースにパターンがある	自動的に適用し、質問しない
前例が見つからない	選択肢を提示してユーザーに質問する
互いに矛盾する複数のパターンがある	ユーザーに選択してもらう
ビジネスルールが必要	ユーザーに質問する

ノートファイルへの出力

{scope}-prd-notes.md を次の内容で更新します。

## Inferred Patterns (from codebase)
| Edge Case | Source | Pattern Applied |
|-----------|--------|-----------------|
| Delete | `src/models/User.ts:45` | Soft delete |

## Edge Cases
### Auto-handled (following codebase patterns)
- Empty list → Use existing EmptyState component

### Confirmed by User
- Concurrent edit: Last write wins (confirmed {date})

タスク計画を更新します。

- [x] Phase 2.5: Edge case analysis ✓
- [ ] Phase 3: Research & analysis (CURRENT)

ステップ 3：調査と分析

ベストプラクティスを調査し、結果を {scope}-prd-notes.md に保存します。

# Search for similar implementations
grep -r "keyword" packages/ --include="*.ts"

# Search web for best practices
web search "best practices for {feature}"

調査結果を {scope}-prd-notes.md の「調査結果」セクションに保存します。

ステップ 4：ソリューションの設計

トレードオフを含むアーキテクチャを提案し、内容を {scope}-prd-notes.md に保存します。

## Architecture Options

- Option A: {Description}
  - Pros: {Advantages}
  - Cons: {Disadvantages}

- Option B: {Description}
  - Pros: {Advantages}
  - Cons: {Disadvantages}

- Option C: {Description}
  - Pros: {Advantages}
  - Cons: {Disadvantages}

**Selected**: Option {X} - because {reason}

ステップ 5：PRD の作成

{scope}-prd-notes.md を読み、内容を整理して完成度の高い PRD にまとめます。

1. Read {scope}-prd-notes.md to understand:
   - Requirements gathered
   - Research findings
   - Architecture decision (which option was selected)

2. Write {scope}-prd.md with:
   - Clear problem statement
   - Goals and Non-Goals (explicit exclusions)
   - Measurable success criteria (specific numbers/timings)
   - Scope (In Scope / Out of Scope)
   - Functional requirements
   - Non-functional requirements
   - User flows
   - Implementation plan (high level)

3. Reference tech doc: "See {scope}-tech.md for technical design"

ステップ 6：技術設計の作成

1. Read {scope}-prd-notes.md for selected architecture option

2. Write {scope}-tech.md with:
   - Overview (technical approach summary)
   - Key Components (what pieces, responsibilities)
   - API Design (signatures, contracts)
   - Data Flow (how data moves through system)
   - Implementation Details (specific notes)
   - Migration Plan (if applicable)

ステップ 7：検証と仕上げ

ユーザーと確認します：

1. PRD の要約を提示する
2. フィードバックを求める
3. 変更を反映する
4. フェーズ 7 を完了としてマークする

重要なルール

ルール	悪い例	良い例
ファイルを使う	メモリに保持する	{scope}-prd-notes.md に保存する
計画を更新する	更新せずに次へ進む	チェックボックスを付けて task-plan.md を更新する
判断前に読む	記憶を頼りに判断する	先にメモを読む
ドキュメントを分ける	PRD と Tech を混ぜる	PRD は「何を」、Tech は「どのように」を扱う
選択肢を含める	すぐに解決策へ進む	長所と短所を添えて 2～3 個の選択肢を記録する

フェーズの移行

各フェーズの後に、チェックボックス ✓ とタイムスタンプを付けて {scope}-prd-task-plan.md を更新します。

PRD の完了

すべてのフェーズを完了としてマークし、ステータスを「✅ COMPLETE」に設定して、最終成果物を記録します。

ファイルの整理（任意）

PRD の完了後：

• 参照用として {scope}-prd-notes.md を残します（意思決定のプロセスを確認できます）
• {scope}-prd-task-plan.md をアーカイブするか、削除します
• 最終成果物は {scope}-prd.md と {scope}-tech.md です

クイックスタートテンプレート

# PRD Task Plan: {Feature}

## Goal
Create PRD and technical design for {description}

## Phases
- [ ] Initialize 4 files
- [ ] Gather requirements
- [ ] Research & analysis
- [ ] Design solution (A/B/C options)
- [ ] Write PRD
- [ ] Write technical design
- [ ] Validate & finalize

## Status
Phase 1: Initializing files

これが有効な理由

問題	解決策
コンテキストの切り替え	思考内容をすべてファイルに保存し、いつでも読み返せるようにする
要件の紛失	すぐに {scope}-prd-notes.md に保存する
一貫性のない PRD	同じプロセス、同じ構成にする
「左脳と右脳」	一貫したワークフローを 1 つにまとめる
コンテキストの再説明	ファイルにコンテキスト全体を記載する
関心事の混在	PRD（プロダクト）と Tech（実装）を分ける
隠れた意思決定	アーキテクチャの選択肢 A/B/C を記録する

参考資料

• planning-with-files - ファイルベースの計画手法
• architecting-solutions - PRD 以外のソリューションおよびアーキテクチャ設計
• エッジケースの検出：references/edge-case-analysis.md

---

自動トリガー（フォローアップのメタデータ）

このスキルの完了時に、サポートされているフォローアップを記録するか、実行します：

1. self-improving-agent（バックグラウンド） - 再利用可能なパターンを提案する
2. session-logger（自動） - サポートされている場合、セッションのコンテキストを保存する