SKILL.md
readonlyread-only
name
gen-specs-as-issues
description
此工作流程引導您透過系統化的方法來識別缺失功能、排定優先順序，並建立詳細的實作規格。
產品經理助手：功能識別與規格制定
此工作流程引導您透過系統化的方法來識別缺失功能、排定優先順序，並建立詳細的實作規格。
1. 專案理解階段
- 檢視專案結構以了解其組織方式
- 閱讀 README.md 及其他文件檔案，了解專案的核心功能
- 透過以下方式識別現有實作狀態：
- 主要進入點（CLI、API、UI 等）
- 核心模組及其功能
- 測試以了解預期行為
- 任何佔位實作
引導問題：
- 此專案的主要目的是什麼？
- 它解決了哪些使用者問題？
- 現有實作中存在哪些模式？
- 哪些功能在文件中被提及但未完整實作？
2. 差距分析階段
- 僅將文件中的功能描述與實際實作進行比較
- 識別缺乏真實功能的「佔位」程式碼
- 尋找文件中提及但缺少完整實作的功能
- 考慮使用者旅程，找出中斷或缺失的步驟
- 優先關注核心功能（而非錦上添花的功能）
產出建立：
- 建立潛在缺失功能清單（5-7 項）
- 針對每個功能，記錄：
- 目前實作狀態
- 文件中的參考資料
- 若缺失對使用者體驗的影響
3. 優先順序排定階段
- 為每個識別出的差距評分：
評分矩陣（1-5 分制）：
- 使用者影響：有多少使用者受益？
- 策略契合度：符合核心使命？
- 實作可行性：技術複雜度？
- 資源需求：所需開發工作量？
- 風險等級：潛在負面影響？
優先順序 = (使用者影響 × 策略契合度) / (實作工作量 × 風險等級)
產出建立：
- 根據評分，呈現優先順序最高的前 3 項缺失功能
- 針對每項功能，提供：
- 功能名稱
- 目前狀態
- 若未實作的影響
- 與其他功能的相依性
4. 規格制定階段
- 針對每個優先功能，制定詳細但實用的規格：
- 從哲學方法開始：簡單勝於複雜
- 先專注於 MVP 功能
- 考慮開發者體驗
- 保持規格易於實作
每個功能規格：
-
概述與範圍
- 解決什麼問題？
- 包含哪些內容，明確排除哪些內容？
-
技術需求
- 所需核心功能
- 使用者面對的介面（API、UI、CLI 等）
- 與現有程式碼的整合點
-
實作計畫
- 需建立或修改的關鍵模組/檔案
- 展示方法的簡單程式碼範例
- 清晰的資料結構與介面
-
驗收標準
- 如何知道已完成？
- 哪些特定功能必須運作？
- 哪些測試應通過？
5. GitHub Issue 建立階段
- 針對每個規格，建立一個 GitHub issue：
- 清晰、具描述性的標題
- 內文中包含完整的規格
- 適當的標籤（enhancement、high-priority 等）
- 在相關處明確提及 MVP 哲學
Issue 範本結構：
[功能名稱]
概述
[功能的簡短描述及其目的]
範圍
[包含哪些內容，明確排除哪些內容]
技術需求
[具體的技術需求與限制]
實作計畫
[逐步方法，附簡單程式碼範例]
驗收標準
[視為功能完成的明確需求清單]
優先順序
[優先順序排定的理由]
相依性
- 阻擋： [被此 issue 阻擋的 issue 清單]
- 被阻擋： [此 issue 依賴的 issue 清單]
實作規模
- 預估工作量： [小/中/大]
- 子 issue： [若此為父 issue，則為子 issue 的連結]
5.5 工作分配最佳化
-
獨立性分析
- 檢視每個規格，識別真正獨立的元件
- 重構規格以最大化獨立工作流
- 在相互依賴的元件之間建立明確界限
-
相依性對應
- 對於無法避免相依性的功能，建立明確的 issue 階層
- 為整體功能建立父 issue，並為元件建立子 issue
- 明確記錄「被阻擋」與「阻擋」的關係
-
工作量平衡
- 將大型規格拆解為較小、可管理的子 issue
- 確保每個子 issue 代表 1-3 天的開發工作量
- 包含子 issue 特定的驗收標準
實作指南：
- 使用 GitHub issue 連結語法建立明確關係
- 新增標籤以指示相依性狀態（例如「blocked」、「prerequisite」）
- 為每個 issue 包含預估複雜度/工作量，以協助衝刺規劃
6. 最終審查階段
- 總結所有建立的規格
- 強調功能之間的實作相依性
- 建議邏輯上的實作順序
- 記錄任何潛在的挑戰或考量
在整個過程中請記住：
- 簡單勝於複雜
- 從可運作的最小可行實作開始
- 專注於開發者體驗
- 建立可日後擴展的基礎
- 考慮開源社群與貢獻模式
此工作流程體現了我們的方法，有助於維持功能規格與優先順序排定的一致性，確保軟體專案以深思熟慮、以使用者為中心的方式演進。
