GitLab 代码 reviewer

SKILL研究检索

原名 gitlab-code-reviewer

研究检索 接触敏感数据 许可证明确 OpenClaw
安装这个技能

用于围绕 GitLab 项目、Merge Request、Issue、分支、流水线和代码审查流程提供辅助能力。它适合让 Agent 查询项目状态、整理提交差异、辅助检查合并请求或汇总 CI 结果。使用时需要确认项目权限、访问 token 和目标分支范围;涉及合并、推送、改工单或触发流水线时,应先预览影响并核对团队流程。

累计安装 11,712 本周 488
GitHub 星标 1 仓库 gitlab-code-reviewer
下载量 3,904 技能市场下载数
权限级别 接触敏感数据 安装前请确认风险范围
许可证 许可证明确 MIT-0

安装

ClawHub 市场
在支持 Skills 的客户端里执行,装完问一句「你有哪些技能」验证
openclaw skills install gitlab-code-reviewer

技能档案

研究检索
字段来自技能仓库与公开索引,中文说明由本站标注
作者 / 维护方neuyazvimyi仓库 gitlab-code-reviewer · 版本 1.0.2
宿主客户端OpenClaw技能可被这些客户端加载
安装方式ClawHub 市场安装包 neuyazvimyi/gitlab-code-reviewer
权限级别接触敏感数据安装前请确认风险范围
许可证MIT-0许可证明确,商用前请自行确认条款
仓库可用性available技能仓库当前是否可访问
最近核验2026-05-01上游最后核验时间 · 数据更新 未标注
正文体量6.0 KBSKILL.md 原文大小,越大说明说明书写得越细

能做什么

5 项能力
上游给出的能力概览与适用场景
  • 按任务关键词查找相关 Skills
  • 展示可复制的安装命令
  • 保留来源站点、仓库和原始说明,方便继续核验
  • 补充不同宿主或平台的使用分布数据
  • 展示第三方安全扫描或审计结果
OpenClaw 用户查找和安装 Skill 时用户想查找某类 Agent Skill 时需要根据任务场景推荐可安装能力包时需要对比不同来源的安装命令和来源信息时

权限与风险

接触敏感数据
装之前先读完这段

安装与使用指南

安装步骤

本站只展示命令,不托管安装包,也不自动执行。

怎么用

安装后应在对应宿主中按原始 README 的触发条件使用;当前草稿只做目录说明,具体调用方式由规则抽取,异常条目再复核。

SKILL.md 全文

6.0 KB
模型实际读到的说明书原文,来自技能仓库

GitLab MR Code Review

Workflow

1. Read credentials and check token scope

Credentials: ~/.openclaw/credentials/gitlab.json

{
  "token": "glpat-xxx",
  "host": "https://gitlab.com",
  "ignore_patterns": ["*.min.js", "*.lock", "forms/*.json"]
}

Required API scopes:
- api — required for posting inline comments
- read_api — sufficient for analysis only (no comment posting)

Always run token check first to know upfront whether comments can be posted:

python scripts/gitlab_client.py check-token <mr_url>

Output includes "can_write": true/false. If false, skip step 6 and inform the user that the token needs the api scope to post comments. Do NOT proceed to analysis and then fail at step 6.

2. Fetch MR metadata and diff

python scripts/gitlab_client.py fetch-mr   <mr_url>
python scripts/gitlab_client.py fetch-diff <mr_url>

fetch-diff returns a JSON array. Each entry contains new_path, old_path, diff (unified diff text), and boolean flags new_file, deleted_file, renamed_file.

> Fallback: if the /diffs endpoint returns HTTP 500 (some self-hosted GitLab instances), the script automatically retries via /changes. No manual intervention needed.

3. Filter files

Use ignore_matcher.py to exclude files before analysis:

from ignore_matcher import filter_diffs
reviewable = filter_diffs(all_diffs)   # merges defaults + credentials ignore_patterns

