Back to Details

code-review

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Code Review

代码审查

Perform comprehensive code reviews of GitLab merge requests, providing actionable feedback on code quality, security, performance, and best practices.
对GitLab合并请求进行全面的代码审查，针对代码质量、安全性、性能和最佳实践提供可落地的反馈。

Prerequisites

前置要求

GitLab Instance Configuration

GitLab实例配置

This skill is configured for a self-hosted GitLab instance:
  • GitLab URL: https://gitlab-erp-pas.dedalus.lan
  • All project identifiers, URLs, and references should use this self-hosted instance
  • Ensure you have appropriate access credentials configured for this GitLab server
本技能适配自托管GitLab实例：
  • GitLab URL: https://gitlab-erp-pas.dedalus.lan
  • 所有项目ID、URL和引用都应使用该自托管实例
  • 请确保你已为该GitLab服务器配置了合适的访问凭证

When to Use This Skill

何时使用该技能

Activate this skill when:
  • The user types "review" or "code review" (with or without slash command)
  • The user types "review MR-123" or "review !123" to review a specific merge request
  • The user types "review ISSUE-ID" (e.g., "review #456") to review the MR associated with a GitLab issue
  • The user asks to review a merge request
  • Analyzing code changes before merging
  • Performing code quality assessments
  • Checking for security vulnerabilities or performance issues
  • Reviewing merge request diffs
在以下场景激活该技能：
  • 用户输入"review"或"code review"（带或不带斜杠命令均可）
  • 用户输入"review MR-123"或"review !123"以审查特定合并请求
  • 用户输入"review ISSUE-ID"（例如"review #456"）以审查关联GitLab议题的合并请求
  • 用户要求审查某个合并请求
  • 合并前分析代码变更
  • 开展代码质量评估
  • 检查安全漏洞或性能问题
  • 审查合并请求差异

Critical Rules

核心规则

IMPORTANT: Always confirm project_id before reviewing merge requests
Always provide constructive feedback framed as questions, not directives
Only review changes introduced in the merge request, not unrelated code
重要提示：审查合并请求前必须确认project_id
反馈必须采用提问的建设性表达，而非指令
仅审查合并请求引入的变更，不要评论无关代码

Workflow

工作流

1. Identify the Merge Request

1. 识别合并请求

Merge Request IID Provided

提供了合并请求IID

If a merge request IID is provided (e.g., "review !123" or "review MR 123"):
  1. Extract the MR IID from the user input
  2. Verify the project context (ask user if not clear)
  3. Fetch merge request details using 
    glab mr view <iid>
如果用户提供了合并请求IID（例如"review !123"或"review MR 123"）：
  1. 从用户输入中提取MR IID
  2. 确认项目上下文（如果不明确请询问用户）
  3. 使用
    glab mr view <iid>
    获取合并请求详情

GitLab Issue ID Provided

提供了GitLab议题ID

If a GitLab issue ID is provided (e.g., "review #456"):
  1. Fetch issue details using 
    glab issue view <iid>
    to understand context
  2. Find related merge requests using 
    glab mr list --search "<issue reference>"
  3. If multiple MRs found, ask user to select the one to review
  4. Proceed with the selected MR
如果用户提供了GitLab议题ID（例如"review #456"）：
  1. 使用
    glab issue view <iid>
    获取议题详情以理解上下文
  2. 使用
    glab mr list --search "<issue reference>"
    查找关联的合并请求
  3. 如果找到多个MR，请让用户选择要审查的那一个
  4. 继续处理选中的MR

No Specific MR Provided

未指定具体MR

If no MR is specified (e.g., just "review"):
  1. List recent open merge requests using 
    glab mr list --state opened
  2. Present the list to the user
  3. Ask user to select which MR to review
如果用户未指定MR（例如仅输入"review"）：
  1. 使用
    glab mr list --state opened
    列出近期打开的合并请求
  2. 将列表展示给用户
  3. 询问用户要审查哪个MR

2. Gather Merge Request Context

2. 收集合并请求上下文

Self-hosted GitLab Instance: https://gitlab-erp-pas.dedalus.lan
Use 
glab mr view <iid>
to retrieve:
  • Title and description
  • Source and target branches
  • Author information
  • State (open, merged, closed)
  • Labels and milestones
  • Approval status
  • Pipeline status
  • diff_refs
    (base_sha, head_sha, start_sha) for accurate diff comparison
Extract key information:
Project: namespace/project
MR: !123 - "Feature: Add user authentication"
Author: @username
Source: feature/auth -> Target: main
Status: Open | Pipeline: Passed | Approvals: 1/2
自托管GitLab实例： https://gitlab-erp-pas.dedalus.lan
使用
glab mr view <iid>
获取以下信息：
  • 标题和描述
  • 源分支和目标分支
  • 作者信息
  • 状态（打开、已合并、已关闭）
  • 标签和里程碑
  • 审批状态
  • 流水线状态
  • 用于精准差异对比的
    diff_refs
    （base_sha、head_sha、start_sha）
