prompts/sdlc-analyze.md

@@ -0,0 +1,74 @@
+name: sdlc-analyze
+description: 僅由 /sdlc-analyze 指令叫用。對一顆需求議題執行可行性檢查，把疑點逐題問到共識並輸出摘要。
+
+# sdlc-analyze
+
+對一顆需求議題執行可行性檢查，把疑點一題一題問到雙方有共識。
+
+這一段到共識摘要為止，**不寫入 Gitea**。把工作包開出去是下一段的事。
+
+這份檔案是流程正本。各平台的轉接檔只是指回這裡，不要把規則抄過去。
+
+## 輸入
+
+一個需求議題編號。
+
+## 步驟
+
+### 1. 讀議題
+
+```
+node scripts/issue-extract.js --repo <owner/name> --index <編號>
+```
+
+拿到的是結構化欄位，不必再讀整份議題全文。
+
+**先看 `未處理留言數`。** 只要不是 0，就代表議題描述可能是過期的——留言裡有決策還沒被
+整併回描述。這時**先停下來**告訴使用者有幾則未整併的留言，建議先執行 `/sdlc-sync`
+把它們整併回描述，再回來做分析。使用者堅持要繼續就繼續，但要記下這件事，
+並在共識摘要裡註明「分析基於未整併留言前的描述」。
+
+### 2. 對四份清單列出疑點
+
+依序讀這四份規則正本，逐條對照議題內容：
+
+1. `references/feasibility-architecture.md` — 架構：放錯 repo、循環相依、穿越邊界。
+2. `references/feasibility-logic.md` — 邏輯：既有功能是不是已經做過同一件事。
+3. `references/feasibility-data.md` — 資料：schema 變更、遷移、交易邊界。
+4. `references/feasibility-schedule.md` — 時程：相依鏈最長路徑、未知數最大的一項。
+
+每一條檢查若在議題裡找不到答案，就轉成一個問題。**能在程式碼裡查證的就自己去查，
+不要拿去問使用者**——把問題留給只有人能回答的事。
+
+### 3. 逐題問到共識
+
+**一次問一題。** 問完等使用者回答，再問下一題，讓他能看著前一題的答案回答下一題。
+不要一次丟出五個問題，也不要把多個問題包成一題的多個選項。
+
+順序固定為**架構 → 邏輯 → 資料 → 時程**，前一類的問題全部清空才進入下一類。
+前面的答案常常會讓後面的問題消失或改寫；每問完一題，重新檢視剩下的問題還成不成立。
+
+每一題固定給兩個選項：
+
+- **建議** — 你的答案，附上理由。理由要寫「為什麼是這個」，不是複述問題。
+- **手動輸入** — 讓使用者自己寫。任何一題都必須能手動作答，不被選項限制。
+
+問題本身要具體到能用一句話回答。問不出收斂答案的問題，多半是問題本身太大，拆開再問。
+
+### 4. 輸出共識摘要
+
+全部問完後，輸出一份摘要讓使用者做最後確認，內容包含：
+
+- **每一類的結論** — 架構／邏輯／資料／時程各自問出了什麼，逐條列出「問題 → 答案」。
+- **改變了什麼** — 分析過程中翻掉或修正了需求議題裡的哪些假設。
+- **仍然未決的事** — 問了但沒有答案、或使用者明確說「之後再說」的事。
+- **人天估算** — 每一項的估算與最沒把握的那一項。
+
+摘要只印在終端，**不寫回議題、不建立任何東西**。使用者看過點頭之後，才進入下一段。
+
+## 邊界
+
+- 不對 Gitea 產生任何寫入：不建議題、不改描述、不貼標籤、不留留言。
+- 不修改使用者的專案檔案。查證既有功能時只讀不寫。
+- 不替使用者決定他沒回答的事。問不到答案就進「仍然未決的事」。
+- 不自行建立標籤、Milestone 或專案看板。