Back to Details

review-changes

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Review Git Changes

审查Git变更

Instructions

操作说明

Perform thorough code review of current working copy changes, optionally compare to plan, and identify engineering issues.
对当前工作副本的变更进行全面代码审查，可选择性与规划进行对比，并识别工程问题。

Phase 1: Discover Changes & Context

第一阶段：发现变更与上下文

Step 1: Get Current Changes

步骤1：获取当前变更

bash
undefined
bash
undefined

See changed files

查看已变更文件

git status
git status

See detailed diff

查看详细差异

git diff
git diff

See staged changes separately

单独查看已暂存的变更

git diff --cached
git diff --cached

See both staged and unstaged

同时查看已暂存和未暂存的变更

git diff HEAD
undefined
git diff HEAD
undefined

Step 2: Identify Related Plan (if exists)

步骤2：识别相关规划（若存在）

Search for related plan file:
  • Check for relevant plan tickets (
    tk list --tag plan
    )
  • Look for plan mentioned in branch name
  • Ask user if unsure which plan applies
  • If no plan exists, review against general best practices
If plan exists:
  • Read the entire plan
  • Understand intended design and architecture
  • Note specific requirements and constraints
搜索相关规划文件：
  • 检查相关规划工单（
    tk list --tag plan
    ）
  • 查看分支名称中提及的规划
  • 若不确定适用哪个规划，询问用户
  • 若不存在规划，则对照通用最佳实践进行审查
若存在规划：
  • 通读整个规划
  • 理解预期的设计与架构
  • 记录具体要求和约束条件

Step 3: Categorize Changed Files

步骤3：对变更文件进行分类

Group files by type:
  • New files: Created from scratch
  • Modified files: Existing files changed
  • Deleted files: Removed files
  • Renamed/moved files: Organizational changes
Create todo list with one item per changed file to review.
按类型对文件分组：
  • 新文件：从头创建的文件
  • 修改文件：已存在的文件被修改
  • 删除文件：已移除的文件
  • 重命名/移动文件：仅做了组织性变更的文件
创建待办列表，每个变更文件对应一个审查项。

Phase 2: Systematic File Review

第二阶段：系统化文件审查

For EACH changed file in the todo list:
对待办列表中的每个变更文件：

Step 1: Read Current State

步骤1：阅读当前状态

  • Read the entire file in its current state
  • Understand what it does
  • Note its responsibilities
  • 阅读文件的完整当前状态
  • 理解其功能
  • 记录其职责范围

Step 2: Analyze the Changes

步骤2：分析变更内容

Read git diff to see exactly what changed:
  • What was added?
  • What was removed?
  • What was modified?
查看Git Diff以明确具体变更：
  • 新增了什么？
  • 删除了什么？
  • 修改了什么？

Step 3: Assess Against Plan (if applicable)

步骤3：对照规划评估（若适用）

If plan exists, check:
  • Does implementation match plan?
    • Are planned features implemented correctly?
    • Is architecture followed?
    • Are file names as specified?
  • Scope adherence:
    • Is this change in the plan?
    • Is it necessary for the plan's goals?
    • Is it scope creep?
  • REMOVAL SPEC compliance:
    • If plan said to remove code, was it removed?
    • Is old code still present when it shouldn't be?
若存在规划，检查：
  • 实现是否符合规划？
    • 规划的功能是否正确实现？
    • 是否遵循了架构设计？
    • 文件命名是否符合指定规范？
  • 范围一致性：
    • 此变更是否在规划范围内？
    • 对于实现规划目标是否必要？
    • 是否存在范围蔓延？
  • 移除规范合规性：
    • 若规划要求移除代码，是否已移除？
    • 是否仍存在不应保留的旧代码？

Step 4: Identify Engineering Issues

步骤4：识别工程问题

