gitlab-mr-review

GitLab 合并请求审查

对 GitLab 合并请求进行代码审查。获取 MR 数据时优先使用 glab MCP；MCP 不可用时使用 glab CLI。

---

仓库和 MR 定位

默认仓库

• 默认情况： 假定 GitLab 项目与当前项目名称相同（例如工作区或仓库目录名称）。
• 如果当前目录是 Git 仓库，且配置了 GitLab 远程仓库，则尽可能据此推断 namespace/project。

仓库缺失或不正确时

如果符合以下任一情况：

• 当前目录不是 Git 仓库，或
• 没有 GitLab 远程仓库，或
• 要审查的 MR 属于其他项目，

则询问用户以下信息：

• 仓库： GitLab 项目路径（namespace/project 或完整路径），或仓库 URL。
• MR： 合并请求 IID（例如 42）或分支名称（如果不是当前分支）。

不要猜测仓库；确认默认情况不适用或无法确定后，询问一次即可。

---

工作流

1. 定位仓库
   • 使用默认仓库（项目名称／当前 GitLab 远程仓库）。
   • 如果仓库不可用或不是目标仓库，询问用户仓库（必要时也询问 MR）。
2. 定位 MR
   • 优先使用当前分支对应的合并请求。
   • 如果用户指定了 MR IID 或分支，则使用该信息。
   • 如果无法确定，则询问 MR IID 或分支。
3. 获取 MR 数据
   • MCP： 使用 glab MCP 工具获取 MR 详情和差异（例如查看 MR、获取差异）。
   • CLI： glab mr view [MR_IID] 和 glab mr diff [MR_IID]（如果当前分支对应的 MR 已在上下文中，则省略 MR_IID）。
   • 审查前确保已获取完整差异、标题和描述。
4. 进行审查
   • 分析差异，检查以下方面：
     • 正确性和逻辑
     • 安全性和数据处理
     • 风格、命名和结构
     • 测试和边界情况
     • 相关文档和注释
   • 输出简洁的审查结果：摘要、问题列表（注明文件／行号或差异片段上下文）以及建议。
5. 可选：作为 MR 评论发布
   • 仅在用户确认后执行。 在用户明确同意之前，不要向 GitLab 发布任何内容。
   • MCP： 使用工具添加评论（例如 MR 备注），并填写审查内容。
   • CLI： 使用 glab mr note [MR_IID] --message "..."，并正确转义或引用评论内容。

---

获取 MR 数据

• MCP： 使用可用的 glab MCP 工具执行以下操作：
  • 列出或获取当前／指定的 MR
  • 获取 MR 差异
• CLI（在已通过 glab 认证的仓库中）：
  • glab mr view：查看当前分支对应的 MR（或使用 glab mr view <IID>）
  • glab mr diff：查看当前分支对应 MR 的差异（或使用 glab mr diff <IID>）
  • 如果仓库不同：使用 glab mr view -R namespace/project <IID> 和 glab mr diff -R namespace/project <IID>

---

审查输出格式

1. 摘要： 用 2–4 句话说明 MR 的作用和整体评估。
2. 问题： 按严重程度或类别分组（例如“阻塞问题”“建议”“小问题”）。
   • 每项注明文件（尽可能标出行号／差异片段）、问题以及建议的修改或需要确认的问题。
3. 结论： 批准／附带评论批准／要求修改（或同等表述），并列出后续步骤（如有）。

确保审查结果可执行：清晰、具体，并与差异直接相关。

---

检查清单

• 已定位仓库（默认使用项目名称；否则已询问用户仓库）
• 已定位 MR（当前分支对应的 MR，或用户指定的 IID／分支）
• 已获取 MR 详情和完整差异（通过 MCP 或 CLI）
• 已撰写包含摘要、带上下文的问题和结论的审查结果
• 如需发布评论：已获得用户确认，然后使用 MCP 或 glab mr note