prd

PRD 作成スキル

RFC レビューに適し、AI エージェントが実装に使えるプロダクト要件定義書を作成します。

PRD では、何を、なぜ構築するのかを記述します。どのように、どの順序で構築するかは記述しません。

ワークフロー

1. コンテキストを把握する

ユーザーが問題と初期のアイデアを説明します。コードベースを調べ、既存のパターン、制約、依存関係を把握します。

2. 設計ツリーに沿ってヒアリングする

設計上の意思決定ツリーを分岐ごとに確認します。意思決定の各ポイントでは、次の点に従います。

• まずコードベースを調べる — コードから答えが得られない場合にのみ、ユーザーに質問します
• 1ターンにつき1つのトピック — 複数の質問を一度にまとめて提示しません
• 次に進む前に、意思決定間の依存関係を解決します

ツリーが分岐するにつれて、次の領域を網羅します。

• 問題と動機（何か、誰が関わるか、なぜ今なのか、何もしない場合のコスト）
• ユーザーとステークホルダー
• 完了時の状態と成功基準
• スコープと境界（対象となるもの、明示的な対象外、影響を与えてはならないもの）
• 制約（パフォーマンス、セキュリティ、互換性、アクセシビリティ）
• リスクと依存関係
• 検討した代替案

曖昧な用語や意味が広すぎる用語が出てきた場合は、それを指摘し、標準的な用語を提案します。

共通認識に至るまで続けます。質問数に人為的な上限は設けません。

3. モジュールを特定する

構築または変更する主要なモジュールの概要を作成します。深いモジュール（多くの実装を隠す小さなインターフェースを持ち、単独でテスト可能なモジュール）として切り出せる箇所を探します。

ユーザーに次の点を確認します。

• これらのモジュールはユーザーの想定と一致していますか？
• どのモジュールに専用のテストが必要ですか？

4. PRD を作成する

以下のテンプレートを使って、機能に関連するセクションだけを含む Markdown 形式の PRD をプロジェクトのルートに prd-<feature-name>.md として生成します。

テンプレート

# PRD: <Feature Name>

**Date:** <YYYY-MM-DD>

---

## Problem Statement

### What problem are we solving?
Clear description of the problem. Include user impact and business impact.

### Why now?
What triggered this work? Cost of inaction?

### Who is affected?
- **Primary users:** Description
- **Secondary users:** Description

---

## Proposed Solution

### Overview
One paragraph describing what this feature does when complete.

### User Experience (if applicable)
How will users interact with this feature? Include user flows for primary scenarios.

### Design Considerations (if applicable)
- Visual/interaction requirements
- Accessibility requirements (WCAG level)
- Platform-specific considerations

---

## End State

When this PRD is complete, the following will be true:

- [ ] Capability 1 exists and works
- [ ] Capability 2 exists and works
- [ ] All acceptance criteria pass
- [ ] Tests cover the new functionality
- [ ] Observability/monitoring is in place

---

## Acceptance Criteria

### Feature: <Name>
- [ ] Criterion 1
- [ ] Criterion 2
- [ ] Criterion 3

---

## Durable Architectural Decisions

Decisions unlikely to change regardless of implementation order:

- **Routes/URL patterns:** ...
- **Schema shape:** ...
- **Key data models:** ...
- **Auth/authorisation approach:** ...
- **Third-party service boundaries:** ...

Include only what applies. These anchor the PRD for anyone implementing from it.

---

## Modules

Major modules to build or modify, with interface sketches where helpful.

Do NOT include specific file paths or code snippets — they become outdated quickly. Describe modules by name and responsibility.

- **Module name:** What it owns, what it hides, how callers interact with it
- **Module name:** ...

---

## Testing Strategy

- Which modules are tested and at which tier (unit / integration / component / e2e)
- What makes a good test for this feature (test behaviour through public interfaces, not implementation)
- Prior art — similar test patterns already in the codebase

---

## Technical Context

### Existing Patterns
Patterns in the codebase to follow (describe by name and purpose, not file paths):
- Pattern name — why relevant, how it applies

