Requesting Code Review

作者 obra5bf4e7801107無授權條款292K 個星標收錄於 2026年9月23日更新於 2026年9月23日儲存庫昨天更新

Use when completing tasks, implementing major features, or before merging to verify work meets requirements

AI 產生的概覽

派發程式碼審查子代理,並為它準備精確的上下文,在問題擴散前先找出問題。

功能
指導代理如何發起程式碼審查:說明何時必須審查、何時可選審查,示範如何取得基準與最新的 git SHA,並說明如何以 code-reviewer.md 範本派發 general-purpose 審查子代理,填入描述、需求與 SHA 佔位符。也說明如何依嚴重程度處理回饋,以及在審查意見有誤時如何提出有理有據的反駁。產出是對工作成果的審查,而非工作階段的歷史紀錄。
適用情境
適用於子代理驅動開發中每完成一項任務後、完成重大功能後,或合併到主分支之前。卡住時、重構前或修復複雜缺陷後也可使用。
執行需求
需要 git 以解析提交 SHA,並需要能派發子代理;此技能不附帶指令碼,僅提供 code-reviewer.md 範本。

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.

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

Optional but valuable:

  • When stuck (fresh perspective)
  • Before refactoring (baseline check)
  • After fixing complex bug

How to Request

1. Get git SHAs:

bash
BASE_SHA=$(git rev-parse HEAD~1)  # or: git merge-base origin/main HEADHEAD_SHA=$(git rev-parse HEAD)

2. Dispatch code reviewer subagent:

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

Placeholders:

  • {DESCRIPTION} - Brief summary of what you built
  • {PLAN_OR_REQUIREMENTS} - What it should do
  • {BASE_SHA} - Starting commit
  • {HEAD_SHA} - Ending 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)

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]

Common Rationalizations

ExcuseReality
"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.

Red Flags

Never:

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

If reviewer wrong:

  • Push back with technical reasoning
  • Show code/tests that prove it works
  • Request clarification

See template at: code-reviewer.md [blocked]

來源與署名

來源:obra/superpowers位於skills/requesting-code-review提交5bf4e78

授權條款: 無授權條款

內容歸原作者所有。SourceWeft 從公開儲存庫中收錄這些內容。

檢舉或申請下架