Check for Bad Engineering:
  • Bugs: Logic errors, off-by-one, race conditions
  • Poor error handling: Swallowed errors, generic catches
  • Missing validation: No input validation, no null checks
  • Hard-coded values: Magic numbers, hardcoded URLs/paths
  • Tight coupling: Unnecessary dependencies between modules
  • Violation of SRP: Class/function doing too many things
  • Incorrect patterns: Misuse of design patterns
  • Type issues: Use of 
    any
    , missing types, wrong types
  • Missing edge cases: Doesn't handle empty/null/error cases
Check for Over-Engineering:
  • Unnecessary abstraction: Too many layers for simple logic
  • Premature optimization: Complex code for unmeasured performance
  • Framework overuse: Using heavy library for simple task
  • Feature creep: Adding features not in requirements
  • Gold plating: Excessive polish on non-critical code
  • YAGNI violations: Code for "might need later" scenarios
  • Complexity without benefit: Complicated when simple works
Check for Suboptimal Solutions:
  • Duplication: Copy-pasted code instead of extraction
  • Reinventing wheel: Custom code when standard library exists
  • Wrong tool: Using inappropriate data structure/algorithm
  • Inefficient approach: O(n²) when O(n) is obvious
  • Poor naming: Unclear variable/function names
  • Missing reuse: Existing utilities/types not used
  • Inconsistent patterns: Doesn't match codebase style
  • Technical debt: Quick hack instead of proper solution
检查不良工程实践：
  • Bug：逻辑错误、差一错误、竞态条件
  • 错误处理不佳：错误被吞掉、通用捕获语句
  • 缺少验证：无输入验证、无空值检查
  • 硬编码值：魔法数字、硬编码URL/路径
  • 紧耦合：模块间存在不必要的依赖
  • 违反单一职责原则：类/函数承担过多职责
  • 模式误用：设计模式使用错误
  • 类型问题：使用
    any
    、缺少类型、类型错误
  • 缺少边界场景处理：未处理空值/空集合/错误场景
检查过度设计：
  • 不必要的抽象：简单逻辑却有过多层级
  • 过早优化：为未验证的性能需求编写复杂代码
  • 框架滥用：用重型库完成简单任务
  • 功能蔓延：添加需求外的功能
  • 镀金：对非关键代码过度打磨
  • 违反YAGNI原则：为“以后可能需要”的场景编写代码
  • 无意义的复杂度：能用简单方案却选择复杂实现
检查非最优解决方案：
  • 代码重复：复制粘贴代码而非提取复用
  • 重复造轮子：已有标准库却编写自定义代码
  • 工具选型错误：使用不恰当的数据结构/算法
  • 低效实现：明明可以用O(n)却用了O(n²)
  • 命名不佳：变量/函数名称不清晰
  • 未复用现有代码：未使用已有的工具类/类型
  • 模式不一致：与代码库现有风格不符
  • 技术债务：用快速 hack 替代合理实现

Step 5: Check Code Quality

步骤5：检查代码质量

  • Readability: Is code clear and self-documenting?
  • Maintainability: Will this be easy to change later?
  • Testability: Can this be tested easily?
  • Performance: Any obvious performance issues?
  • Security: Any security vulnerabilities?
  • Consistency: Matches existing codebase patterns?
  • 可读性：代码是否清晰且自文档化？
  • 可维护性：后续是否易于修改？
  • 可测试性：是否易于测试？
  • 性能：是否存在明显的性能问题？
  • 安全性：是否存在安全漏洞？
  • 一致性：是否匹配代码库现有模式？

Step 6: Record Findings

步骤6：记录发现的问题

Store in memory:
File: path/to/file.ts
Change Type: [New|Modified|Deleted]
Plan Compliance: [Matches|Deviates|Not in plan]
Issues:
  Bad Engineering:
    - [Specific issue with line number]
  Over-Engineering:
    - [Specific issue with line number]
  Suboptimal:
    - [Specific issue with line number]
