gitlab-code-reviewer
WarnAudited by ClawScan on May 10, 2026.
Overview
The skill is mostly aligned with GitLab merge request review, but it can post comments under your account and may send your GitLab token to a host controlled by the MR URL.
Use this skill only with trusted GitLab MR URLs whose host matches your intended GitLab instance. Prefer a least-privilege or project-scoped token, and do not allow it to post comments unless you have reviewed and approved the exact comments first.
Findings (3)
Artifact-based informational review of SKILL.md, metadata, install specs, static scan signals, and capability signals. ClawScan does not execute the skill or run runtime probes.
A malicious or mistyped MR URL could cause your GitLab personal access token to be sent to the wrong server, potentially exposing access to your GitLab account or projects.
The API destination host is taken from the MR URL, which may be any http or https host, and the local GitLab token is sent to that host in the PRIVATE-TOKEN header. The configured credential host is not enforced for fetch/post operations.
pattern = r"(https?://[^/]+)/(.+)/-/merge_requests/(\d+)" ... host, project, iid = parse_mr_url(mr_url) ... req = Request(url, headers={"PRIVATE-TOKEN": token, "Content-Type": "application/json"})Validate that the MR URL host exactly matches the configured GitLab host, require HTTPS, and use separate per-host/project-scoped tokens with least privilege.
A normal review request could lead to comments being posted to a merge request under your account before you approve the exact wording.
Posting review comments is an externally visible GitLab account action, but the workflow condition is token write capability rather than an explicit user approval after the generated comments are shown.
Triggers on requests like: "review this MR" ... "check this merge request" ... "post review comments to GitLab" ... Only execute this step if `check-token` (step 1) returned `"can_write": true`.
Default to analysis-only, show the proposed comments first, and require an explicit user instruction such as 'post these comments' before calling the posting script.
Users may not realize from the registry metadata that installing/using the skill involves a local GitLab token with potentially broad account permissions.
The skill clearly documents a GitLab token file and the need for API scope, but the registry metadata says there is no primary credential or required config path. The `api` scope is broad even if the script intends only to post discussions.
Credentials: `~/.openclaw/credentials/gitlab.json` ... Required API scopes: `api` — required for posting inline comments; `read_api` — sufficient for analysis only
Declare the credential/config requirement in metadata, document least-privilege token guidance, and prefer project-scoped tokens where GitLab supports them.