GitLab MR Reviewer

GitLab MR 审查调度层技能。只定义触发条件、执行顺序、硬规则和失败回退；命令细节与长参考统一放到 references/。

适用场景

• 用户明确提到 GitLab MR 审查，例如：审核 MR #42、检查合并请求 42
• 需要对 MR 发布行内评论、总结评论、approve 或 request changes
• 需要在审查后发送飞书通知
• 需要对 MR 做静态分析或 AI 深审（在配置允许时）

不适用场景

• GitHub PR 审查（非 GitLab）
• 纯本地代码评审且用户明确不希望与 GitLab 交互
• 缺少最小配置且用户不希望先做初始化

执行前检查清单（Preflight）

执行前必须确认（配置优先从 reviewer.config.json 读取，其次才是环境变量）：

• 工具可用：git、glab、python
• 配置齐全：gitlab.projectId、review.repoPath、gitlab.defaultBaseBranch
• 主机格式一致：gitlab.host 统一使用主机名（例如 gitlab.example.com，不带协议）
• 已认证：glab auth status 可通过，或存在有效 GITLAB_TOKEN
• 当前任务目标明确：仅审查 / 审查并评论 / 审查并通知 / approve
• 配置读取来源：统一以 reviewer.config.json 为准（不要依赖环境变量回填）

缺少最小配置时，先停下并向用户追问，不得猜测 project id、host、repo path。

核心工作流

1. 同步仓库：进入 REVIEW_REPO_PATH 并执行 git fetch --all --prune
2. 切换 MR：优先 glab mr checkout <MR_ID>
3. 运行分析：执行 scripts/mr_analyzer.py 生成 JSON 结果
4. 生成结论：根据严重级别与置信度，得出 approve 或 request_changes
5. 发布评论：
   • 有有效文件与行号 -> scripts/gitlab_inline_commenter.py
   • 无法定位行号 -> 回退为 MR 总结评论
6. 需要通知时：执行 scripts/feishu_notifier.py

Webhook 触发语义（强制）

• 任何 System Hook GitLab / webhook 自动触发，默认等价于：审核 MR #<id> 并通知飞书
• webhook 触发不是“仅分析”模式，必须执行完整闭环：
  1. 完成 MR 审查并生成结论
  2. 发布 GitLab 审查结果（优先行内评论，失败回退总结评论）
  3. 发送飞书通知
  4. 返回发送回执（gitlab_publish / feishu_notify 的 success|fail 与失败原因）
• 不允许只输出审查结论而不执行发送动作
• 飞书配置缺失时必须显式报错，不允许静默跳过
• GitLab 发布必须走脚本 API 路径（scripts/gitlab_inline_commenter.py），不要直接用终端文本粘贴 glab mr note
• 同一次 webhook 任务只允许 1 条总结评论，禁止重复发布
• 发布文本必须是 UTF-8 中文可读，禁止乱码评论

硬规则

• 永远先静态分析，再决定是否做 AI 深审
• 审查结论、行内评论、总结报告必须使用中文
• 允许简化的是 skill 的表达风格，不允许简化审查结果与报告结构
• 不泄露任何 secret（如 GITLAB_TOKEN、FEISHU_WEBHOOK_URL）
• confidence < 0.6 不下结论，改为提问式评论
• 单个问题只评论一次，避免重复刷屏
• 行号缺失或定位失败时，必须降级为 summary note
• 大 MR 优先审查高风险文件，不做无边界全量深审
• 检测到 notifications.feishuWebhookUrl 已配置时，默认执行飞书通知；除非用户明确要求不通知
• webhook 自动触发时，默认执行 GitLab 发布 + 飞书通知；除非用户在指令中明确禁止

失败回退顺序（必须按顺序）

1. glab mr checkout 失败 -> 检查 glab version、认证、host
2. 仍失败 -> 使用 git fetch origin merge-requests/<MR_ID>/head:mr-<MR_ID> + git checkout
3. mr_analyzer.py 显示无 diff -> 校验 base 分支与当前 HEAD
4. 行内评论发布失败 -> 回退到 MR 总结评论（Overview）
5. AI 上下文超限 -> 仅审查 review_order 前 N 个高风险文件
6. 证据不足 -> 停止断言并向作者提问

输出契约

• mr_analyzer.py 输出是后续评论/通知的事实来源
• 至少保证字段：verdict、score、findings、severity_counts
• findings 中 file 或 line 缺失时，不发送行内评论
• 审查结论只允许：approve、request_changes、block

最小示例

示例 1：审核 MR

输入：审核 MR #42

动作：preflight -> checkout -> analyzer -> 评论总结 -> 给出结论

示例 2：审核并通知

输入：审核 MR #42 并通知飞书

动作：示例 1 全流程 + feishu_notifier.py

示例 3：通过 MR

输入：通过 MR #42

动作：仅在无阻塞问题时执行 glab mr approve 42；否则改为 request changes 并解释原因

参考文档

• 运行配置：reviewer.config.json
• GitLab 命令与发布流程：references/gitlab_review_workflow.md
• 审查清单：references/mr_review_checklist.md
• AI 审查提示词：references/review_prompts.md