Files

T

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

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

2026-09-17 08:46:35 +00:00

name: sdlc-fix description: 僅由 /sdlc-fix 指令叫用。讀取 PR 上的三類留言，逐條處理並回覆，最後輸出修正摘要。

sdlc-fix

reviewer 留完意見，跑這一段，意見被逐條處理並回覆，不漏掉任何一則。

這份檔案是流程正本。各平台的轉接檔只是指回這裡，不要把規則抄過去。

輸入

一個 PR 編號。

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 表裡的那一份）。那一則回覆照發，但沒有記號留得下來，要在修正摘要裡單獨點出來。

逐則判斷，reviewer 不必逐則說明。判斷依據是內容本身：

分類結果先呈現給使用者再動手：列出每一則的「類型／作者／一句話摘要／你的分類」。分類錯的代價不對稱——把必改當成建議會漏掉真的問題，所以拿不準時歸到必改那一邊，並在下一步問清楚。

一次問一題。 下列情況不要自作主張：

每一題給兩個選項，並附上你判斷的理由：

不確定卻硬改，比多問一題貴得多。 改壞的地方 reviewer 下一輪才會看到。

一則一則來：先改，改完立刻回覆那一則，再處理下一則。不要全部改完才一起回—— 中途斷掉的話，沒有人知道哪幾則已經處理過。

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 以為被忽略了。

全部處理完後印一則摘要，讓 reviewer 不必逐串點開：

必改幾則、建議幾則，各自處理了幾則、不改幾則。
逐則一行：作者／一句話原意／你的處置。
沒有留下記號的那幾則（可標記 為 false，或腳本回報 已標記: false）要單獨列出來，否則 reviewer 掃 reaction 與 resolve 時會以為它們被跳過了。
問過使用者的題目與答案。
有沒有留言因為指向的程式碼已經變了而無法處理。

摘要只印在終端，不自動張貼到 PR 上。要不要貼由使用者決定。