讓 /sdlc-plan 以引導式訪談補全可驗收需求 #85

New Issue

2026-09-22T09:56:57Z

jiantw83 commented

2026-09-22 09:56:57 +00:00

總覽

讓 /sdlc-plan 從只檢查段落是否有內容，改為以引導式訪談協助產品／業務使用者補全可理解、可驗收的需求，再建立需求議題。

背景

目前規劃流程雖然會檢查總覽、背景、目標、非目標、領域名詞表、文件、驗收標準、影響範圍與未決事項是否有內容，但有內容不代表需求已經足夠清楚。使用者可能只填入解法、缺少真正要解決的問題，或沒有說明角色、情境、行為與可觀察結果，後續仍需反覆補問。

本次改善的主要使用者是提出需求的產品／業務使用者；coding agent 擔任需求訪談引導者與整理者。

目標

讓 /sdlc-plan 判斷段落內容是否具備實質需求資訊，而不只判斷是否非空。
每次只問一個最高價值的缺口，說明目前理解、缺少內容與提問原因。
提供建議選項或回答範例，同時允許使用者自由改寫答案。
引導每個需求具體描述角色、情境、行為與可觀察結果。
至少確認主要成功情境；適用時確認失敗或邊界情境。
對確實不適用的內容，要求使用者明確確認「不適用」並說明原因。
所有缺口補完前不得建立需求議題；「尚未決定」不得直接當成完成。
將上述規則集中在 /sdlc-plan 與必要的需求補全 reference，不改變現有需求議題模板、抽取契約或 /sdlc-analyze 契約。

非目標

不修改 templates/requirement-issue.md 的段落結構。
不修改 scripts/issue-extract.js 或其 JSON 輸出契約。
不改變 /sdlc-analyze 的架構、邏輯、資料與時程可行性分析責任。
不要求所有驗收標準一律使用 Given／When／Then 格式。
不在規劃階段替使用者決定架構、模組、資料表或其他實作方案。
不建立新的 Gitea 標籤、Milestone 或專案看板。

領域名詞表

名詞	定義
需求補全	透過逐題引導，將需求補到包含角色、情境、行為與可觀察結果的程度。
可驗收	不依賴實作細節即可由外部觀察或操作確認結果是否符合需求。
不適用	使用者明確確認某段內容不適用，並提供原因；不是尚未決定。
引導式訪談	agent 說明目前理解、缺口與提問原因，提供選項或範例，再等待使用者回答。

文件

待 /sdlc-analyze 產生。

流程圖

讀取輸入 → 檢查九段落的實質內容 → 找出下一個需求缺口 → 說明理解、缺口、原因與建議回答 → 一次詢問一題 → 更新工作稿 → 確認角色、情境、行為與可觀察結果 → 確認成功及適用的失敗／邊界情境 → 所有缺口補完 → 套用需求議題模板並建立。

驗收標準

/sdlc-plan 不把「段落非空」視為該段落已完成；能要求補充缺少的角色、情境、行為或可觀察結果。
每次只提出一個待回答問題，並同時呈現目前理解、缺少內容、提問原因，以及建議選項或範例。
使用者可以直接選擇建議答案，也可以自由改寫答案。
每個需求都能指出角色、情境、行為與可觀察結果。
主要成功情境已確認；需求適用時，失敗或邊界情境也已確認。
使用者回答「尚未決定」或未回答時，流程不建立需求議題。
使用者明確確認「不適用」並說明原因時，該項可視為已補全。
所有缺口補完後，仍產出現有需求議題模板所需的九個段落，不新增下游必須處理的欄位。
引導規則可放在 prompts/sdlc-plan.md 與必要的 references/requirements-discovery.md，不需修改模板、抽取腳本或 /sdlc-analyze。

影響範圍

prompts/sdlc-plan.md：新增需求內容品質判定、逐題引導與建立門檻。
references/requirements-discovery.md：集中記錄角色／情境／行為／結果、成功／失敗／邊界情境與提問格式規則。
templates/requirement-issue.md、scripts/issue-extract.js、prompts/sdlc-analyze.md：維持不變。

未決事項

無。

