GitLab Code Review 是一项用于对 GitLab 合并请求（Merge Request）进行完整代码审查的技能，围绕代码质量、安全、性能和最佳实践提供可操作的反馈。
适用场景与触发方式
当用户输入 "review" 或 "code review"（可带或不带斜杠命令）时激活；输入 "review MR-123" 或 "review !123" 可审查指定合并请求；输入 "review ISSUE-ID"（例如 "review #456"）可审查与某个 GitLab issue 关联的 MR；也可用于合并前的代码变更分析、代码质量评估、安全漏洞或性能问题检查，以及审查合并请求差异。
实例配置
该技能针对自托管 GitLab 实例配置：GitLab URL 为 https://gitlab-erp-pas.dedalus.lan。所有项目标识符、URL 和引用都应使用此自托管实例，并需确保已为该 GitLab 服务器配置适当的访问凭据。
关键规则
审查合并请求前始终确认 project_id；始终以问题而非指令的形式提供建设性反馈；仅审查本次合并请求引入的变更，不评论无关代码。
工作流程
第一步，识别合并请求。若提供了 MR IID（如 "review !123"），从输入中提取 IID，验证项目上下文（不明确时询问用户），使用 glab mr view <iid> 获取合并请求详情。若提供了 GitLab issue ID（如 "review #456"），使用 glab issue view <iid> 了解上下文，通过 glab mr list --search "<issue reference>" 查找相关合并请求；若找到多个，请用户选择要审查的那个。若未指定 MR（如仅输入 "review"），使用 glab mr list --state opened 列出最近开放的合并请求，呈现给用户并请其选择。
第二步，收集合并请求上下文。使用 glab mr view <iid> 获取标题与描述、源分支与目标分支、作者信息、状态（open、merged、closed）、标签与里程碑、审批状态、流水线状态，以及用于准确差异比较的 diff_refs（base_sha、head_sha、start_sha）。提取关键信息，如项目 namespace/project、MR 编号与标题、作者、源分支到目标分支、状态、流水线与审批情况。
第三步，分析变更。使用 glab mr diff <iid> 获取变更文件列表、每个文件的增删行数以及各文件的差异内容；若变更文件较多，差异输出可能很大，应分段审查。对于复杂变更，使用 git show <ref>:<file_path> 查看完整文件上下文、理解周边代码并检查与现有模式的一致性，其中 <ref> 使用源分支或 diff_refs 中的 head_sha，<file_path> 为文件路径。使用 git log --oneline <source_branch> 列出提交，再以 git show <sha> 了解提交历史、审查单个提交变更并检查提交信息质量。
第四步，检查既有讨论。使用 glab api /projects/:id/merge_requests/:iid/discussions 查看已有反馈与讨论，避免重复评论，了解正在进行的对话，并检查未解决的线程。
第五步，检查流水线状态。使用 glab ci list 与 glab ci view <pipeline_id> 验证 CI/CD 流水线状态、检查失败任务并审阅测试结果；若流水线失败，使用 glab ci trace <job_id> 了解失败原因。
第六步，执行全面代码审查（仅针对本次合并请求引入的变更）。代码质量评估包括代码风格与格式一致性、变量与函数命名约定、代码组织与结构、DRY 原则遵循情况、抽象层级是否恰当。技术审查包括逻辑正确性与边界情况、错误处理与验证、性能影响、安全考量（输入验证、SQL 注入、XSS 等）、资源管理（内存泄漏、连接处理）以及并发问题（如适用）。最佳实践检查包括设计模式使用、SOLID 原则遵循、测试覆盖影响、文档完整性、API 一致性、向后兼容性。依赖与集成方面检查新增依赖、现有接口的破坏性变更、对系统其他部分的影响、数据库迁移需求。
第七步，生成审查报告。报告包含执行摘要（变更的高层概述与总体评估）、统计信息（变更文件数、增删行数、审查的提交数、发现的严重问题数）、优点（做得好的地方）、按优先级分类的问题（🔴 Critical 合并前必须修复：缺陷、安全问题；🟡 Important 应当处理：性能、可维护性；🟢 Suggestions 可选改进）、详细发现（每个问题包含文件与行号引用、以问题形式表述的关切、解释为何提问的上下文、有帮助时的代码示例）、安全审查、性能审查、测试建议与文档需求。报告模板包含结论选项：APPROVED、CHANGES_REQUESTED 或 NEEDS_DISCUSSION。
第八步，可选地向合并请求添加评论。关键点：向 MR 添加评论前必须先询问用户。若用户希望直接添加反馈：一般评论使用 glab mr note <iid> --message "<comment>"，其中 <iid> 为 MR 内部 ID，<comment> 为 Markdown 格式的评论内容；行级讨论使用 glab api POST /projects/:id/merge_requests/:iid/discussions，包含 body（讨论内容）与 position 对象（含 base_sha、head_sha、start_sha 均来自 diff_refs，new_path 文件路径、new_line 新代码行号、old_path 文件路径、old_line 被删除代码行号）。
反馈风格：提问而非指令
所有反馈以问题而非命令形式表述，以鼓励对话并尊重作者的上下文。例如，不要写 "You should use early returns here" 或 "This needs error handling"，而应写 "Could this be simplified with an early return?" 或 "What happens if this API call fails? Would error handling help here?"。以问题表述更有效的原因包括：作者可能拥有你不了解的上下文；问题引发解释而非防御心理；承认审查者理解上的不确定性；创造对话而非清单。
使用示例
示例一：审查特定合并请求。用户输入 "Review !42 in namespace/project"，执行动作依次为 glab mr view 42 获取 MR 详情、glab mr diff 42 获取文件变更、glab api /projects/:id/merge_requests/42/discussions 检查已有反馈、glab ci list 检查 CI 状态、分析变更并生成报告、向用户呈现审查结果、询问是否将评论添加到 MR。
示例二：审查与 issue 相关的 MR。用户输入 "Review the MR for issue #123"，执行动作依次为 glab issue view 123 获取 issue 详情、glab mr list --search "#123" 查找相关 MR、呈现找到的 MR 并请用户确认、继续执行代码审查工作流。
示例三：列出待审查的开放 MR。用户输入 "Show me open merge requests to review"，执行动作依次为 glab mr list --state opened 列出开放 MR、呈现包含关键信息（标题、作者、流水线状态）的列表、询问用户要审查哪个 MR。
重要注意事项
仅审查本次合并请求的变更，不评论未更改的代码；以问题形式表述反馈以鼓励对话；反馈应建设性且具体；为建议的改进提供代码示例；认可良好实践与改进；清晰区分问题优先级（Critical > Important > Suggestions）；考虑变更的上下文与目的；在得出结论前检查流水线状态；审查既有讨论以避免重复反馈；添加评论到 MR 前始终先询问；若关联到 issue，确认审查是否满足验收标准。