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。
核心工作流
- 同步仓库：进入
REVIEW_REPO_PATH并执行git fetch --all --prune - 切换 MR：优先
glab mr checkout <MR_ID> - 运行分析：执行
scripts/mr_analyzer.py生成 JSON 结果 - 生成结论：根据严重级别与置信度，得出
approve或request_changes - 发布评论：
- 有有效文件与行号 ->scripts/gitlab_inline_commenter.py
- 无法定位行号 -> 回退为 MR 总结评论 - 需要通知时：执行
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 发布 + 飞书通知；除非用户在指令中明确禁止
失败回退顺序（必须按顺序）
glab mr checkout失败 -> 检查glab version、认证、host- 仍失败 -> 使用
git fetch origin merge-requests/<MR_ID>/head:mr-<MR_ID>+git checkout mr_analyzer.py显示无 diff -> 校验 base 分支与当前 HEAD- 行内评论发布失败 -> 回退到 MR 总结评论（Overview）
- AI 上下文超限 -> 仅审查
review_order前 N 个高风险文件 - 证据不足 -> 停止断言并向作者提问
输出契约
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