Severity: [CRITICAL|HIGH|MEDIUM|LOW]
在内存中记录：
文件: path/to/file.ts
变更类型: [新增|修改|删除]
规划合规性: [符合|偏离|未包含在规划中]
问题:
  不良工程实践:
    - [带行号的具体问题]
  过度设计:
    - [带行号的具体问题]
  非最优方案:
    - [带行号的具体问题]
严重程度: [CRITICAL|HIGH|MEDIUM|LOW]

Step 7: Update Todo

步骤7：更新待办列表

Mark file as reviewed in todo list.
在待办列表中标记该文件已审查。

Phase 2.5: Issue/Task Coverage Verification (MANDATORY)

阶段2.5：需求/任务覆盖验证（强制要求）

CRITICAL: Before completing the review, verify that 100% of the original issue/task requirements are implemented.
关键要求：完成审查前，必须验证原始需求/任务的所有要求是否100%实现。

Step 1: Identify Source Requirements

步骤1：确定需求来源

Locate the original requirements from:
  • GitHub issue (
    gh issue view <number>
    )
  • PR description referencing issues
  • Task ticket or plan ticket (tagged 
    plan
    )
  • Commit messages describing the work
从以下位置定位原始需求：
  • GitHub Issue（
    gh issue view <number>
    ）
  • 引用了Issue的PR描述
  • 任务工单或规划工单（标记为
    plan
    ）
  • 描述工作内容的提交信息

Step 2: Extract ALL Requirements

步骤2：提取所有需求

Create exhaustive checklist:
  • Functional requirements (what it should do)
  • Acceptance criteria (how to verify)
  • Edge cases mentioned
  • Error handling requirements
创建完整的检查清单：
  • 功能需求（应该实现什么）
  • 验收标准（如何验证）
  • 提及的边界场景
  • 错误处理要求

Step 3: Verify Each Requirement

步骤3：验证每个需求

#RequirementStatusEvidence
1[requirement]✅/❌/⚠️file:line or "Missing"
序号需求内容状态证据
1[需求内容]✅/❌/⚠️文件:行号 或 "缺失"

Step 4: Coverage Assessment

步骤4：覆盖情况评估

Requirements Coverage = (Implemented / Total) × 100%
Anything less than 100% = REQUEST CHANGES immediately
Add to report:
markdown
undefined
需求覆盖率 = (已实现需求数 / 总需求数) × 100%
覆盖率低于100% = 立即要求修改
在报告中添加：
markdown
undefined

Issue/Task Coverage

需求/任务覆盖情况

