Back to Details

gitlab-code-review

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

GitLab Code Review

GitLab 代码审查

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

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
  • 所有项目标识符、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」来审查指定的merge request
  • 用户输入「review ISSUE-ID」（例如「review #456」）来审查关联GitLab issue的MR
  • 用户提出审查merge request的需求
  • 合并分支前分析代码变更
  • 开展代码质量评估
  • 排查安全漏洞或性能问题
  • 审查merge request的diff内容

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
重要提示：审查merge request前务必确认project_id
所有反馈都应以提问形式给出，而非指令性内容
仅审查该merge request引入的变更，不要评论无关代码

Workflow

工作流

1. Identify the Merge Request

1. 识别Merge Request

Merge Request IID Provided

已提供Merge Request 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>
如果用户提供了merge request IID（例如「review !123」或「review MR 123」）：
  1. 从用户输入中提取MR IID
  2. 确认项目上下文（如果不明确可询问用户）
  3. 使用
    glab mr view <iid>
    获取merge request详情

GitLab Issue ID Provided

已提供GitLab Issue 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 issue ID（例如「review #456」）：
  1. 使用
    glab issue view <iid>
    获取issue详情，了解上下文
  2. 使用
    glab mr list --search "<issue reference>"
    查找关联的merge requests
  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
    列出最近的开放merge requests
  2. 将列表展示给用户
  3. 询问用户选择要审查的MR

2. Gather Merge Request Context

2. 收集Merge Request上下文

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对比的
    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>
获取以下内容：
  • 变更文件列表
  • 每个文件的新增和删除行数
  • 每个文件的diff内容
分页处理：如果变更文件较多，diff输出可能很大，可分区块审查。

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.
仅针对本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注入、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. 向Merge Request添加评论（可选）

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
    ：包含diff位置详情的对象： 
    • 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?"
❌ 错误写法：
  • "你应该在这里使用提前返回"
  • "这里需要加错误处理"
  • "把这部分抽成单独的函数"
  • "加个空值校验"
✅ 正确写法：
  • "这里用提前返回是不是可以简化逻辑？"
  • "如果这个API调用失败会发生什么？在这里加错误处理会不会更好？"
  • "为了复用性，把这部分抽成独立的函数是不是更合理？"
  • "有没有场景下这个值可能为null？如果有的话我们应该怎么处理？"

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：审查指定Merge Request

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：审查关联Issue的MR

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
  • 仅审查本merge request的变更内容 - 不要评论未被修改的代码
  • 以提问形式呈现反馈，促进对话
  • 反馈要具备建设性和明确性
  • 为建议的优化方案提供代码示例
  • 肯定做得好的实践和改进点
  • 清晰划分问题优先级（严重 > 重要 > 建议）
  • 考虑变更的上下文和目标
  • 得出审查结论前检查流水线状态
  • 审查现有讨论避免重复反馈
  • 向MR添加评论前务必询问用户
  • 如果MR关联了issue，需确认审查覆盖了验收标准