sprint-self-review

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（指標被當目標就被灌水）的風險消失，所以可以大膽用質性、主觀的訊號。

四條護欄（任何時候都不能違反）

1. 永不把 LOC / commit 數當分數。 最多當背景脈絡，且必須標註「這是虛榮指標」。
2. 數字只當「提問與旗標」，不當「評分」。 churn 高 → 引導使用者去判斷日誌回答為什麼，而不是說「你不及格」。
3. 只跟過去的自己比，不跨人比較。 價值在趨勢，不在單次絕對值。
4. 判斷日誌（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 判斷日誌：逐題問（這是重點，慢慢問、追問具體例子）：
  1. 這 sprint 你做了哪個 AI 給不出來的判斷/決策？（架構選擇、否決爛方案、發現需求其實是錯的）
  2. 你 抓到 AI 哪個錯？或反過來，哪個你沒抓到、後來爆掉了？
  3. 你有沒有讓 未來變快？（可複用的東西、釐清模糊需求、解了別人卡住的問題）

Step 5 — 組報告 + 存檔

用 templates/self_review.md 組出報告，寫進 history/（檔名 YYYY-Www.md，例 2026-W26.md，用 ISO 週數）。對比前 1–2 週的趨勢，結尾給 1–2 個下週可改的具體小動作（不是空泛勉勵）。

語言

跟著使用者，預設繁體中文。