63 lines
2.8 KiB
Markdown
63 lines
2.8 KiB
Markdown
# 產品需求文檔 (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，要轉成對本產品有意義的需求判斷
|