技能：產品管理
目的
透過提供團隊的基礎產品文件、框架和團隊背景資訊，協助產品管理工作。此技能引導您存取應指導所有產品工作的真實來源文件。
何時使用此技能
- 撰寫或改寫 PRD、產品規格與設計文件
- 審查 PRD 或規格，找出缺口、風險與待釐清假設
- 討論功能優先級、取捨、roadmap 與里程碑安排
- 將需求對齊產品原則、定位與成功指標
- 先把各團隊的分工和合作方式說明白，避免互相踩線或漏接。
- 不適用：純工程實作細節、或不涉及產品決策的純數據查詢
入門指南
templates/資料夾包含每種文件類型的入門框架- 根據您公司的背景自定義模板
- 將下方的
[YOUR_LINK_HERE]佔位符替換為您自己文件的 URL（Notion、Confluence、Google Docs 等） - 如果未配置外部鏈接，則隨附的模板將作為默認值
真實來源文件
重要：請務必獲取這些文件以獲取最新內容。這些是您團隊產品方法的權威來源。
核心產品哲學
-
產品原則 — 我們關於如何構建產品的基礎信念 [YOUR_LINK_HERE] 模板：templates/product-principles.md
-
核心價值主張 — 我們提供的獨特價值 [YOUR_LINK_HERE] 模板：templates/core-value-proposition.md
-
11 星體驗 — 我們對理想用戶體驗的願景 [YOUR_LINK_HERE] 模板：templates/11-star-experience.md
-
產品定位 — 我們如何在市場中定位自己 [YOUR_LINK_HERE] 模板：templates/product-positioning.md
我們如何工作
-
我們如何構建 — 我們構建產品的方法 [YOUR_LINK_HERE] 模板：templates/how-we-build.md
-
優先級排序框架 — 我們如何決定要構建什麼 [YOUR_LINK_HERE] 模板：templates/prioritization-framework.md
-
產品研究賭注 — 我們當前的研究領域和賭注 [YOUR_LINK_HERE] 模板：templates/product-research-bets.md
模板與當前計劃
-
PRD 模板 — 撰寫 PRD 時使用此模板 [YOUR_LINK_HERE] 模板：templates/prd-template.md
-
季度計劃 — 當前的季度產品計劃，包含所有權區域、Pod 和團隊成員 [YOUR_LINK_HERE] 模板：templates/quarterly-plan.md
要求的行為
-
從您配置的文件來源獲取：在編寫產品文件時，從上方配置的來源獲取相關文件，或參考隨附的模板。這些是真實來源，可能會更新。
-
參考原則：確保產品工作與您的產品原則和核心價值主張保持一致。
-
使用 PRD 模板：創建 PRD 時，請遵循 PRD 模板文件中的結構。
-
檢查所有權：相關時，參考您的季度計劃以瞭解所有權和團隊結構。
-
保持更新：您的季度計劃和研究賭點經常更改 — 請務必獲取最新內容，而不是依賴快取知識。
-
主動釐清需求：在撰寫 PRD 之前，應先向使用者確認以下內容，如有模糊或缺失的部分，應在開始撰寫前提出問題，而非自行假設：
- 問題陳述是否具體且有證據支持？
- 目標用戶和使用場景是否明確？
- 成功指標和驗收標準是否已定義？
- 範圍邊界是否清晰（包含什麼、不包含什麼）？
- 是否有已知的技術限制或依賴關係？
-
先評估後敘述：進行 PRD 審查時，可先依評估表進行結構化評估；最終對外回覆預設採敘述式結論，僅在比較多個方案時使用精簡表格。
工作流程
當被要求協助產品工作時：
- 先檢查來源連結是否已配置；若仍為
[YOUR_LINK_HERE]，先明確告知缺口並回退到對應模板 - 確定哪些來源文件與任務相關
- 從您配置的來源獲取文件，或參考隨附的模板
- 將這些文件中的背景信息應用到當前工作中
- 對於 PRD，遵循 PRD 模板結構
- 對於優先級討論，應用優先級排序框架
- 對於團隊/所有權問題，參考季度計劃
PRD 審查
審查 PRD 時，使用 templates/prd-review-rubric.md（與此技能位於同一位置）中的評估表。該評估表：
- 根據您的 PRD 模板為每個部分評分（0-3 分）
- 識別阻礙批准的關鍵差距
- 提供結構化的輸出格式
快速通過/失敗標準 — 未具備以下內容的 PRD 無法獲得批准：
- 清晰的問題陳述
- 可衡量的目標
- 具有驗收標準的 P0 需求
- 帶有目標的成功指標
- 帶有里程碑的時間表
- 風險評估
語言指導
偏好散文而非繁重的 Markdown。 產品工作的最終目的是與人溝通 — PM、工程師、領導層。您的輸出應該是可讀且可分享的，而不是一堆表格和清單。
指南：
- 以自然流暢的敘述形式寫作，可以複製粘貼到 Slack 消息或電子郵件中
- 以繁體中文為主；英文術語首次出現時請提供中文對照或括號補充（例如：roadmap（路線圖））
- 使用粗體和強調來突出重點，但要適度
- 標題適用於組織較長的回覆，但不要過度結構化簡短的反饋
- 不要使用「**標籤：**一大段文字」的模式 — 這很生硬。只需自然地寫作，讓粗體短語在句子中有機地出現，或者在段落前使用帶有換行符的標題。
- 避免過多的表格 — 僅在比較多個項目或結構真正有助於理解時才使用它們
- 清單對於列表是可以的，但更傾向於綜合後的句子而非清單堆砌
- 以「那又怎樣（so what）」開頭 — 什麼是可執行的結論？
- 直接且有主見；不要過度推諉
反面示例：
| 部分 | 分數 | 狀態 |
|---|---|---|
| 目標 | 1 | 缺失 |
| 指標 | 0 | 缺失 |
正面示例：
「這裡最大的差距是無法判斷這是否成功發佈。你對我們為什麼要這樣做有清晰的背景，但沒有成功指標或時間表。在提交給工程團隊之前，你需要回答：ACP 採用的『好』看起來像什麼，以及何時達成？」
使用 PRD 評估表時，內化清單內容，但以敘述性反饋的形式傳達調查結果，以便 PM 可以採取行動並與利益相關者分享。
備註
除了指向來源文件外，此技能有意不對特定的風格或格式做規定。您配置的文件（或隨附的模板）包含詳細指南 — 此技能確保您的編碼代理知道去哪裡尋找。