首頁全景圖學習路線

name	`requesting-code-review`
description (EN)	Use when completing tasks, implementing major features, or before merging to verify work meets requirements
說明 (繁中)	當完成任務、實作主要功能，或在合併之前，用於驗證工作成果符合需求時使用

requesting-code-review

任務完成、發合併前，送審查確認有沒有照需求做。

附屬文件：code-reviewer

Requesting Code Review

請求程式碼審查

Dispatch a code reviewer subagent to catch issues before they cascade. The reviewer gets precisely crafted context for evaluation — never your session's history.

派發一個程式碼審查子代理，在問題擴大蔓延之前捕捉問題。審查者會取得精確建構的評估上下文 —— 絕不是你 session 的歷史。

Core principle: Review early, review often.

核心原則： 早點審查，常常審查。

When to Request Review

何時請求審查

Mandatory: - After each task in subagent-driven development - After completing major feature - Before merge to main

必須： - 子代理驅動開發中每個任務之後 - 完成主要功能之後 - 合併到 main 之前

Optional but valuable: - When stuck (fresh perspective) - Before refactoring (baseline check) - After fixing complex bug

非必要但有價值： - 卡住時（新的視角） - 重構之前（基線檢查） - 修正複雜 bug 之後

How to Request

如何請求

1. Get git SHAs:

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

1. 取得 git SHAs：

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

2. Dispatch code reviewer subagent:

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

Dispatch a general-purpose subagent, filling the template at code-reviewer.md

派發一個 general-purpose 子代理，填入 code-reviewer.md 的範本

Placeholders: - {DESCRIPTION} - Brief summary of what you built - {PLAN_OR_REQUIREMENTS} - What it should do - {BASE_SHA} - Starting commit - {HEAD_SHA} - Ending commit

占位符： - {DESCRIPTION} - 你建構內容的簡短摘要 - {PLAN_OR_REQUIREMENTS} - 它應該做什麼 - {BASE_SHA} - 起始 commit - {HEAD_SHA} - 結束 commit

3. Act on feedback: - Fix Critical issues immediately - Fix Important issues before proceeding - Note Minor issues for later - Push back if reviewer is wrong (with reasoning)

3. 依回饋行動： - 立即修正 Critical 問題 - 在繼續前修正 Important 問題 - 記下 Minor 問題稍後處理 - 若審查者錯了，提出異議（附上理由）

Example

範例

[Just completed Task 2: Add verification function]

You: Let me request code review before proceeding.

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

[Dispatch code reviewer subagent]
  DESCRIPTION: Added verifyIndex() and repairIndex() with 4 issue types
  PLAN_OR_REQUIREMENTS: Task 2 from docs/superpowers/plans/deployment-plan.md
  BASE_SHA: a7981ec
  HEAD_SHA: 3df7661

[Subagent returns]:
  Strengths: Clean architecture, real tests
  Issues:
    Important: Missing progress indicators
    Minor: Magic number (100) for reporting interval
  Assessment: Ready to proceed

You: [Fix progress indicators]
[Continue to Task 3]

[Just completed Task 2: Add verification function]

You: Let me request code review before proceeding.

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

[Dispatch code reviewer subagent]
  DESCRIPTION: Added verifyIndex() and repairIndex() with 4 issue types
  PLAN_OR_REQUIREMENTS: Task 2 from docs/superpowers/plans/deployment-plan.md
  BASE_SHA: a7981ec
  HEAD_SHA: 3df7661

[Subagent returns]:
  Strengths: Clean architecture, real tests
  Issues:
    Important: Missing progress indicators
    Minor: Magic number (100) for reporting interval
  Assessment: Ready to proceed

You: [Fix progress indicators]
[Continue to Task 3]

Common Rationalizations

常見合理化藉口

Excuse	Reality
"I'll just review the diff myself instead of dispatching a reviewer"	You're the coordinator — reviewing the diff inline burns the context window you need to keep driving the work. Dispatch a reviewer subagent: the diff and the evaluation live in its context, and only the findings come back to you.
"The reviewer needs my whole session history to understand the change"	Hand it precisely crafted context, never your session's history. That keeps the reviewer on the work product, not your thought process.

藉口	事實
「我自己審視 diff 就好，不用派發審查者」	你是協調者 —— 直接審視 diff 會燒掉你持續推動工作所需的上下文。派發一個審查子代理：diff 與評估都在它的上下文裡，只有發現回傳給你。
「審查者需要我整個 session 的歷史才能理解變更」	給它精確建構的上下文，絕不是你 session 的歷史。這讓審查者專注於工作成果，而不是你的思考過程。

Red Flags

紅旗

Never: - Skip review because "it's simple" - Ignore Critical issues - Proceed with unfixed Important issues - Argue with valid technical feedback

絕不： - 因為「這很簡單」就跳過審查 - 忽略 Critical 問題 - 帶著未修正的 Important 問題繼續 - 與合理的技術回饋爭辯

If reviewer wrong: - Push back with technical reasoning - Show code/tests that prove it works - Request clarification

如果審查者錯了： - 用技術論證提出異議 - 展示證明它能運作的程式碼/測試 - 請求釐清

See template at: code-reviewer.md

範本見：code-reviewer.md