gitlab-mr-reviewer

当需要审核 GitLab 合并请求、检查 MR diff 风险、发布 GitLab 审查评论、执行 approve/request changes，或发送 MR 审查通知时使用。

Security Scan

The skill's code and runtime instructions match a GitLab MR reviewer, but the package metadata omits the sensitive environment variables and credentials the scripts actually require and the webhook/bridge code can forward MR content to an OpenClaw gateway — both make the package's true requirements and blast radius unclear.

Purpose & Capability

The name, SKILL.md, and scripts consistently implement a GitLab MR review workflow (checkout, analyze, post inline notes, notify Feishu, optional webhook -> OpenClaw trigger). However the registry metadata lists no required env vars or binaries while the SKILL.md and included reviewer.config.json clearly expect git/glab/python and several secrets (GITLAB_TOKEN, FEISHU_WEBHOOK_URL, OPENCLAW_HOOK_TOKEN, OPENCLAW_GATEWAY_URL, GITLAB_WEBHOOK_SECRET). The omission in metadata is an inconsistency that should be explained.

Instruction Scope

The SKILL.md restricts behavior to MR review and references the provided scripts for actions. The runtime instructions call local git/glab commands, run the analyzer, post to GitLab and Feishu, and may trigger an OpenClaw gateway via webhook_listener. These operations are within the stated purpose, but webhook_listener sends MR text (and the constructed message) to a gateway URL which could be external if misconfigured — reviewers should verify the gateway target and tokens before use.

Install Mechanism

No install spec is provided and code is included as scripts; nothing is automatically downloaded from third-party URLs. Risk from installation is low, but the included scripts will perform network operations when executed, so the runtime behavior is what requires review.

Credentials

Although metadata declares no required env vars, reviewer.config.json and the scripts reference multiple sensitive variables (GITLAB_TOKEN, FEISHU_WEBHOOK_URL, OPENCLAW_HOOK_TOKEN/OPENCLAW_GATEWAY_URL, GITLAB_WEBHOOK_SECRET). These are necessary for full functionality but were not declared — this mismatch is concerning. In particular, OPENCLAW_HOOK_TOKEN + gateway URL allow the skill to call a hook endpoint (Bearer token) that can trigger other agent actions; provide least-privilege, project-scoped tokens and verify endpoints before granting them.

Persistence & Privilege

The skill does not request always:true and does not modify other skills. The webhook_listener can run a long-lived HTTP server that spawns threads to POST to an OpenClaw gateway; that increases runtime blast radius if started on a publicly reachable host, but this is an expected capability for a webhook bridge and not an inherent platform privilege escalation.

What to consider before installing

This package implements a coherent GitLab MR reviewer, but you should not install or run it without checking a few things: - Metadata mismatch: the registry entry did not declare required environment variables, yet reviewer.config.json and scripts expect sensitive values (GITLAB_TOKEN, FEISHU_WEBHOOK_URL, OPENCLAW_HOOK_TOKEN, OPENCLAW_GATEWAY_URL, GITLAB_WEBHOOK_SECRET). Verify with the author why they were omitted and update metadata before use. - Secrets and least privilege: only provide a project-scoped GitLab PAT with the minimal scopes needed (comments/reads), and a Feishu webhook limited to sending messages. Do NOT supply an account-level admin token. Prefer ephemeral or narrowly-scoped tokens. - OpenClaw gateway target: by default the gateway is http://127.0.0.1:18789, but reviewer.config.json allows changing OPENCLAW_GATEWAY_URL. If that is set to an external host, the webhook listener and scripts will POST MR content there using OPENCLAW_HOOK_TOKEN; confirm that endpoint is trusted and that the token is limited in scope. - Webhook listener exposure: if you run webhook_listener.py, bind it only to internal interfaces and protect it with GITLAB_WEBHOOK_SECRET. Do not expose it publicly without network controls. - Test in dry-run: run scripts with --dry-run or in an isolated environment and inspect what they would POST (gitlab_inline_commenter supports dry-run). Review the code to ensure it doesn't transmit anything beyond MR metadata and findings you are comfortable sharing. - Update metadata/ask publisher: ask the skill publisher to declare required binaries and env vars in the registry metadata and to document the minimum token scopes and expected endpoints. If you cannot verify the author, avoid running the webhook listener and run analysis locally on a copy of the repo. If you confirm those items (trusted gateway, least-privilege tokens, local-only webhook exposure, and corrected metadata), the skill appears coherent with its stated purpose; otherwise treat it as risky.

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

缺少最小配置时，先停下并向用户追问，不得猜测 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

硬规则

• 永远先静态分析，再决定是否做 AI 深审
• 不泄露任何 secret（如 GITLAB_TOKEN、FEISHU_WEBHOOK_URL）
• confidence < 0.6 不下结论，改为提问式评论
• 单个问题只评论一次，避免重复刷屏
• 行号缺失或定位失败时，必须降级为 summary note
• 大 MR 优先审查高风险文件，不做无边界全量深审

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

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