feat(需求補全): 改善規劃需求補全
引導使用者補齊角色、情境、行為與可觀察結果,並在完整性閘門通過前停止建立需求議題。
This commit is contained in:
+15
-5
@@ -7,23 +7,33 @@ description: 僅由 /sdlc-plan 指令叫用。把一段口語需求轉成結構
|
||||
|
||||
## 步驟
|
||||
|
||||
開始前讀取 `references/requirements-discovery.md`。它是需求內容品質與建立前完整性閘門的規則正本;本流程只補充操作順序與 Gitea 交付步驟。
|
||||
|
||||
### 1. 列出九段落依據與缺漏〔可委派〕
|
||||
|
||||
讀齊輸入,列出總覽、背景、目標、非目標、領域名詞表、文件、驗收標準、影響範圍與未決事項中已有依據與缺漏。這一步只產出可核對的清單;你的環境若能把工作交給子代理,就交出去,只把清單帶回來;不能就自己做。
|
||||
讀齊輸入,列出總覽、背景、目標、非目標、領域名詞表、文件、驗收標準、影響範圍與未決事項中已有依據與缺漏。對每一段不只檢查是否非空,還要依需求補全規則檢查實質內容。這一步只產出可核對的清單;你的環境若能把工作交給子代理,就交出去,只把清單帶回來;不能就自己做。
|
||||
|
||||
### 2. 一次問一題補齊缺漏
|
||||
|
||||
一次問一題補齊缺漏;未獲回答的內容放入「未決事項」,不得自行編造。
|
||||
依需求補全規則挑出下一個最高價值的需求缺口。每次只問一題,並同時列出目前理解、缺少內容、為什麼需要,以及建議選項或短範例;明確允許使用者自由改寫答案。
|
||||
|
||||
### 3. 填入需求議題模板
|
||||
能從輸入、既有議題或可取得的 repo 內容查證的事項先自行查證;只有需要需求擁有者決策的事項才提問。不得把推測或實作方案寫成已確認需求。
|
||||
|
||||
每次收到回答後更新工作稿,重新檢查角色、情境、行為、可觀察結果,以及主要成功情境與適用的失敗/邊界情境。未回答、「不知道」或「尚未決定」仍是缺口,繼續一次問一題;只有使用者明確確認「不適用」並說明原因,才可標記該項完成。
|
||||
|
||||
### 3. 建立前完整性閘門
|
||||
|
||||
套用 `references/requirements-discovery.md` 的完整性閘門。九段落都必須有實質內容,或由使用者確認不適用並說明原因;不得留下未回答或「尚未決定」的缺口。未通過閘門前不得套用模板、查標籤或建立議題。
|
||||
|
||||
### 4. 填入需求議題模板
|
||||
|
||||
套用 `templates/requirement-issue.md`,填入總覽、背景、目標、非目標、領域名詞表、文件、驗收標準、影響範圍與未決事項;全程使用繁體中文。
|
||||
|
||||
### 4. 取得既有標籤
|
||||
### 5. 取得既有標籤
|
||||
|
||||
用 `scripts/labels-list.js` 取得既有標籤,只能選既有標籤。
|
||||
|
||||
### 5. 試跑並建立議題
|
||||
### 6. 試跑並建立議題
|
||||
|
||||
寫入前先執行:
|
||||
|
||||
|
||||
Reference in New Issue
Block a user