### System Dependencies
- External services/APIs
- Package requirements
- Infrastructure requirements

### Data Model Changes (if applicable)
- New entities/tables
- Schema migrations required
- Data backfill considerations

---

## Boundary Tiers

### Always (conventions to follow)
- Convention 1
- Convention 2

### Ask First (decisions needing human input)
- Decision area 1
- Decision area 2

### Never (must not be touched)
- Protected area 1 — why
- Protected area 2 — why

---

## Risks & Mitigations

| Risk | Likelihood | Impact | Mitigation |
|------|------------|--------|------------|
| Risk 1 | High/Med/Low | High/Med/Low | How to mitigate |

---

## Alternatives Considered

### Alternative 1: <Name>
- **Description:** Brief description
- **Pros:** What's good about it
- **Cons:** Why we didn't choose it
- **Decision:** Why rejected

---

## Non-Goals (v1)

Explicitly out of scope:
- Thing we're not building — why deferred
- Future enhancement — why deferred

---

## Interface Specifications (if applicable)

### CLI

command-name [args] [options]

### API

POST /api/endpoint Request: { field: type } Response: { field: type } Errors: 4xx/5xx scenarios

---

## Success Metrics (if applicable)

How we'll know this worked:
- Metric 1: current → target (how measured)
- Metric 2: current → target (how measured)

---

## Open Questions

- Question 1
- Question 2

主な原則

解決策より先に問題を記述する

問題から始めます。何もしない場合のコストを定量化し、なぜ重要なのかを明確にします。

プロセスではなく完了時の状態を定義する

完了時に何が存在するのかを記述します。実装の順序、優先順位、フェーズを指定しません。

ファイルパスを記載しない

ファイルパスやコードスニペットは古くなります。パターンは名称と目的で説明します。モジュールは場所ではなく責務で参照します。

境界によってスコープの逸脱を防ぐ

明確な境界レベル（常に／事前に確認／禁止）と対象外の事項を定め、エージェントが安定したコードに手を加えたり、依頼されていない機能を構築したりするのを防ぎます。

テスト戦略はアーキテクチャそのもの

どのモジュールをどの層でテストするかによって、アーキテクチャが明らかになります。深いモジュールには境界テスト、純粋なロジックには単体テスト、組み合わせ部分には統合テストを実施します。

悪い例と良い例

悪い例（指示的／フェーズ分け）

## Phase 1: Database
1. Create users table
2. Add indexes

## Phase 2: API
1. Build registration endpoint

悪い例（RFC に必要なコンテキストが不足）

## Overview
We need user authentication.

## Acceptance Criteria
- [ ] Users can register
- [ ] Users can log in

不足しているもの：なぜか？どのような問題か？リスクは？代替案は？テスト戦略は？

良い例（RFC レビューに対応）

## Problem Statement
Users can't persist data across sessions. 47% drop off when asked to re-enter
information. ~$50k/month in lost conversions.

## Durable Architectural Decisions
- **Routes:** POST /api/auth/register, POST /api/auth/login
- **Schema:** users table with email (unique), password_hash, created_at
- **Auth:** JWT with 24h expiry, refresh token with 7d expiry

## Modules
- **AuthService:** Owns registration, login, token lifecycle. Callers pass
  credentials, receive tokens. Hides hashing, token signing, refresh logic.

## Testing Strategy
- AuthService: integration tests against real DB (prior art: tests/int/)
- Token validation: unit tests for expiry, malformed tokens, refresh flows

## Boundary Tiers
### Never
- Payment module — unrelated, must not be affected
- User profile schema — separate concern, future PRD

PRD 作成後

共有する前に、次の点を確認します。

• 問題の説明が明確で、説得力がある
• スコープの境界（境界レベルと対象外の事項）が明示されている
• テスト戦略が特定したモジュールを網羅している
• 古くなるファイルパスやコードスニペットが含まれていない
• 長期にわたって有効なアーキテクチャ上の決定と実装の詳細が分けられている

ユーザーに「PRD を prd-<name>.md に保存しました」と伝えます。