Back to Details

code-review

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Code Review

代码审查

Guide proper code review practices emphasizing technical rigor, evidence-based claims, and verification over performative responses.
指导注重技术严谨性、基于证据的声明与验证的正确代码审查实践，而非流于形式的回应。

Overview

概述

Code review requires three distinct practices:
  1. Receiving feedback - Technical evaluation over performative agreement
  2. Requesting reviews - Systematic review via code-reviewer subagent
  3. Verification gates - Evidence before any completion claims
Each practice has specific triggers and protocols detailed in reference files.
代码审查需要三种不同的实践：
  1. 接收反馈 - 以技术评估替代流于形式的认同
  2. 请求审查 - 通过code-reviewer subagent进行系统化审查
  3. 验证关卡 - 在做出任何完成声明前先获取证据
每种实践都有详细的触发条件与流程，详见参考文件。

Core Principle

核心原则

Technical correctness over social comfort. Verify before implementing. Ask before assuming. Evidence before claims.
技术正确性优先于社交舒适度。先验证再实施。先询问再假设。先有证据再做声明。

When to Use This Skill

何时使用该技能

Receiving Feedback

接收反馈

Trigger when:
  • Receiving code review comments from any source
  • Feedback seems unclear or technically questionable
  • Multiple review items need prioritization
  • External reviewer lacks full context
  • Suggestion conflicts with existing decisions
Reference: 
references/code-review-reception.md
触发场景：
  • 从任何来源收到代码审查评论
  • 反馈内容模糊或存在技术疑问
  • 多个审查项需要优先级排序
  • 外部审查者缺乏完整上下文
  • 建议与现有决策存在冲突
参考文件： 
references/code-review-reception.md

Requesting Review

请求审查

Trigger when:
  • Completing tasks in subagent-driven development (after EACH task)
  • Finishing major features or refactors
  • Before merging to main branch
  • Stuck and need fresh perspective
  • After fixing complex bugs
Reference: 
references/requesting-code-review.md
触发场景：
  • 在子代理驱动的开发中完成任务后（每个任务完成后都需触发）
  • 完成主要功能或重构后
  • 合并到主分支前
  • 遇到瓶颈需要新视角时
  • 修复复杂漏洞后
参考文件： 
references/requesting-code-review.md

Verification Gates

验证关卡

Trigger when:
  • About to claim tests pass, build succeeds, or work is complete
  • Before committing, pushing, or creating PRs
  • Moving to next task
  • Any statement suggesting success/completion
  • Expressing satisfaction with work
Reference: 
references/verification-before-completion.md
触发场景：
  • 即将声明测试通过、构建成功或工作完成时
  • 提交、推送或创建PR前
  • 进入下一个任务前
  • 任何暗示成功/完成的表述
  • 对工作表示满意时
参考文件： 
references/verification-before-completion.md

Quick Decision Tree

快速决策树

SITUATION?
│
├─ Received feedback
│  ├─ Unclear items? → STOP, ask for clarification first
│  ├─ From human partner? → Understand, then implement
│  └─ From external reviewer? → Verify technically before implementing
│
├─ Completed work
│  ├─ Major feature/task? → Request code-reviewer subagent review
│  └─ Before merge? → Request code-reviewer subagent review
│
└─ About to claim status
   ├─ Have fresh verification? → State claim WITH evidence
   └─ No fresh verification? → RUN verification command first
SITUATION?
│
├─ Received feedback
│  ├─ Unclear items? → STOP, ask for clarification first
│  ├─ From human partner? → Understand, then implement
│  └─ From external reviewer? → Verify technically before implementing
│
├─ Completed work
│  ├─ Major feature/task? → Request code-reviewer subagent review
│  └─ Before merge? → Request code-reviewer subagent review
│
└─ About to claim status
   ├─ Have fresh verification? → State claim WITH evidence
   └─ No fresh verification? → RUN verification command first

Receiving Feedback Protocol

接收反馈流程

Response Pattern

响应模式

READ → UNDERSTAND → VERIFY → EVALUATE → RESPOND → IMPLEMENT
READ → UNDERSTAND → VERIFY → EVALUATE → RESPOND → IMPLEMENT

Key Rules

关键规则

  • ❌ No performative agreement: "You're absolutely right!", "Great point!", "Thanks for [anything]"
  • ❌ No implementation before verification
  • ✅ Restate requirement, ask questions, push back with technical reasoning, or just start working
  • ✅ If unclear: STOP and ask for clarification on ALL unclear items first
  • ✅ YAGNI check: grep for usage before implementing suggested "proper" features
  • ❌ 禁止流于形式的认同："You're absolutely right!", "Great point!", "Thanks for [anything]"
  • ❌ 禁止未验证就实施
  • ✅ 重述需求、提出问题、以技术理由反驳，或直接开始工作
  • ✅ 若内容模糊：立即停止，先针对所有模糊项请求澄清
  • ✅ YAGNI检查：在实施建议的"proper"功能前，先搜索其实际使用场景

