# 產品需求文檔 (Write-a-PRD) 技能指南

## 概述
`write-a-prd` 是一個純 PM 技能，用來把已釐清的產品方向整理成結構化 PRD。它負責定義問題、目標、範圍、成功指標、功能性需求、非功能需求、驗收標準與風險，不負責技術設計。

## 運作流程
1. **需求釐清**：確認目標使用者、現況流程、痛點、限制與發佈邊界。
2. **收斂產品定義**：根據使用者情境整理目標、非目標、範圍、成功指標與需求。
3. **吸收研究輸入**：若存在 `docs/research/...`，將市調、競品與類別期待轉化為 PRD 依據。
4. **正式撰寫**：輸出標準化 PRD 至 `docs/prd/...`。
5. **可選同步**：只有在使用者明確要求時，才另外同步成 GitHub Issue。

## 輸入與輸出
### 輸入
- 主要輸入：`docs/brainstorm/{date}-{feature}-design.md`
- 可選輸入：`docs/research/{date}-{topic}.md`

### 輸出
- 主要輸出：`docs/prd/{date}-{feature}.md`
- 次要輸出：GitHub Issue（僅限使用者明確要求時）

## PRD 結構
- `## Research Inputs`（有需要才填）
- `## Problem`
- `## Goals`
- `## Non Goals`
- `## Scope`
- `## Success Metrics`
- `## User Stories`
- `## Functional Requirements`
- `## Acceptance Criteria`
- `## Edge Cases`
- `## Non Functional Requirements`
- `## Risks`
- `## Assumptions`
- `## Dependencies`
- `## Open Questions`

## 規則
- 驗收標準必須使用 `Given / When / Then`
- 功能性需求與非功能需求必須依使用者情境定義
- 只寫使用者可觀察或可依賴的行為
- 不得寫 architecture、module、schema、database、API path、技術選型、工程拆工

## 注意事項
- `docs/prd/...` 是 agent 間交接的主要橋樑
- 不要把競品解法直接抄進 PRD，要轉成對本產品有意義的需求判斷