feat(sdlc-fix): 新增 sdlc-fix 流程正本

分類必改／建議、不確定時停下來問、最後那則摘要——這三件腳本擋不住，只有正本做得到。

標不了的那幾則要在摘要裡單獨點出來，否則 reviewer 掃 reaction 與 resolve 時會以為它們
被跳過了。留言指向的程式碼已被改掉時不要硬試，列進「無法處理」讓使用者自己回。

prompts/sdlc-fix.md

@@ -0,0 +1,104 @@
+name: sdlc-fix
+description: 僅由 /sdlc-fix 指令叫用。讀取 PR 上的三類留言，逐條處理並回覆，最後輸出修正摘要。
+
+# sdlc-fix
+
+reviewer 留完意見，跑這一段，意見被逐條處理並回覆，不漏掉任何一則。
+
+這份檔案是流程正本。各平台的轉接檔只是指回這裡，不要把規則抄過去。
+
+## 輸入
+
+一個 PR 編號。
+
+## 1. 讀留言
+
+```
+node scripts/pr-comments.js --repo <owner/name> --index <PR 編號>
+```
+
+三類留言一次讀齊：**一般留言**、**review 總評**、**行內留言**。每一則都帶 `id`、`作者`、
+`內容`、`已處理`，行內的還帶 `檔案`／`行`／`diff`——那段 diff 是判斷「他在說哪裡」的依據，
+不要略過不看。
+
+**先看 `未處理數`。** 它是這一輪要處理的量；`已處理` 為 `true` 的那些是前一輪做過的，
+跳過不再處理。
+
+**三類都標記得了，機制不同**：一般留言與 review 總評用 `+1` reaction，行內留言用
+resolve。`已處理` 認的是**自己打的** `+1`——reviewer 對留言按讚是「我同意」，不是
+「這則處理過了」。
+
+偶爾會遇到 `可標記` 是 `false` 的總評（在 timeline 上對不到它在 issue comment 表裡的
+那一份）。那一則回覆照發，但沒有記號留得下來，**要在修正摘要裡單獨點出來**。
+
+## 2. 分類：必改還是建議
+
+逐則判斷，**reviewer 不必逐則說明**。判斷依據是內容本身：
+
+- **必改** — 指出了錯誤、遺漏、會出事的寫法，或明確要求改動。
+- **建議** — 提出另一種做法、風格偏好、「之後可以考慮」。
+
+分類結果**先呈現給使用者**再動手：列出每一則的「類型／作者／一句話摘要／你的分類」。
+分類錯的代價不對稱——把必改當成建議會漏掉真的問題，所以拿不準時歸到必改那一邊，
+並在下一步問清楚。
+
+## 3. 不確定就問
+
+**一次問一題。** 下列情況不要自作主張：
+
+- 分不出必改還是建議。
+- 知道要改，但有兩種以上做法，而選擇會影響別處。
+- 留言本身看不懂，或它指的位置與現在的程式碼對不上（PR 之後又推了新 commit 是常見原因）。
+
+每一題給兩個選項，並附上你判斷的理由：
+
+- **建議** — 你的答案，寫「為什麼是這個」。
+- **手動輸入** — 讓使用者自己說。
+
+**不確定卻硬改，比多問一題貴得多。** 改壞的地方 reviewer 下一輪才會看到。
+
+## 4. 逐則處理並回覆
+
+一則一則來：先改，改完立刻回覆那一則，再處理下一則。**不要全部改完才一起回**——
+中途斷掉的話，沒有人知道哪幾則已經處理過。
+
+```
+node scripts/pr-reply.js --repo <owner/name> --index <PR 編號> \
+  --comment <留言 id> --kind inline|general|review --body '<回覆>' --dry-run
+```
+
+`--kind` 對應 `pr-comments` 給的 `類型`：`行內` → `inline`、`一般` → `general`、
+`總評` → `review`。**三類留言的 id 各自獨立**，`--kind` 給錯會找不到那一則。
+
+腳本自己會去查行內留言的位置（含它在新檔還是被刪掉的那一側）與它所屬的 commit，
+把回覆放回同一串；也會在回覆成功之後才標記（行內用 resolve，一般與總評用 `+1`）。
+回覆失敗就不標記——沒回卻標記等於謊稱處理過。
+
+**留言指向的程式碼已經被改掉時**，回覆可能會被 Gitea 拒絕（位置對不上）。那時不要硬試，
+把那一則列進摘要的「無法處理」，讓使用者自己去 PR 上回。
+
+**回覆要說出做了什麼**，不是「已修正」。reviewer 看回覆就要知道改法對不對，
+不必自己去翻 diff。決定不改的也要回，並說明理由——建議類的留言常常合理地不採納，
+但沉默會讓 reviewer 以為被忽略了。
+
+## 5. 修正摘要
+
+全部處理完後印一則摘要，讓 reviewer 不必逐串點開：
+
+- **必改幾則、建議幾則**，各自處理了幾則、不改幾則。
+- **逐則一行**：作者／一句話原意／你的處置。
+- **沒有留下記號的那幾則**（`可標記` 為 `false`，或腳本回報 `已標記: false`）要單獨
+  列出來，否則 reviewer 掃 reaction 與 resolve 時會以為它們被跳過了。
+- **問過使用者的題目與答案**。
+- 有沒有留言因為指向的程式碼已經變了而無法處理。
+
+摘要只印在終端，**不自動張貼到 PR 上**。要不要貼由使用者決定。
+
+## 邊界
+
+- 不改與留言無關的程式碼。順手看到的問題記下來說出來，不要摸進這一輪。
+- 不自行判斷不確定的事——寧可多問一題。
+- 不跳過任何一則留言。決定不改的也要回覆並說明理由。
+- 不在回覆沒成功時標記已處理。
+- **不自動張貼修正摘要**，也不自動關閉或合併 PR。
+- 不動 PR 的 review 狀態：回覆一則意見不該順手把整個 PR 標成通過或要求變更。