Source Handling

来源处理

  • Human partner: Trusted - implement after understanding, no performative agreement
  • External reviewers: Verify technically correct, check for breakage, push back if wrong
Full protocol: 
references/code-review-reception.md
  • 人类合作者：可信任 - 理解后实施，无需流于形式的认同
  • 外部审查者：先验证技术正确性，检查是否会导致故障，若有误则提出反驳
完整流程： 
references/code-review-reception.md

Requesting Review Protocol

请求审查流程

When to Request

请求时机

  • After each task in subagent-driven development
  • After major feature completion
  • Before merge to main
  • 子代理驱动开发中每个任务完成后
  • 主要功能完成后
  • 合并到主分支前

Process

流程

  1. Get git SHAs: 
    BASE_SHA=$(git rev-parse HEAD~1)
    and 
    HEAD_SHA=$(git rev-parse HEAD)
  2. Dispatch code-reviewer subagent via Task tool with: WHAT_WAS_IMPLEMENTED, PLAN_OR_REQUIREMENTS, BASE_SHA, HEAD_SHA, DESCRIPTION
  3. Act on feedback: Fix Critical immediately, Important before proceeding, note Minor for later
Full protocol: 
references/requesting-code-review.md
  1. 获取git SHA：
    BASE_SHA=$(git rev-parse HEAD~1)
    和 
    HEAD_SHA=$(git rev-parse HEAD)
  2. 通过任务工具调度code-reviewer subagent，需提供：WHAT_WAS_IMPLEMENTED、PLAN_OR_REQUIREMENTS、BASE_SHA、HEAD_SHA、DESCRIPTION
  3. 根据反馈行动：立即修复严重问题，在推进前修复重要问题，记录次要问题留待后续处理
完整流程： 
references/requesting-code-review.md

Verification Gates Protocol

验证关卡流程

The Iron Law

铁则

NO COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE
无新鲜验证证据，不得做出完成声明

Gate Function

关卡流程

IDENTIFY command → RUN full command → READ output → VERIFY confirms claim → THEN claim
Skip any step = lying, not verifying
识别命令 → 运行完整命令 → 读取输出 → 验证确认声明 → 再做出声明
跳过任何步骤 = 不实陈述，未完成验证

Requirements

要求

  • Tests pass: Test output shows 0 failures
  • Build succeeds: Build command exit 0
  • Bug fixed: Test original symptom passes
  • Requirements met: Line-by-line checklist verified
  • 测试通过：测试输出显示0个失败项
  • 构建成功：构建命令退出码为0
  • 漏洞修复：测试原症状已解决
  • 需求满足：逐行核对检查清单确认

Verification Commands

验证命令

bash
undefined
bash
undefined

Tests (prefer bun)

Tests (prefer bun)

bun test # or: npm test
bun test # or: npm test

Build

Build

bun run build # or: npm run build
bun run build # or: npm run build

Lint

Lint

bun run lint # or: npm run lint
bun run lint # or: npm run lint

Type check

Type check

bun run typecheck # or: bunx tsc --noEmit
undefined
bun run typecheck # or: bunx tsc --noEmit
undefined

Red Flags - STOP

危险信号 - 立即停止

Using "should"/"probably"/"seems to", expressing satisfaction before verification, committing without verification, trusting agent reports, ANY wording implying success without running verification
Full protocol: 
references/verification-before-completion.md
使用"应该"/"可能"/"似乎"等表述、在验证前表示对工作满意、未验证就提交、信任代理报告、任何未运行验证就暗示成功的表述
完整流程： 
references/verification-before-completion.md

Integration with Workflows

与工作流集成

  • Subagent-Driven: Review after EACH task, verify before moving to next
  • Pull Requests: Verify tests pass, request code-reviewer review before merge
  • General: Apply verification gates before any status claims, push back on invalid feedback
  • 子代理驱动开发：每个任务完成后进行审查，进入下一个任务前先验证
  • 拉取请求（Pull Request）：验证测试通过后，请求code-reviewer子代理审查再合并
  • 通用场景：在做出任何状态声明前应用验证关卡，对无效反馈提出反驳

Bottom Line

总结

  1. Technical rigor over social performance - No performative agreement
  2. Systematic review processes - Use code-reviewer subagent
  3. Evidence before claims - Verification gates always
Verify. Question. Then implement. Evidence. Then claim.
  1. 技术严谨优先于社交表现 - 拒绝流于形式的认同
  2. 系统化审查流程 - 使用code-reviewer subagent
  3. 先有证据再做声明 - 始终启用验证关卡
先验证，再质疑，然后实施。先有证据，再做声明。