Back to Details

review-staged-changes

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Review Staged Changes

审查暂存变更

Reviews staged git changes to ensure they improve code quality, maintainability, and readability without introducing regressions.
审查暂存的Git变更，确保它们在不引入回归问题的前提下，提升代码质量、可维护性和可读性。

Workflow

工作流程

When reviewing staged changes:
  1. Get the staged diff: 
    git diff --cached
    or 
    git diff --staged
  2. Analyze each change against the four criteria below
  3. Provide structured feedback using the template in this skill: 
    templates/review-summary.md
    (relative to the skill directory)
审查暂存变更时：
  1. 获取暂存diff：
    git diff --cached
    或 
    git diff --staged
  2. 对照以下四项标准分析每项变更
  3. 使用本skill中的模板提供结构化反馈：
    templates/review-summary.md
    （相对于skill目录）

Review Criteria

审查标准

1. Contextual Sense

1. 上下文合理性

Verify changes align with the stated purpose:
  • Do the modifications address the intended goal?
  • Are related changes grouped logically?
  • Is the scope appropriate (not too broad, not too narrow)?
  • Are any unrelated changes included that should be in a separate commit?
验证变更是否符合既定目标：
  • 修改内容是否解决了预期问题？
  • 相关变更是否按逻辑分组？
  • 范围是否恰当（既不过宽也不过窄）？
  • 是否包含了应单独提交的无关变更？

2. Regression Prevention

2. 回归问题预防

Identify potential breaking changes:
  • Behavior changes: Does the code behave differently than before?
  • API changes: Are function signatures, props, or interfaces modified?
  • Side effects: Could changes affect other parts of the codebase?
  • Dependencies: Are imports, dependencies, or external integrations affected?
  • Edge cases: Are existing edge cases still handled correctly?
Red flags:
  • Removing error handling without replacement
  • Changing return types or function signatures
  • Modifying shared utilities without checking usages
  • Removing validation or checks
  • Changing default values that other code might depend on
识别潜在的破坏性变更：
  • 行为变更：代码行为是否与之前不同？
  • API变更：函数签名、props或接口是否被修改？
  • 副作用：变更是否可能影响代码库的其他部分？
  • 依赖项：导入、依赖或外部集成是否受到影响？
  • 边缘情况：现有边缘情况是否仍能被正确处理？
危险信号：
  • 移除错误处理但未替换
  • 更改返回类型或函数签名
  • 修改共享工具类但未检查所有使用场景
  • 移除验证或检查逻辑
  • 更改其他代码可能依赖的默认值

3. Maintainability & Evolvability

3. 可维护性与可演进性

Assess long-term code health:
  • Structure: Is code better organized (extracted functions, clearer modules)?
  • Complexity: Is cyclomatic complexity reduced?
  • Coupling: Are dependencies reduced or better managed?
  • Testability: Is code easier to test (pure functions, dependency injection)?
  • Documentation: Are complex parts documented?
  • Patterns: Are established patterns followed consistently?
Signs of improvement:
  • Extracting reusable utilities
  • Reducing nested conditionals
  • Breaking large functions into smaller ones
  • Using consistent naming conventions
  • Following project architecture patterns
评估代码的长期健康状况：
  • 结构：代码组织是否更合理（如提取函数、模块更清晰）？
  • 复杂度：圈复杂度是否降低？
  • 耦合度：依赖关系是否减少或管理更得当？
  • 可测试性：代码是否更易于测试（如纯函数、依赖注入）？
  • 文档：复杂部分是否有文档说明？
  • 模式：是否始终遵循已确立的设计模式？
改进迹象：
  • 提取可复用的工具类
  • 减少嵌套条件判断
  • 将大型函数拆分为更小的函数
  • 使用一致的命名规范
  • 遵循项目架构模式

4. Readability

4. 可读性

Evaluate code clarity:
  • Naming: Are variables, functions, and types clearly named?
  • Structure: Is code flow easy to follow?
  • Comments: Are comments helpful (explain "why", not "what")?
  • Formatting: Is code consistently formatted?
  • Magic numbers: Are constants extracted and named?
Signs of improvement:
  • More descriptive variable names
  • Reduced nesting levels
  • Clearer control flow
  • Better type annotations
  • Consistent code style
评估代码的清晰度：
  • 命名：变量、函数和类型的命名是否清晰？
  • 结构：代码流程是否易于理解？
  • 注释：注释是否有帮助（解释“为什么”而非“是什么”）？
  • 格式：代码格式是否一致？
  • 魔法值：是否提取常量并命名？
改进迹象：
  • 变量命名更具描述性
  • 嵌套层级减少
  • 控制流程更清晰
  • 类型注解更完善
  • 代码风格一致

Common Patterns to Check

需检查的常见模式

Refactoring Patterns

重构模式

Good refactoring:
  • Extract function → Verify all call sites updated
  • Rename variable → Verify all references updated
  • Move code → Verify imports and dependencies updated
Risky refactoring:
  • Changing shared utilities without checking all usages
  • Modifying type definitions without updating consumers
  • Removing "unused" code that might be used dynamically
良好的重构：
  • 提取函数 → 验证所有调用点已更新
  • 重命名变量 → 验证所有引用已更新
  • 移动代码 → 验证导入和依赖已更新
高风险重构：
  • 修改共享工具类但未检查所有使用场景
  • 修改类型定义但未更新所有使用方
  • 移除看似“未使用”但可能被动态调用的代码

Code Quality Improvements

代码质量改进

Verify improvements are real:
  • Not just moving code around
  • Actually reducing complexity
  • Actually improving readability
  • Making code more testable, not just prettier
验证是否为真正的改进：
  • 不只是简单地移动代码
  • 确实降低了复杂度
  • 确实提升了可读性
  • 使代码更易于测试，而非仅仅更美观

Readability Improvements

可读性改进

Ensure clarity gains:
  • Names are actually more descriptive
  • Structure is genuinely easier to follow
  • Comments add value, not noise
确保获得清晰度提升：
  • 命名确实更具描述性
  • 结构确实更易于理解
  • 注释增加了价值，而非冗余信息

When to Flag Issues

何时标记问题

Flag changes if:
  • Critical: Changes break existing functionality or introduce bugs
  • Warning: Changes might cause issues or reduce maintainability
  • Suggestion: Changes could be improved but aren't problematic
Provide specific examples from the diff when flagging issues.
出现以下情况时标记变更：
  • 严重问题：变更破坏现有功能或引入Bug
  • 警告：变更可能引发问题或降低可维护性
  • 建议：变更可优化但无严重问题
标记问题时，请提供diff中的具体示例。