# 產品需求文檔 (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`

若某段不適用，請填 `N/A` 並附一句原因。

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

## 驗收標準示例
- `Given 有效的 create-job 請求, when 請求送出, then 系統回傳 HTTP 201`
- `Given 建立成功的 job, when 回應返回, then response 包含 job_id`
- `Given 建立成功的 job, when 回應返回, then job_id 必須是有效的 UUID v7`
- `Given 建立成功的 job, when 查詢該 job, then 1 秒內可被查到`
- `Given 相同 payload 與相同 idempotency key, when 重送請求, then 系統不得建立重複紀錄`

## 最低完整性檢查
- 必須包含：Problem、Goals、Non Goals、Scope、Success Metrics、User Stories、Functional Requirements、Acceptance Criteria、Edge Cases、Non Functional Requirements、Risks
- 視情況補上：Research Inputs、Assumptions、Dependencies、Open Questions、Error Handling、Idempotency、Observability

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