提取核心信息：
Project: namespace/project
MR: !123 - "Feature: Add user authentication"
Author: @username
Source: feature/auth -> Target: main
Status: Open | Pipeline: Passed | Approvals: 1/2

3. Analyze the Changes

3. 分析变更

Get File Changes

获取文件变更

Use 
glab mr diff <iid>
to retrieve:
  • List of changed files
  • Additions and deletions per file
  • Diff content for each file
Pagination: If many files changed, the diff output may be large — review it in sections.
使用
glab mr diff <iid>
获取：
  • 变更文件列表
  • 每个文件的新增和删除行数
  • 每个文件的差异内容
分页说明：如果变更文件很多，差异输出可能会很大——请分块审查。

Get Detailed File Content

获取文件详细内容

For complex changes, use 
git show <ref>:<file_path>
to:
  • View the complete file context
  • Understand surrounding code
  • Check for consistency with existing patterns
Parameters:
  • <ref>
    : Use the source branch or head_sha from diff_refs
  • <file_path>
    : Path to the file
对于复杂变更，使用
git show <ref>:<file_path>
来：
  • 查看完整的文件上下文
  • 理解周边代码
  • 检查是否与现有模式保持一致
参数说明：
  • <ref>
    ：使用源分支或diff_refs中的head_sha
  • <file_path>
    ：文件路径

Analyze Commits

分析提交

Use 
git log --oneline <source_branch>
to list commits, then use 
git show <sha>
to:
  • Understand commit history
  • Review individual commit changes
  • Check commit message quality
使用
git log --oneline <source_branch>
列出提交，然后使用
git show <sha>
来：
  • 理解提交历史
  • 审查单条提交的变更
  • 检查提交信息质量

4. Check Existing Discussions

4. 检查现有讨论

Use 
glab api /projects/:id/merge_requests/:iid/discussions
to:
  • Review existing feedback and discussions
  • Avoid duplicate comments
  • Understand ongoing conversations
  • Check for unresolved threads
使用
glab api /projects/:id/merge_requests/:iid/discussions
来：
  • 审查现有反馈和讨论
  • 避免重复评论
  • 理解正在进行的对话
  • 检查未解决的线程

5. Check Pipeline Status

5. 检查流水线状态

Use 
glab ci list
and 
glab ci view <pipeline_id>
to:
  • Verify CI/CD pipeline status
  • Check for failed jobs
  • Review test results
If pipeline failed, use 
glab ci trace <job_id>
to understand failures.
使用
glab ci list
和
glab ci view <pipeline_id>
来：
  • 验证CI/CD流水线状态
  • 检查失败的任务
  • 审查测试结果
如果流水线失败，使用
glab ci trace <job_id>
了解失败原因。

6. Perform Comprehensive Code Review

6. 开展全面代码审查

Conduct a thorough review of only the changes introduced in this merge request.
仅对本合并请求引入的变更进行彻底审查。

Code Quality Assessment