Source: [Issue #X / Plan file] Coverage: X% (Y of Z requirements)
来源: [Issue #X / 规划文件] 覆盖率: X% (Z项需求中已实现Y项)

Missing Requirements

缺失的需求

  • ❌ [Requirement X]: Not implemented
  • ❌ [Requirement Y]: Partially implemented - [what's missing]
VERDICT: Coverage incomplete. Cannot approve until 100% implemented.
undefined
  • ❌ [需求X]: 未实现
  • ❌ [需求Y]: 部分实现 - [缺失内容]
结论: 覆盖不完整。必须实现所有需求后才能批准。
undefined

Phase 3: Cross-File Analysis

第三阶段：跨文件分析

After reviewing all files:
完成所有文件审查后：

Step 1: Architectural Impact

步骤1：架构影响

  • How do changes affect overall system architecture?
  • Are there breaking changes?
  • Do changes introduce new dependencies?
  • Is there architectural drift from the plan?
  • 变更对整体系统架构有何影响？
  • 是否存在破坏性变更？
  • 变更是否引入了新依赖？
  • 与规划相比是否存在架构漂移？

Step 2: Pattern Consistency

步骤2：模式一致性

  • Are changes consistent with each other?
  • Do they follow same patterns?
  • Any conflicting approaches?
  • 变更之间是否一致？
  • 是否遵循相同的模式？
  • 是否存在冲突的实现方式？

Step 3: Completeness Check

步骤3：完整性检查

  • Are all related changes present?
  • Missing files that should be changed?
  • Orphaned references?
  • 所有相关变更是否都已提交？
  • 是否缺少应变更的文件？
  • 是否存在孤立的引用？

Phase 4: Generate Review Report

第四阶段：生成审查报告

Create report at 
.reviews/code-review-[timestamp].md
:
markdown
undefined
在
.reviews/code-review-[timestamp].md
路径下创建报告：
markdown
undefined

Code Review Report

代码审查报告

Date: [timestamp] Branch: [branch name] Related Plan: [plan file or "None"] Files Changed: X Issues Found: Y
日期: [时间戳] 分支: [分支名称] 相关规划: [规划文件或 "无"] 变更文件数: X 发现问题数: Y

Executive Summary

执行摘要

  • Critical Issues: X (must fix before merge)
  • High Priority: Y (should fix)
  • Medium Priority: Z (consider fixing)
  • Low Priority: W (suggestions)
Overall Assessment: [APPROVE|REQUEST CHANGES|REJECT]
  • 关键问题: X个（合并前必须修复）
  • 高优先级: Y个（应该修复）
  • 中优先级: Z个（建议修复）
  • 低优先级: W个（优化建议）
整体评估: [批准|要求修改|拒绝]

Plan Compliance (if applicable)

规划合规性（若适用）

Matches Plan ✅

符合规划 ✅

  • Feature X implemented correctly
  • Architecture follows design
  • File naming conventions followed
  • 功能X已正确实现
  • 架构遵循设计要求
  • 符合文件命名规范

Deviates from Plan ⚠️

偏离规划 ⚠️

  • Implementation differs from planned approach in [area]
  • Missing feature Y from plan
  • Scope creep: Added Z not in plan
  • [某领域]的实现与规划方案不同
  • 缺少规划中的功能Y
  • 范围蔓延：添加了规划外的功能Z

REMOVAL SPEC Status

移除规范执行状态

  • ✅ Old code removed from 
    file.ts:50-100
  • ❌ Legacy function still exists in 
    auth.ts:42
    (should be removed)
  • ✅ 旧代码已从
    file.ts:50-100
    移除
  • ❌ 遗留函数仍存在于
    auth.ts:42
    （应移除）

Issues by Severity

按严重程度分类的问题

CRITICAL: Bad Engineering

关键：不良工程实践

Logic Bug in 
src/services/auth.ts:125

src/services/auth.ts:125
中的逻辑Bug

typescript
// Current code:
if (user.role = 'admin') { // Assignment instead of comparison
  grantAccess()
}
Issue: Assignment operator used instead of equality check. This always evaluates to true and grants everyone admin access. Severity: CRITICAL - Security vulnerability Fix: Change 
=
to 
===
typescript
// 当前代码:
if (user.role = 'admin') { // 赋值而非比较
  grantAccess()
}
问题: 使用赋值运算符而非相等性检查。此代码始终为true，会向所有用户授予管理员权限。 严重程度: 关键 - 安全漏洞 修复方案: 将
=
改为
===

Unhandled Promise in 
src/api/client.ts:67

src/api/client.ts:67
中的未处理Promise

typescript
// Current code:
fetchData().then(data => process(data)) // No error handling
Issue: Promise rejection not handled, will crash silently Severity: CRITICAL - Application stability Fix: Add 
.catch()
or use try/catch with async/await
typescript
// 当前代码:
fetchData().then(data => process(data)) // 无错误处理
问题: Promise拒绝未被处理，会导致程序静默崩溃 严重程度: 关键 - 影响应用稳定性 修复方案: 添加
.catch()
或使用async/await配合try/catch

HIGH: Over-Engineering

高优先级：过度设计

Unnecessary Abstraction in 
src/utils/formatter.ts

src/utils/formatter.ts
中的不必要抽象

typescript
// Current code: 50 lines of abstraction
class FormatterFactory {
  createFormatter(type: string): IFormatter { /* ... */ }
}
class StringFormatter implements IFormatter { /* ... */ }
// ... only used once for simple string formatting
Issue: Complex factory pattern for single use case Severity: HIGH - Maintenance burden Better Approach: Simple function 
formatString(value: string): string
typescript
// 当前代码: 50行抽象代码
class FormatterFactory {
  createFormatter(type: string): IFormatter { /* ... */ }
}
class StringFormatter implements IFormatter { /* ... */ }
// ...仅用于一次简单的字符串格式化
问题: 为单一使用场景引入复杂的工厂模式 严重程度: 高 - 增加维护负担 更好的实现: 简单函数
formatString(value: string): string

MEDIUM: Suboptimal Solutions

中优先级：非最优解决方案

Code Duplication in 
src/components/

src/components/
中的代码重复

Files: 
user-form.tsx
, 
admin-form.tsx
Issue: Both contain identical validation logic (30 lines duplicated) Severity: MEDIUM - Maintenance issue Better Approach: Extract to 
src/utils/form-validation.ts
文件: 
user-form.tsx
, 
admin-form.tsx
问题: 两者包含完全相同的验证逻辑（30行重复代码） 严重程度: 中 - 维护问题 更好的实现: 提取到
src/utils/form-validation.ts

Not Using Existing Type in 
src/types/user.ts

未使用
src/types/user.ts
中的现有类型

typescript
// Current code:
interface UserData {
  id: string
  email: string
  name: string
}
// But `User` type already exists with same fields in `src/models/user.ts`
Issue: Duplicate type definition Severity: MEDIUM - Type inconsistency risk Fix: Import and use existing 
User
type
typescript
// 当前代码:
interface UserData {
  id: string
  email: string
  name: string
}
// 但`src/models/user.ts`中已存在字段完全相同的`User`类型
问题: 重复定义类型 严重程度: 中 - 存在类型不一致风险 修复方案: 导入并使用现有的
User
类型

LOW: Suggestions

低优先级：优化建议

Verbose Naming in 
src/services/database-connection-manager.ts

src/services/database-connection-manager.ts
中的冗长命名

Issue: Overly verbose filename Suggestion: Simplify to 
src/services/database.service.ts
问题: 文件名过于冗长 建议: 简化为
src/services/database.service.ts

Issues by Category

按类别分类的问题

Bad Engineering (X issues)

不良工程实践（X个问题）

  • Logic bugs: X
  • Missing error handling: Y
  • Type issues: Z
  • Missing validation: W
  • 逻辑Bug: X个
  • 缺少错误处理: Y个
  • 类型问题: Z个
  • 缺少验证: W个

Over-Engineering (Y issues)

过度设计（Y个问题）

  • Unnecessary abstraction: X
  • Premature optimization: Y
  • Feature creep: Z
  • 不必要的抽象: X个
  • 过早优化: Y个
  • 功能蔓延: Z个

Suboptimal Solutions (Z issues)

非最优解决方案（Z个问题）

  • Code duplication: X
  • Reinventing wheel: Y
  • Poor naming: Z
  • Not using existing code: W
  • 代码重复: X个
  • 重复造轮子: Y个
  • 命名不佳: Z个
  • 未使用现有代码: W个

Architectural Assessment

架构评估

Positive Changes

积极变更

  • Clean separation of concerns in new modules
  • Proper use of dependency injection
  • Good test coverage added
  • 新模块中关注点分离清晰
  • 正确使用依赖注入
  • 添加了良好的测试覆盖

Concerns

关注点

  • New dependency introduced without discussion
  • Breaking change to public API
  • Coupling between previously independent modules
  • 引入了未经过讨论的新依赖
  • 对公共API进行了破坏性变更
  • 原本独立的模块之间产生了耦合

Technical Debt Introduced

引入的技术债务

  • Quick hack in 
    auth.ts:200
    marked with TODO
  • Temporary file 
    temp-processor.ts
    added
  • Migration code that should be removed later
  • auth.ts:200
    中标记为TODO的快速hack
  • 添加了临时文件
    temp-processor.ts
  • 存在后续应移除的迁移代码

Detailed File Reviews

详细文件审查

src/services/auth.ts (Modified)

src/services/auth.ts（已修改）

Plan Compliance: Matches Changes: 45 lines added, 20 removed Issues:
  • CRITICAL: Logic bug at line 125 (assignment vs equality)
  • HIGH: Missing error handling at line 89 Positive:
  • Good use of existing types
  • Clear function names
规划合规性: 符合 变更内容: 新增45行，删除20行 问题:
  • 关键：第125行的逻辑Bug（赋值 vs 相等性检查）
  • 高优先级：第89行缺少错误处理 优点:
  • 正确使用了现有类型
  • 函数命名清晰

src/components/user-form.tsx (New)

src/components/user-form.tsx（新增）

Plan Compliance: Not in plan (scope creep) Changes: 150 lines added Issues:
  • MEDIUM: Duplicates logic from admin-form.tsx
  • LOW: Could use existing form validation utility Positive:
  • Clean component structure
  • Good TypeScript usage
[Continue for all changed files]
规划合规性: 未包含在规划中（范围蔓延） 变更内容: 新增150行 问题:
  • 中优先级：与admin-form.tsx存在逻辑重复
  • 低优先级：可使用现有的表单验证工具 优点:
  • 组件结构清晰
  • TypeScript使用规范
[所有变更文件的审查内容以此类推]

Statistics

统计数据

By Severity:
  • Critical: X
  • High: Y
  • Medium: Z
  • Low: W
By Category:
  • Bad Engineering: X
  • Over-Engineering: Y
  • Suboptimal: Z
By File Type:
  • Services: X issues
  • Components: Y issues
  • Utils: Z issues
按严重程度:
  • 关键: X个
  • 高优先级: Y个
  • 中优先级: Z个
  • 低优先级: W个
按类别:
  • 不良工程实践: X个
  • 过度设计: Y个
  • 非最优方案: Z个
按文件类型:
  • 服务层: X个问题
  • 组件: Y个问题
  • 工具类: Z个问题

Recommendations

建议

Must Fix (Before Merge)

合并前必须修复

  1. Fix logic bug in 
    auth.ts:125
    - Security issue
  2. Add error handling in 
    client.ts:67
    - Stability issue
  3. Remove temporary file 
    temp-processor.ts
    - Plan violation
  1. 修复
    auth.ts:125
    中的逻辑Bug - 安全问题
  2. 为
    client.ts:67
    添加错误处理 - 稳定性问题
  3. 移除临时文件
    temp-processor.ts
    - 违反规划要求

Should Fix

应该修复

  1. Extract duplicated validation logic
  2. Simplify over-abstracted formatter
  3. Use existing types instead of duplicates
  1. 提取重复的验证逻辑
  2. 简化过度抽象的格式化工具
  3. 使用现有类型而非重复定义

Consider

可考虑优化

  1. Rename verbose files
  2. Add more inline documentation
  3. Improve variable naming in complex functions
  1. 重命名冗长的文件
  2. 添加更多内联文档
  3. 优化复杂函数中的变量命名

Overall Assessment

整体评估

Recommendation: REQUEST CHANGES
Reasoning:
  • 2 critical security/stability issues must be fixed
  • Over-engineering in several areas adds unnecessary complexity
  • Code duplication will cause maintenance issues
  • Some scope creep not discussed in plan
After Fixes: Changes will be solid. Core implementation is sound, just needs cleanup and bug fixes.
undefined
建议: 要求修改
理由:
  • 存在2个关键的安全/稳定性问题必须修复
  • 多个区域的过度设计增加了不必要的复杂度
  • 代码重复会导致后续维护问题
  • 存在部分未在规划中讨论的范围蔓延
修复后: 变更将变得可靠。核心实现合理，仅需清理和Bug修复。
undefined

Phase 5: Summary for User

第五阶段：给用户的摘要

Provide concise summary:
markdown
undefined
提供简洁的总结：
markdown
undefined

Code Review Complete

代码审查完成

Assessment: [APPROVE|REQUEST CHANGES|REJECT]

评估结果: [批准|要求修改|拒绝]

Critical Issues (X)

关键问题（X个）

  • Security bug in 
    auth.ts:125
    - assignment vs equality
  • Unhandled promise in 
    client.ts:67
    - will crash
  • auth.ts:125
    中的安全Bug - 赋值而非相等性检查
  • client.ts:67
    中的未处理Promise - 会导致崩溃

High Priority (Y)

高优先级问题（Y个）

  • Over-engineering in 
    formatter.ts
    - unnecessary abstraction
  • Missing error handling in multiple files
  • formatter.ts
    中的过度设计 - 不必要的抽象
  • 多个文件缺少错误处理

Medium Priority (Z)

中优先级问题（Z个）

  • Code duplication between forms
  • Not using existing types
  • 表单之间存在代码重复
  • 未使用现有类型

Plan Compliance

规划合规性

  • ✅ Core features implemented correctly
  • ⚠️ Some scope creep (user-form not in plan)
  • ❌ REMOVAL SPEC incomplete (legacy code still exists)
  • ✅ 核心功能实现正确
  • ⚠️ 存在部分范围蔓延（user-form未包含在规划中）
  • ❌ 移除规范未完全执行（仍存在遗留代码）

Must Fix Before Merge

合并前必须修复

  1. Fix logic bug in auth.ts
  2. Add error handling
  3. Remove legacy code per REMOVAL SPEC
Full Report: 
.reviews/code-review-[timestamp].md
undefined
  1. 修复auth.ts中的逻辑Bug
  2. 添加错误处理
  3. 根据移除规范删除遗留代码
完整报告: 
.reviews/code-review-[timestamp].md
undefined

Critical Principles

核心原则

  • NEVER EDIT FILES - This is review only, not implementation
  • BE THOROUGH - Review every changed file
  • BE SPECIFIC - Point to exact line numbers
  • BE CONSTRUCTIVE - Explain why and suggest better approach
  • CHECK PLAN - If plan exists, verify compliance
  • VERIFY REMOVAL SPEC - Ensure old code was removed
  • IDENTIFY PATTERNS - Note systemic issues across files
  • BE HONEST - Don't approve bad code to be nice
  • SUGGEST ALTERNATIVES - Don't just criticize, help improve
  • 绝不修改文件 - 仅进行审查，不负责实现
  • 全面彻底 - 审查所有变更文件
  • 具体明确 - 指向精确的行号
  • 建设性反馈 - 说明问题原因并提供更好的方案
  • 对照规划 - 若存在规划，验证合规性
  • 验证移除规范 - 确保旧代码已被移除
  • 识别模式问题 - 记录跨文件的系统性问题
  • 保持诚实 - 不因情面批准劣质代码
  • 提供替代方案 - 不只是批评，还要帮助改进

Success Criteria

成功标准

A complete code review includes:
  • 100% of issue/task requirements verified as implemented
  • All changed files reviewed
  • Plan compliance verified (if plan exists)
  • All engineering issues identified and categorized
  • Severity assigned to each issue
  • Specific line numbers referenced
  • Alternative approaches suggested
  • Overall assessment provided
  • Structured report generated
CRITICAL: If issue/task coverage is less than 100%, the review MUST request changes regardless of code quality.
After completing the review, follow handbook 
15.04
to create 
tk
tickets for all surfaced issues.
完整的代码审查应包含：
  • 100%验证需求/任务的实现情况
  • 所有变更文件均已审查
  • 验证规划合规性（若存在规划）
  • 识别并分类所有工程问题
  • 为每个问题分配严重程度
  • 引用具体的行号
  • 提供替代实现方案
  • 给出整体评估
  • 生成结构化报告
关键要求: 若需求/任务覆盖率低于100%，无论代码质量如何，审查必须要求修改。
完成审查后，按照手册
15.04
的要求，为所有发现的问题创建
tk
工单。