| name | sprint-self-review |
| description | 在 AI 時代誠實地自評「我這個 sprint 的交付成效」。不是產出量打分，而是用對 AI 免疫的流動/品質指標當溫度計、用判斷日誌當北極星。Use when the user says "sprint 自評", "我這 sprint 做得如何", "我的交付成效", "sprint self review", "個人交付量", or invokes /sprint-self-review. |
Sprint 自評（個人視角）
幫使用者誠實地檢視「我這個 sprint 做得好不好」。對象是使用者本人對自己的反省，不是給主管/投資人的報告，也不跟別人比較。
為什麼這個 skill 存在（讀 references/rationale.md 拿完整理由）
AI 讓「產出程式碼」成本趨近於零，所以行數、commit 數、甚至故事點數都變成虛榮指標。使用者剩下的價值集中在 判斷、整合、驗證。因此自評的核心問題不是「我產出多少」，而是：
這個 sprint，我把時間花在 AI 取代不了的事情上了嗎？我做的那些判斷後來被證明是對的嗎？
因為是「自己誠實量自己」，Goodhart（指標被當目標就被灌水）的風險消失，所以可以大膽用質性、主觀的訊號。
四條護欄（任何時候都不能違反）
- 永不把 LOC / commit 數當分數。 最多當背景脈絡，且必須標註「這是虛榮指標」。
- 數字只當「提問與旗標」，不當「評分」。 churn 高 → 引導使用者去判斷日誌回答為什麼，而不是說「你不及格」。
- 只跟過去的自己比，不跨人比較。 價值在趨勢，不在單次絕對值。
- 判斷日誌（L3）沒填，報告就不算完成。 它是本體，量化層只是護欄。
計算手段是 optional 的，臨場判斷
Python 腳本不是這個 skill 的必經步驟，只是眾多計算手段之一。原則：優先用最輕的手段拿到數字。
- 簡單的一週脈搏 → 直接敲
gh / git 指令 inline 解析就好，不要寫檔案。
- 麻煩或會重複的計算（churn 逐行追、4 週滾動趨勢、跨多 repo） → 才值得寫一支 Python 落地到
scripts/，順便下次重用。
- 數字用看的就有 → 根本不用算。一週可能就 2–3 個 PR，硬跑腳本是儀式感。
scripts/ 是「用進廢退的工具箱」，一開始是空的，撞到值得落地的計算才長出來。
環境前提（已知）
- Git host：GitHub，用
gh CLI（已登入，帳號 CodeMachine0121）。
- 工作流：從
Develop 切 feature branch → PR merge 回 Develop。「交付完成」這條線 = PR merge 進 Develop 且在觀察窗口內未被回滾/大改（＝「淨交付」，net delivery）。不是上 production（pre-PMF、production 沒人用，上線與否不該算進自評）。
- 借自 XP 的「淨交付」定義：一個故事只有通過審查、整合進主線、且觀察窗口內沒被回滾/緊急修補才算數。書的原版觀察窗口在 production；我們情境（production 沒人用）平移成「merge 進 Develop 後在觀察窗口內有沒有被回滾/大改」——這其實就是 churn，但要明確當成「淨交付」來講。觀察窗口建議用滾動 4 週（單週太短，回滾常發生在 merge 之後的下一兩週）。
- Sprint 長度：1 週。因為窗口短、單週數字很吵，一律同時呈現「本週」與「滾動 4 週趨勢」兩欄，本週看脈搏、4 週看趨勢。
- 預設單一 repo；多 repo 就讓使用者給 repo 清單。
- 認自己的 PR 用
--author "@me"。
三層指標
| 層 | 內容 | 怎麼來 |
|---|
| L1 脈搏（量化，當溫度計） | merge 進 Develop 的 PR 數、淨交付（扣掉觀察窗口內被回滾/大改的）、PR cycle time、review 來回次數、自己 code 的 churn | gh/git 算 |
| L2 時間流向（半自動） | 高判斷密度的事 vs. 純敲 code 的比例 | 拿 PR 清單請使用者快速分類 |
| L3 判斷日誌（純訪談，北極星） | AI 給不出的判斷、抓到/漏掉的 AI 錯誤、有沒有讓未來變快 | 逐題訪談 |
流程
Step 1 — 定範圍
確認 repo、sprint 窗口（預設最近 7 天，可手動指定起迄）、確認 author 是使用者本人。
Step 2 — 算 L1（手段臨場決定，見上）
撈本週 + 過去 4 週的：
- merge 進 Develop 的 PR：
gh pr list --author "@me" --base develop --state merged --limit 100 --json number,title,createdAt,mergedAt,additions,deletions,reviewDecision 再依 mergedAt 在窗口內過濾。
- 淨交付（net delivery）：merge 進 Develop 的 PR，扣掉在觀察窗口內被回滾（revert）或被大幅重寫的。訊號可來自：後續有
Revert "..." 的 commit/PR、或先前 merge 的檔案在窗口內又被自己/別人大改（與 churn 同源）。這是書裡「最該上儀表板的誠實數字」——把清理 AI 爛攤子的成本記回帳。
- Cycle time：每個 PR 的
mergedAt - createdAt，看中位數。
- Review 來回：對 PR 抓
--json reviews,commits，數 CHANGES_REQUESTED 次數，或首次 review 之後又推的 commit 數。
- Churn（近似 proxy，務必標註是近似值）：使用者這窗口內新增/改的行，在同窗口內又被改掉的比例。值得算才用
git log --author --since --numstat 或逐行 git blame 追；嫌麻煩就先略過並說明。
Step 3 — 呈現成溫度計 + 旗標
本週 vs 4 週兩欄。把異常的數字標出來，轉成一個該反省的問題指向 L3，不要下評語。例：「本週 review 來回比平均高 2 倍 → 是不是送了半成品 / 過度信任 AI 產出沒先自審？等下在判斷日誌談。」
Step 4 — 訪談 L2 + L3
- L2：拿 Step 2 的 PR 清單，請使用者把時間粗分成「高判斷密度（定義問題/架構/審查/整合/除錯/驗證）」vs「純敲 code」。重點是讓他看見自己的角色有沒有往 AI 時代正確遷移。
- 淨交付回顧（每輪必問，書的「讓校準變成例行公事」）：
- 上週宣稱 done 的東西，這週有幾個被回滾/動過？這輪的工作量裡，有多少其實是花在修上一輪的東西？
- AI 生成的部分，審查花了多久？
把答案記下來——連續幾輪會得到一條「比帳面難看、但唯一能用」的誠實曲線。注意：不要追求精確歸因（那本身是虛榮的精密），要的是「返工率在升還是降、審查負載在累積還是被消化」這種粗但一致的方向。
- L3 判斷日誌：逐題問（這是重點，慢慢問、追問具體例子）：
- 這 sprint 你做了哪個 AI 給不出來的判斷/決策？（架構選擇、否決爛方案、發現需求其實是錯的）
- 你 抓到 AI 哪個錯？或反過來，哪個你沒抓到、後來爆掉了？
- 你有沒有讓 未來變快？（可複用的東西、釐清模糊需求、解了別人卡住的問題）
Step 5 — 組報告 + 存檔
用 templates/self_review.md 組出報告，寫進 history/（檔名 YYYY-Www.md，例 2026-W26.md，用 ISO 週數）。對比前 1–2 週的趨勢，結尾給 1–2 個下週可改的具體小動作（不是空泛勉勵）。
語言
跟著使用者，預設繁體中文。
