requesting-code-review

請求程式碼審查

派遣程式碼審查子代理人在問題擴大前抓出問題。審查者會獲得精確建構的評估上下文——絕不會是你的對話歷史。這讓審查者專注於工作產出，而非你的思考過程，同時保留你的上下文以便繼續工作。

核心原則： 及早審查，經常審查。

何時請求審查

強制：

• 在子代理人驅動開發的每個任務之後
• 完成主要功能後
• 合併到主分支前

選擇性但有價值：

• 卡住時（新的觀點）
• 重構前（基準檢查）
• 修復複雜錯誤後

如何請求

1. 取得 Git SHA：

BASE_SHA=$(git rev-parse HEAD~1)  # 或 origin/main
HEAD_SHA=$(git rev-parse HEAD)

2. 派遣程式碼審查子代理人：

使用 general-purpose 類型的 Task 工具，填入 code-reviewer.md 範本

佔位符：

• {DESCRIPTION} - 你建置內容的簡短摘要
• {PLAN_OR_REQUIREMENTS} - 它應該做什麼
• {BASE_SHA} - 起始提交
• {HEAD_SHA} - 結束提交

3. 根據回饋行動：

• 立即修復嚴重問題
• 在繼續前修復重要問題
• 記錄次要問題供後續處理
• 若審查者錯誤則提出異議（附上理由）

範例

[剛完成任務 2：新增驗證函式]

你：讓我在繼續前請求程式碼審查。

BASE_SHA=$(git log --oneline | grep "Task 1" | head -1 | awk '{print $1}')
HEAD_SHA=$(git rev-parse HEAD)

[派遣程式碼審查子代理人]
  DESCRIPTION: 新增 verifyIndex() 和 repairIndex()，支援 4 種問題類型
  PLAN_OR_REQUIREMENTS: 來自 docs/superpowers/plans/deployment-plan.md 的任務 2
  BASE_SHA: a7981ec
  HEAD_SHA: 3df7661

[子代理人回覆]：
  優點：架構乾淨，有真實測試
  問題：
    重要：缺少進度指示器
    次要：回報間隔的魔術數字 (100)
  評估：可以繼續

你：[修復進度指示器]
[繼續到任務 3]

與工作流程整合

子代理人驅動開發：

• 每個任務後都審查
• 在問題累積前抓出
• 修復後再進行下一個任務

執行計畫：

• 每個任務後或自然檢查點審查
• 取得回饋，套用，繼續

臨時開發：

• 合併前審查
• 卡住時審查

紅旗

絕對不要：

• 因為「很簡單」而跳過審查
• 忽略嚴重問題
• 在重要問題未修復的情況下繼續
• 與有效的技術回饋爭論

如果審查者錯誤：

• 用技術理由提出異議
• 展示證明可行的程式碼/測試
• 要求澄清

請參閱範本：requesting-code-review/code-reviewer.md