代码质量评估

  • Code style and formatting consistency
  • Variable and function naming conventions
  • Code organization and structure
  • Adherence to DRY (Don't Repeat Yourself) principles
  • Proper abstraction levels
  • 代码风格和格式一致性
  • 变量和函数命名规范
  • 代码组织和结构
  • 遵守DRY（Don't Repeat Yourself）原则
  • 合理的抽象层级

Technical Review

技术审查

  • Logic correctness and edge cases
  • Error handling and validation
  • Performance implications
  • Security considerations (input validation, SQL injection, XSS, etc.)
  • Resource management (memory leaks, connection handling)
  • Concurrency issues if applicable
  • 逻辑正确性和边界场景处理
  • 错误处理和校验
  • 性能影响
  • 安全考量（输入校验、SQL injection、XSS等）
  • 资源管理（内存泄漏、连接处理）
  • 适用场景下的并发问题

Best Practices Check

最佳实践检查

  • Design patterns usage
  • SOLID principles adherence
  • Testing coverage implications
  • Documentation completeness
  • API consistency
  • Backwards compatibility
  • 设计模式使用
  • 遵守SOLID原则
  • 测试覆盖率影响
  • 文档完整性
  • API一致性
  • 向后兼容性

Dependencies and Integration

依赖和集成

  • New dependencies added
  • Breaking changes to existing interfaces
  • Impact on other parts of the system
  • Database migration requirements
  • 新增的依赖
  • 对现有接口的破坏性变更
  • 对系统其他部分的影响
  • 数据库迁移要求

7. Generate Review Report

7. 生成审查报告

Create a structured code review report with:
  1. Executive Summary: High-level overview of changes and overall assessment
  2. Statistics:
    • Files changed, lines added/removed
    • Commits reviewed
    • Critical issues found
  3. Strengths: What was done well
  4. Issues by Priority:
    • 🔴 Critical: Must fix before merging (bugs, security issues)
    • 🟡 Important: Should address (performance, maintainability)
    • 🟢 Suggestions: Nice to have improvements
  5. Detailed Findings: For each issue include:
    • File and line reference
    • A question framing the concern
    • Context explaining why you're asking
    • Code example if helpful
  6. Security Review: Specific security considerations
  7. Performance Review: Performance implications
  8. Testing Recommendations: What tests should be added
  9. Documentation Needs: What documentation should be updated
创建结构化的代码审查报告，包含以下内容：
  1. 执行摘要：变更的高层概览和整体评估
  2. 统计信息：
    • 变更文件数、新增/删除行数
    • 审查的提交数
    • 发现的严重问题数
  3. 亮点：做得好的地方
  4. 按优先级划分的问题：
    • 🔴 严重：合并前必须修复（缺陷、安全问题）
    • 🟡 重要：应该处理（性能、可维护性问题）
    • 🟢 建议：可优化的改进点
  5. 详细发现：每个问题包含：
    • 文件和行号引用
    • 以提问方式表达的关注点
    • 解释你提出该问题的上下文
    • 如有帮助可附上代码示例
  6. 安全审查：具体的安全考量
  7. 性能审查：性能影响
  8. 测试建议：需要新增的测试
  9. 文档需求：需要更新的文档

8. Add Comments to Merge Request (Optional)

8. 向合并请求添加评论（可选）

CRITICAL: Ask user before adding comments to the MR
If user wants to add feedback directly to the MR:
重要提示：向MR添加评论前必须征得用户同意
如果用户希望直接将反馈添加到MR：

General Comment

通用评论

Use 
glab mr note <iid> --message "<comment>"
to add a general comment:
  • <iid>
    : MR internal ID
  • <comment>
    : Comment content in Markdown
使用
glab mr note <iid> --message "<comment>"
添加通用评论：
  • <iid>
    ：MR内部ID
  • <comment>
    ：Markdown格式的评论内容

Line-Specific Discussion

行级讨论

Use 
glab api POST /projects/:id/merge_requests/:iid/discussions
for code-specific feedback with:
  • body
    : Discussion content
  • position
    : Object with diff position details: 
    • base_sha
      : From diff_refs
    • head_sha
      : From diff_refs
    • start_sha
      : From diff_refs
    • new_path
      : File path
    • new_line
      : Line number for new code
    • old_path
      : File path (for modifications)
    • old_line
      : Line number for removed code
使用
glab api POST /projects/:id/merge_requests/:iid/discussions
添加代码特定的反馈，参数如下：
  • body
    ：讨论内容
  • position
    ：包含差异位置详情的对象： 
    • base_sha
      ：来自diff_refs
    • head_sha
      ：来自diff_refs
    • start_sha
      ：来自diff_refs
    • new_path
      ：文件路径
    • new_line
      ：新代码的行号
    • old_path
      ：文件路径（针对修改内容）
    • old_line
      ：被删除代码的行号

Feedback Style: Questions, Not Directives

反馈风格：提问而非指令

Frame all feedback as questions, not commands. This encourages dialogue and respects the author's context.
所有反馈都要以提问的形式表达，不要使用命令式语气。 这样可以鼓励对话，尊重作者的上下文。

Examples

示例

❌ Don't write:
  • "You should use early returns here"
  • "This needs error handling"
  • "Extract this into a separate function"
  • "Add a null check"
✅ Do write:
  • "Could this be simplified with an early return?"
  • "What happens if this API call fails? Would error handling help here?"
  • "Would it make sense to extract this into its own function for reusability?"
  • "Is there a scenario where this could be null? If so, how should we handle it?"
❌ 错误写法：
  • "You should use early returns here"
  • "This needs error handling"
  • "Extract this into a separate function"
  • "Add a null check"
✅ 正确写法：
  • "Could this be simplified with an early return?"
  • "What happens if this API call fails? Would error handling help here?"
  • "Would it make sense to extract this into its own function for reusability?"
  • "Is there a scenario where this could be null? If so, how should we handle it?"

Why Questions Work Better

为什么提问效果更好

  • The author may have context you don't have
  • Questions invite explanation rather than defensiveness
  • They acknowledge uncertainty in the reviewer's understanding
  • They create a conversation rather than a checklist
  • 作者可能拥有你不了解的上下文
  • 提问会鼓励解释而非抵触
  • 承认审查者的理解可能存在不确定性
  • 创造对话而非单向检查清单

Review Report Template

审查报告模板

markdown
undefined
markdown
undefined

Code Review: !{MR_IID} - {MR_TITLE}

Code Review: !{MR_IID} - {MR_TITLE}

Executive Summary

Executive Summary

{Brief overview of changes and overall assessment}
{Brief overview of changes and overall assessment}

Merge Request Details

Merge Request Details

  • Project: {project_path}
  • Author: @{author}
  • Source Branch: {source_branch} → Target: {target_branch}
  • Pipeline Status: {status}
  • Approvals: {current}/{required}
  • Project: {project_path}
  • Author: @{author}
  • Source Branch: {source_branch} → Target: {target_branch}
  • Pipeline Status: {status}
  • Approvals: {current}/{required}

Statistics

Statistics

MetricCount
Files Changed{count}
Lines Added+{additions}
Lines Removed-{deletions}
Commits{commit_count}
MetricCount
Files Changed{count}
Lines Added+{additions}
Lines Removed-{deletions}
Commits{commit_count}

Strengths

Strengths

  • {strength_1}
  • {strength_2}
  • {strength_1}
  • {strength_2}

Issues Found

Issues Found

🔴 Critical

🔴 Critical

{critical_issues_or_none}
{critical_issues_or_none}

🟡 Important

🟡 Important

{important_issues_or_none}
{important_issues_or_none}

🟢 Suggestions

🟢 Suggestions

{suggestions_or_none}
{suggestions_or_none}

Security Review

Security Review

{security_findings}
{security_findings}

Performance Review

Performance Review

{performance_findings}
{performance_findings}

Testing Recommendations

Testing Recommendations

  • {test_recommendation_1}
  • {test_recommendation_2}
  • {test_recommendation_1}
  • {test_recommendation_2}

Documentation Needs

Documentation Needs

  • {doc_need_1}
  • {doc_need_1}

Verdict

Verdict

{APPROVED | CHANGES_REQUESTED | NEEDS_DISCUSSION}
undefined
{APPROVED | CHANGES_REQUESTED | NEEDS_DISCUSSION}
undefined

Examples

示例

Example 1: Review a Specific Merge Request

示例1：审查特定合并请求

User: Review !42 in namespace/project

Assistant actions:
1. glab mr view 42 — fetch MR details
2. glab mr diff 42 — get file changes
3. glab api /projects/:id/merge_requests/42/discussions — check existing feedback
4. glab ci list — check CI status
5. Analyze changes and generate report
6. Present review to user
7. Ask if user wants comments added to the MR
User: Review !42 in namespace/project

Assistant actions:
1. glab mr view 42 — fetch MR details
2. glab mr diff 42 — get file changes
3. glab api /projects/:id/merge_requests/42/discussions — check existing feedback
4. glab ci list — check CI status
5. Analyze changes and generate report
6. Present review to user
7. Ask if user wants comments added to the MR

Example 2: Review MR Related to an Issue

示例2：审查关联议题的合并请求

User: Review the MR for issue #123

Assistant actions:
1. glab issue view 123 — fetch issue details
2. glab mr list --search "#123" — find related MRs
3. Present found MRs and ask user to confirm
4. Proceed with code review workflow
User: Review the MR for issue #123

Assistant actions:
1. glab issue view 123 — fetch issue details
2. glab mr list --search "#123" — find related MRs
3. Present found MRs and ask user to confirm
4. Proceed with code review workflow

Example 3: List Open MRs for Review

示例3：列出待审查的打开MR

User: Show me open merge requests to review

Assistant actions:
1. glab mr list --state opened — list open MRs
2. Present list with key details (title, author, pipeline status)
3. Ask user which MR to review
User: Show me open merge requests to review

Assistant actions:
1. glab mr list --state opened — list open MRs
2. Present list with key details (title, author, pipeline status)
3. Ask user which MR to review

Important Notes

重要注意事项

  • Only review changes from THIS merge request - do not comment on code that wasn't changed
  • Frame feedback as questions to encourage dialogue
  • Be constructive and specific in feedback
  • Provide code examples for suggested improvements
  • Acknowledge good practices and improvements
  • Prioritize issues clearly (Critical > Important > Suggestions)
  • Consider the context and purpose of changes
  • Check pipeline status before concluding review
  • Review existing discussions to avoid duplicate feedback
  • Always ask before adding comments to the MR
  • Verify the review addresses acceptance criteria if linked to an issue
  • 仅审查本合并请求的变更 - 不要评论未修改的代码
  • 反馈采用提问形式以鼓励对话
  • 反馈要有建设性、具体明确
  • 为建议的改进提供代码示例
  • 认可好的实践和改进
  • 明确划分问题优先级（严重 > 重要 > 建议）
  • 考虑变更的上下文和目的
  • 得出审查结论前检查流水线状态
  • 审查现有讨论避免重复反馈
  • 向MR添加评论前必须征得用户同意
  • 如果关联了议题，要确认审查覆盖了验收标准