/sdlc:retro — 流程檢討

角色是流程顧問：目標不是檢討程式碼品質，是找出「人與 AI 協作的流程」 哪裡卡住。先跑 /sdlc:sprint-review 確認事實，再跑這個——順序不可反。

第一步：重建時間軸

1. 最初的目標是什麼？中途有沒有漂移或擴張？
2. 實際完成了什麼？哪些原本想做但沒做完？
3. 階段劃分（釐清需求 → 探索 → 實作 → 除錯 → 收尾），各花了多少來回。

第二步：找摩擦點

只列實際發生的問題，不要為了填滿清單而硬湊。

• 溝通摩擦：哪些指令一開始理解錯，是描述不清還是缺背景？
• 上下文摩擦：哪些資訊被反覆詢問或反覆讀取？該進 CLAUDE.md 嗎？
• 流程摩擦：有沒有大量返工？有沒有重複性手動步驟可以變成 script／CI／hook？ 有沒有適合平行、這次卻串行的工作？
• 驗證摩擦：怎麼確認產出正確的？有沒有錯誤拖到很後面才發現？
• 更正統計：這個 sprint 發了幾則更正 comment？原因類型是什麼 （盤點數字錯／前提沒查證／只查了一個環境／相依講反）？ 更正文化是好的下游，更正率高代表上游查證不夠。

第三步：輸出

✅ 做得好的（保持）

最多 3 點。

🔴 卡住的地方（依浪費的來回次數排序）

每點：發生了什麼、根本原因、大約浪費幾個來回。

🎯 改善行動（最多 3 項）

優先順序：

1. 當場改進流程／CI（最好——踩雷當天修進機制）
2. 開票（次選——必須註明為什麼進不了機制，並在下輪 sprint-review 驗收）
3. 寫進文件（最後手段——視同沒有對策，只有在真的無法機械化時才接受）

新的檢查器要配「反假綠燈」自我測試：把真實缺陷種回去，斷言檢查必須失敗。 一道永遠會過的檢查比沒有檢查更糟。 </hard-rule>

不要超過 3 項——寧可少而精。某項改善的成本高於它省下的時間就直說不值得做。

順帶：死規則清理

有沒有規則從立了以來一次都沒觸發過、或文件與行為已經不一致？ 刪掉或修正，不要留著當裝飾——文件與行為不一致的規則會教人忽視其他規則。

收尾

補寫進 docs/sprints/ 同一份紀錄檔。有建議改 CLAUDE.md 或新增機制的， 問使用者要不要直接建立。