Default ignore patterns (always applied, even without credentials file):
*.min.js, *.min.css, *.lock, package-lock.json, pnpm-lock.yaml, forms/*.json

Binary extensions (.png, .jar, .class, .map, etc.) are always skipped.

4. Analyze the diff

  • Analyze only modified lines (added/removed in the diff). Do not comment on unchanged context lines.
  • If the total diff is large, process file-by-file and aggregate results.
  • Read references/review-guidelines.md for all review rules, severity definitions, and comment format.

Focus areas:
- Java / Spring Boot — Clean Code, SOLID, transaction boundaries, lazy loading
- MongoDB — query correctness, index coverage, atomicity
- PostgreSQL — SQL correctness, isolation levels, index/schema migrations
- React / TypeScript — hooks correctness, type safety, XSS, stale closures

5. Structure the chat summary

Group findings by severity:

## Code Review — <MR title> (<source_branch> → <target_branch>)

### Critical
- `UserService.java:42` — Transaction wraps HTTP call; holds DB lock during network I/O.

### Major
- `OrderRepository.java:87` — N+1: `findRolesByUserId` called inside loop. Use batch query.

### Minor
- `PaymentDto.java:15` — Field name `val` is not descriptive.

### Decision: Needs changes

Decision options: Pass / Needs changes / Reject
- Pass: no Critical or Major findings
- Needs changes: one or more Major findings, no Critical
- Reject: one or more Critical findings

6. Post inline comments to GitLab

Only execute this step if check-token (step 1) returned "can_write": true.

Write comments to a temp JSON file, then post via post_comments.py.
Never use python -c with inline comment bodies — backticks and special characters break shell escaping.

# 1. Write all findings to a JSON file
cat > /tmp/mr_comments.json << 'EOF'
[
  {
    "file_path": "src/main/UserService.java",
    "line": 42,
    "body": "[CRITICAL] Transaction wraps HTTP call...\
\
Suggestion:\
```java\
// fix\
```"
  }
]
EOF

# 2. Post via script
python scripts/post_comments.py <mr_url> /tmp/mr_comments.json

How to determine the correct line number from a diff hunk:

@@ -375,6 +375,8 @@       ← new file starts at line 375
     unchanged line          → 375
     unchanged line          → 376
     unchanged line          → 377
+    added line              → 378  ← use this number
+    added line              → 379

Count from the +A value in @@ -X,Y +A,B @@ for new-file lines.

Each comment body format (from references/review-guidelines.md §8):

[SEVERITY] <one-line issue>

<2-4 sentence explanation referencing the diff.>

Suggestion:
```<language>
<corrected snippet>

```

Constraints:
- Do not auto-approve the MR.
- Do not add labels or trigger pipelines.
- Only post comment-type discussions (no approval API calls).
- If a line is not in the diff, the API returns an error — log it and continue with the next comment.
- On HTTP 403 insufficient_scope, the script stops immediately and prints a fix instruction. Do not retry.

Behavior Rules

  • Strict engineering tone. No emotional language. No generic praise.
  • Analyze only the modified code in the diff. Do not speculate about code outside the diff.
  • Do not log or persist source code content.
  • Respect ignore patterns strictly.
  • For large diffs: process per file, deduplicate similar findings across files before final output.

References

  • Review rules, severity table, comment format: references/review-guidelines.md
  • §2 Java & Spring Boot (Clean Code, transactions, N+1, concurrency)
  • §3 MongoDB (queries, indexes, atomicity)
  • §4 PostgreSQL (SQL correctness, isolation, migrations)
  • §5 React & TypeScript (hooks, type safety, security)
  • §6 SOLID & DDD alignment
  • §7 Severity classification table
  • §8 Inline comment format template

安全信息

审计结论
未标注不代表已通过审计
安全审计VirusTotal、ClawScan、Static analysis第三方安全审计平台给出的结论

热门专题

按场景挑技能
全部专题 →

技能内容以作者仓库为准;分类、权限级别与许可证状态的中文说明为中文整理,最近核验 2026-05-01。