102 lines
4.1 KiB
Markdown
102 lines
4.1 KiB
Markdown
---
|
||
name: report-writer
|
||
description: 報告格式化與存檔技能。定義各類研究報告的 Markdown 模板、存檔路徑規範、版本控制策略。
|
||
---
|
||
|
||
# 報告撰寫技能 (Report Writer Skill)
|
||
|
||
統一所有產品經理 (PM) 產出的報告格式，確保內容的一致性、可追溯性，並規範標準的存檔路徑。
|
||
|
||
## 存檔路徑規範
|
||
|
||
所有報告應存入 `docs/prd/drafts/[產品名稱]-[YYYY-MM-DD]/` 目錄中：
|
||
|
||
| 報告類型 | 標準檔名 |
|
||
|---------|------|
|
||
| 市場研究報告 | `01-market-research.md` |
|
||
| 競品分析報告 | `02-competitor-analysis.md` |
|
||
| 用戶洞察報告 | `03-user-insights.md` |
|
||
| 旅程與策略報告 | `04-journey-strategy.md` |
|
||
| 優先級與 Roadmap | `05-prioritization.md` |
|
||
| 最終 PRD 文件 | `../[產品名稱]-prd-[YYYY-MM-DD].md` |
|
||
|
||
## 報告通用格式
|
||
|
||
每份報告必須嚴格包含以下標頭結構：
|
||
|
||
```markdown
|
||
# [報告標題名稱]
|
||
|
||
| 資訊欄位 | 具體內容 |
|
||
|------|------|
|
||
| 產出日期 | [YYYY-MM-DD] |
|
||
| 產出 Agent | [Agent 識別名稱] |
|
||
| 主要資料來源 | [主要搜尋關鍵字或爬取來源概括] |
|
||
|
||
---
|
||
|
||
[報告正文內容]
|
||
|
||
---
|
||
|
||
## 參考資料清單
|
||
- [資料來源 1]：[完整 URL 連結]
|
||
- [資料來源 2]：[完整 URL 連結]
|
||
```
|
||
|
||
## 版本控制策略
|
||
|
||
- **初版**：以原檔名儲存。
|
||
- **修改版**：存為 `[原檔名]-v2.md`（後續版本如 v3、v4 依此類推）。
|
||
- **記錄變更**：每次修改必須在文件末尾的「版本變更記錄」中詳細載明。
|
||
|
||
```markdown
|
||
## 版本變更記錄
|
||
| 版本號 | 日期 | 變更內容說明 | 觸發之指令/操作 |
|
||
|------|------|---------|---------|
|
||
| v1.0 | [日期] | 初始版本產出 | /pm |
|
||
| v1.1 | [日期] | [具體修改之處說明] | /pm-edit |
|
||
```
|
||
|
||
## 執行完成後的回報格式
|
||
|
||
每當完成檔案儲存後，Agent 必須依照下述格式回報：
|
||
|
||
```
|
||
✅ [報告類型] 已成功存檔至 [完整絕對路徑]
|
||
```
|
||
|
||
## PRD 模板摘要與格式強制規範
|
||
|
||
最終產出的 PRD 文件除了基礎業務邏輯外，必須強制包含以下結構（詳情請參閱 `pm-writer` agent）：
|
||
|
||
1. **TL;DR (重點摘要)**
|
||
2. **背景與目標原因 (Why)**
|
||
3. **具體目標與核心成功指標 (KPIs)**
|
||
4. **目標用戶畫像與使用情境 (User Personas & Scenarios)**
|
||
5. **功能性需求 (Functional Requirements)**
|
||
- 必須採用 **模組 (Module)** 與 **子模組 (Sub-module)** 分層撰寫 (例如 `## 帳號體系` -> `### 使用者註冊`)。
|
||
- **針對每個獨立功能點，必須包含以下 4 個標準化區塊：**
|
||
1. **流程與交互圖**：使用 `mermaid` 語法繪製流程圖 (Flowchart)、時序圖 (Sequence Diagram) 或狀態機圖。
|
||
2. **邊界條件與異常處理 (Edge Cases)**：使用表格詳列「觸發情況/錯誤錯誤」、「觸發條件」與「處理邏輯與系統回應」。
|
||
3. **業務邏輯描述**：使用條列式 (Bullet points) 清楚、無歧義地說明功能規則。
|
||
4. **介面資料欄位 (Data Fields)**：使用表格定義欄位，包含 `欄位名稱(繁中)`、`Name(英文)`、`資料型態`、`功能說明`。
|
||
5. *(建議)* EARS 驗收標準
|
||
6. **通知系統規則 (Notifications)**：統一收斂所有觸發的 SMS/Mail/Push 規則，以表格呈現 (含觸發條件、發送通道、接收對象)。
|
||
7. **非功能性需求 (Non-functional Requirements)**：必須定義：安全性規範、支援地區、標準時區 (如 UTC+8)、多語系支援 (附上 ISO 639-1 代碼)、效能指標與併發處理要求。
|
||
8. **使用者旅程圖 (User Journey)**
|
||
9. **產品路線圖 (Roadmap)**
|
||
10. **資源需求估算 (Resource Estimation)**
|
||
11. **風險評估與假設前提 (Risks & Assumptions)**
|
||
12. **附錄**（含資料來源清單 + 版本變更記錄）
|
||
|
||
## 報告品質底線需求
|
||
|
||
| 檢查項目 | 最低合格標準 |
|
||
|------|---------|
|
||
| **Must Have 功能點** | 至少包含 8 個以上 |
|
||
| **用戶具體痛點** | 至少列出 8 個具體且明確的痛點 |
|
||
| **競品分析數量** | 至少包含 3 個具備完整分析的競對產品 |
|
||
| **風險清單項目** | 至少包含 5 個（並區分 High/Medium/Low 等級） |
|
||
| **待釐清之開放問題** | 至少提出 3 個待討論問題 |
|