## 總覽讓 `/sdlc-plan` 從只檢查段落是否有內容，改為以引導式訪談協助產品／業務使用者補全可理解、可驗收的需求，再建立需求議題。 ## 背景目前規劃流程雖然會檢查總覽、背景、目標、非目標、領域名詞表、文件、驗收標準、影響範圍與未決事項是否有內容，但有內容不代表需求已經足夠清楚。使用者可能只填入解法、缺少真正要解決的問題，或沒有說明角色、情境、行為與可觀察結果，後續仍需反覆補問。本次改善的主要使用者是提出需求的產品／業務使用者；coding agent 擔任需求訪談引導者與整理者。 ## 目標 - 讓 `/sdlc-plan` 判斷段落內容是否具備實質需求資訊，而不只判斷是否非空。 - 每次只問一個最高價值的缺口，說明目前理解、缺少內容與提問原因。 - 提供建議選項或回答範例，同時允許使用者自由改寫答案。 - 引導每個需求具體描述角色、情境、行為與可觀察結果。 - 至少確認主要成功情境；適用時確認失敗或邊界情境。 - 對確實不適用的內容，要求使用者明確確認「不適用」並說明原因。 - 所有缺口補完前不得建立需求議題；「尚未決定」不得直接當成完成。 - 將上述規則集中在 `/sdlc-plan` 與必要的需求補全 reference，不改變現有需求議題模板、抽取契約或 `/sdlc-analyze` 契約。 ## 非目標 - 不修改 `templates/requirement-issue.md` 的段落結構。 - 不修改 `scripts/issue-extract.js` 或其 JSON 輸出契約。 - 不改變 `/sdlc-analyze` 的架構、邏輯、資料與時程可行性分析責任。 - 不要求所有驗收標準一律使用 Given／When／Then 格式。 - 不在規劃階段替使用者決定架構、模組、資料表或其他實作方案。 - 不建立新的 Gitea 標籤、Milestone 或專案看板。 ## 領域名詞表 | 名詞 | 定義 | | --- | --- | | 需求補全 | 透過逐題引導，將需求補到包含角色、情境、行為與可觀察結果的程度。 | | 可驗收 | 不依賴實作細節即可由外部觀察或操作確認結果是否符合需求。 | | 不適用 | 使用者明確確認某段內容不適用，並提供原因；不是尚未決定。 | | 引導式訪談 | agent 說明目前理解、缺口與提問原因，提供選項或範例，再等待使用者回答。 | ## 文件待 `/sdlc-analyze` 產生。 ## 流程圖讀取輸入 → 檢查九段落的實質內容 → 找出下一個需求缺口 → 說明理解、缺口、原因與建議回答 → 一次詢問一題 → 更新工作稿 → 確認角色、情境、行為與可觀察結果 → 確認成功及適用的失敗／邊界情境 → 所有缺口補完 → 套用需求議題模板並建立。 ## 驗收標準 - [ ] `/sdlc-plan` 不把「段落非空」視為該段落已完成；能要求補充缺少的角色、情境、行為或可觀察結果。 - [ ] 每次只提出一個待回答問題，並同時呈現目前理解、缺少內容、提問原因，以及建議選項或範例。 - [ ] 使用者可以直接選擇建議答案，也可以自由改寫答案。 - [ ] 每個需求都能指出角色、情境、行為與可觀察結果。 - [ ] 主要成功情境已確認；需求適用時，失敗或邊界情境也已確認。 - [ ] 使用者回答「尚未決定」或未回答時，流程不建立需求議題。 - [ ] 使用者明確確認「不適用」並說明原因時，該項可視為已補全。 - [ ] 所有缺口補完後，仍產出現有需求議題模板所需的九個段落，不新增下游必須處理的欄位。 - [ ] 引導規則可放在 `prompts/sdlc-plan.md` 與必要的 `references/requirements-discovery.md`，不需修改模板、抽取腳本或 `/sdlc-analyze`。 ## 影響範圍 - `prompts/sdlc-plan.md`：新增需求內容品質判定、逐題引導與建立門檻。 - `references/requirements-discovery.md`：集中記錄角色／情境／行為／結果、成功／失敗／邊界情境與提問格式規則。 - `templates/requirement-issue.md`、`scripts/issue-extract.js`、`prompts/sdlc-analyze.md`：維持不變。 ## 未決事項 - 無。

jiantw83 added the ready-for-agent label 2026-09-22 09:56:57 +00:00

jiantw83 referenced this issue

2026-09-23 00:54:40 +00:00

feat/guided-requirement-completion/main #87

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: plugins/tea-sdlc#85