gitlab-claude

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

GitLab Skill (Claude Code)

Use the

glab

CLI to interact with GitLab. Supports five MR workflows (Read → Review → Fix → CI Fix → Feedback) plus general glab operations.

使用

glab

CLI与GitLab进行交互。支持五种MR工作流（Read → Review → Fix → CI Fix → Feedback）以及常规glab操作。

URL Parsing

URL解析

When given a GitLab MR URL like

https://gitlab.com/group/subgroup/project/-/merge_requests/42

repo_ref: strip

https://

and everything from

/-/

onward →

gitlab.com/group/subgroup/project

mr_id: extract the number after
```
merge_requests/
```
→
```
42
```

These two values power most glab commands:

glab mr <cmd> <mr_id> --repo <repo_ref>

当提供类似

https://gitlab.com/group/subgroup/project/-/merge_requests/42

的GitLab MR URL时：

repo_ref：去除
```
https://
```
和
```
/-/
```
之后的所有内容 →
```
gitlab.com/group/subgroup/project
```
mr_id：提取
```
merge_requests/
```
后的数字 →
```
42
```

这两个值是大多数glab命令的核心：

glab mr <cmd> <mr_id> --repo <repo_ref>

Intent Detection

意图检测

When given a GitLab MR URL, determine the user's intent before selecting a workflow. There are five distinct workflows — Read is the lightest (just summarize), Review runs full specialist agents, Fix reviews then implements, CI Fix targets pipeline failures, and Feedback addresses reviewer comments. Default to Read when no strong signal indicates the user wants more.

Signal in User Request	Workflow
"อ่าน", "ดู", "check", "สรุป", "summary", bare URL with no action verb	MR Read — fetch MR info + diff, then summarize. No specialist agents.
"review", "ตรวจ", "ช่วย review", "review ให้หน่อย"	MR Review — full code/security/QA review via 3 parallel specialist agents, post findings as comment
"แก้", "fix", "แก้ตาม", "แก้ issue", "implement", "ทำตาม"	MR Fix — review first, then ask user to invoke /neo-team-claude to implement fixes
"fix CI", "fix pipeline", "แก้ pipeline", "pipeline fail", "CI fail", "build fail"	MR CI Fix — fetch failed job logs, analyze, ask user to invoke /neo-team-claude to fix
"address feedback", "แก้ตาม comment", "แก้ตาม feedback", "resolve threads", "ตอบ review"	MR Feedback — parse unresolved review threads, implement fixes, resolve

Decision rule:

If the user's message mentions CI/pipeline failure → MR CI Fix
If the user's message mentions feedback/comments to address → MR Feedback
If the user's message contains a fix/แก้ keyword (not CI/feedback-specific) → MR Fix
If the user's message explicitly says "review" or "ตรวจ" → MR Review
Everything else (bare URL, "อ่าน", "ดู", "check", "สรุป", or ambiguous) → MR Read (lightest option, no side effects)

当收到GitLab MR URL时，先确定用户意图再选择工作流。共有五种不同的工作流——Read是最轻量的（仅总结），Review会调用完整的专业代理，Fix先审核再实施修改，CI Fix针对流水线失败问题，Feedback处理审核者的评论。当没有明确信号表明用户需要更多操作时，默认使用Read工作流。

用户请求中的信号	工作流
“读取”、“查看”、“check”、“总结”、“summary”、无操作动词的纯URL	MR Read — 获取MR信息和差异，然后进行总结。不调用专业代理。
“review”、“检查”、“帮我review”、“帮我做下review”	MR Review — 通过3个并行的专业代理进行完整的代码/安全/QA审核，将结果作为评论发布
“修改”、“fix”、“根据...修改”、“修复问题”、“implement”、“按照...做”	MR Fix — 先进行审核，然后请用户调用/neo-team-claude来实施修改
“fix CI”、“fix pipeline”、“修复流水线”、“pipeline失败”、“CI失败”、“构建失败”	MR CI Fix — 获取失败任务的日志，进行分析，然后请用户调用/neo-team-claude来修复
“处理反馈”、“根据评论修改”、“根据反馈修改”、“解决讨论线程”、“回复审核”	MR Feedback — 解析未解决的审核线程，实施修改并解决问题

决策规则：

如果用户消息提到CI/流水线失败 → MR CI Fix
如果用户消息提到需要处理反馈/评论 → MR Feedback
如果用户消息包含修改/fix关键词（非CI/反馈相关） → MR Fix
如果用户消息明确说“review”或“检查” → MR Review
其他情况（纯URL、“读取”、“查看”、“check”、“总结”或模糊请求） → MR Read（最轻量选项，无额外操作）

Specialist Reference Files

专业代理参考文件

This skill delegates review work to three specialist agents. Their detailed instructions live in the neo-team-claude skill's reference files. Before spawning review agents, read these files with

Read

Specialist	Reference File
Code Reviewer	`.agents/skills/neo-team-claude/references/code-reviewer.md`
Security	`.agents/skills/neo-team-claude/references/security.md`
QA	`.agents/skills/neo-team-claude/references/qa.md`

该技能将审核工作委托给三个专业代理。它们的详细说明存于neo-team-claude技能的参考文件中。在启动审核代理前，先通过

Read

读取这些文件：

专业代理	参考文件
代码审核员	`.agents/skills/neo-team-claude/references/code-reviewer.md`
安全审核员	`.agents/skills/neo-team-claude/references/security.md`
QA审核员	`.agents/skills/neo-team-claude/references/qa.md`

MR Read Workflow

MR Read工作流

The lightest workflow — no specialist agents, no comments posted. Just fetch MR data and present a concise summary to the user in the conversation.

1. Fetch MR info (JSON) and diff
2. Summarize in conversation

最轻量的工作流 — 不调用专业代理，也不在MR上发布任何评论。仅获取MR数据并在对话中向用户展示简洁的总结。

1. 获取MR信息（JSON格式）和差异
2. 在对话中进行总结

Step 1: Fetch

步骤1：获取数据

bash

glab mr view <mr_id> --repo <repo_ref> --output json
glab mr diff <mr_id> --repo <repo_ref>

bash

glab mr view <mr_id> --repo <repo_ref> --output json
glab mr diff <mr_id> --repo <repo_ref>

Step 2: Summarize

步骤2：总结

Present a concise Thai summary covering:

MR metadata — title, author, status, source → target branch, pipeline status
What changed — brief description of the changes (group by area: features, refactoring, CI, docs, tests)
Files changed — count and key files
Existing comments — if there are review comments, briefly note them

Keep it terminal-friendly and scannable. Do NOT spawn specialist agents or post any comments on the MR.

展示简洁的中文总结，涵盖：

MR元数据 — 标题、作者、状态、源分支→目标分支、流水线状态
变更内容 — 变更的简要描述（按领域分组：功能、重构、CI、文档、测试）
变更文件 — 文件数量和关键文件
现有评论 — 如果有审核评论，简要提及

保持适合终端阅读的格式，便于快速浏览。不要启动专业代理或在MR上发布任何评论。

MR Review Workflow

MR Review工作流

When the user asks to review a MR (or intent is detected as "review"), run this pipeline:

1. Fetch MR info, diff, and existing comments
2. Read & summarize existing comments (understand what's already discussed)
3. code-reviewer + security + qa → review in PARALLEL (with comment context)
4. Compose Thai comment from template
5. Post comment to the MR

当用户要求审核MR（或意图检测为“review”）时，执行以下流程：

1. 获取MR信息、差异和现有评论
2. 读取并总结现有评论（了解已讨论的内容）
3. code-reviewer + security + qa → 并行审核（包含评论上下文）
4. 根据模板撰写中文评论
5. 将评论发布到MR

Step 1: Fetch

步骤1：获取数据

bash

glab mr view <mr_id> --repo <repo_ref> --output json
glab mr diff <mr_id> --repo <repo_ref>
glab mr note list <mr_id> --repo <repo_ref>

Extract from the view output: MR title, source branch, target branch, author.

bash

glab mr view <mr_id> --repo <repo_ref> --output json
glab mr diff <mr_id> --repo <repo_ref>
glab mr note list <mr_id> --repo <repo_ref>

从view输出中提取：MR标题、源分支、目标分支、作者。

Step 2: Read Existing Comments

步骤2：读取现有评论

Before diving into the review, read through all existing MR comments/notes fetched in Step 1. This gives crucial context — other reviewers may have already flagged issues, the author may have explained design decisions, or there may be ongoing discussions that affect how you should review. Summarize the key points:

Issues already raised by other reviewers
Author's explanations or decisions
Unresolved discussions that need attention
Resolved items (avoid duplicating feedback)

This prevents the review from repeating what's already been said and helps focus on gaps that haven't been addressed yet.

在开始审核前，先阅读步骤1中获取的所有现有MR评论/备注。这能提供关键上下文 — 其他审核者可能已经标记了问题，作者可能已经解释了设计决策，或者可能存在影响审核方式的正在进行的讨论。总结关键点：

其他审核者已提出的问题
作者的解释或决策
需要关注的未解决讨论
已解决的事项（避免重复反馈）

这能防止审核重复已有的内容，帮助聚焦于尚未解决的空白。

Step 3: Parallel Review

步骤3：并行审核

Read the project's

CLAUDE.md

if available (for conventions). Then read the three specialist reference files listed above, and spawn all three agents at the same time — including a summary of existing comments so reviewers have full context:

Agent(
  subagent_type: "Code Reviewer",
  prompt: """

如果项目有

CLAUDE.md

文件，先读取（了解约定）。然后读取上述三个专业代理的参考文件，并同时启动所有三个代理 — 包含现有评论的总结，以便审核者拥有完整上下文：

Agent(
  subagent_type: "Code Reviewer",
  prompt: """

Role: Code Reviewer

角色：代码审核员

[paste full code-reviewer instructions from .agents/skills/neo-team-claude/references/code-reviewer.md]

[粘贴.agents/skills/neo-team-claude/references/code-reviewer.md中的完整代码审核说明]

Project Conventions

项目约定

[relevant sections from CLAUDE.md if available, else omit]

[如果有CLAUDE.md，粘贴相关部分，否则省略]

Existing MR Comments

现有MR评论

[summary of existing comments from Step 2 — issues raised, author explanations, unresolved discussions] Do NOT repeat issues that other reviewers have already flagged unless you have additional insight to add.

[步骤2中的评论总结 — 已提出的问题、作者的解释、未解决的讨论] 除非有额外见解，否则不要重复其他审核者已标记的问题。

Task

任务

Review the following MR diff for convention compliance.

MR: !<mr_id> — <mr_title> Branch: <source> → <target>

审核以下MR差异是否符合约定。

MR: !<mr_id> — <mr_title> 分支: <source> → <target>

Diff

差异

<full diff output> """ )

Agent( subagent_type: "Security Reviewer", prompt: """

<完整差异输出> """ )

Agent( subagent_type: "Security Reviewer", prompt: """

Role: Security Reviewer

角色：安全审核员

[paste full security instructions from .agents/skills/neo-team-claude/references/security.md]

[粘贴.agents/skills/neo-team-claude/references/security.md中的完整安全审核说明]

Existing MR Comments

现有MR评论

[summary of existing comments from Step 2] Do NOT repeat security concerns that have already been raised unless you have additional findings.

[步骤2中的评论总结] 除非有新发现，否则不要重复已提出的安全问题。

Task

任务

Security review the following MR diff.

MR: !<mr_id> — <mr_title> Branch: <source> → <target>

对以下MR差异进行安全审核。

MR: !<mr_id> — <mr_title> 分支: <source> → <target>

Diff

差异

<full diff output> """ )

Agent( subagent_type: "QA Reviewer", prompt: """

<完整差异输出> """ )

Agent( subagent_type: "QA Reviewer", prompt: """

Role: QA Reviewer

角色：QA审核员

[paste full QA instructions from .agents/skills/neo-team-claude/references/qa.md]

[粘贴.agents/skills/neo-team-claude/references/qa.md中的完整QA审核说明]

Project Conventions

项目约定

[relevant sections from CLAUDE.md if available, else omit]

[如果有CLAUDE.md，粘贴相关部分，否则省略]

Existing MR Comments

现有MR评论

[summary of existing comments from Step 2] Do NOT repeat QA concerns that have already been raised unless you have additional findings.

[步骤2中的评论总结] 除非有新发现，否则不要重复已提出的QA问题。

Task

任务

QA review the following MR diff. Focus on:

Test coverage gaps (are new code paths tested?)
Missing edge case tests
Regression risks
Acceptance criteria validation (if available)

MR: !<mr_id> — <mr_title> Branch: <source> → <target>

对以下MR差异进行QA审核。重点关注：

测试覆盖缺口（新代码路径是否有测试？）
缺失的边缘情况测试
回归风险
验收标准验证（如果有）

MR: !<mr_id> — <mr_title> 分支: <source> → <target>

Diff

差异

<full diff output> """ ) ```

<完整差异输出> """ )

undefined

Step 4: Compose Thai comment

步骤4：撰写中文评论

Read references/mr-review-template.md and fill in findings from all three agents (code-reviewer, security, qa).

读取references/mr-review-template.md，填入三个代理的审核结果（code-reviewer、security、qa）。

Step 5: Post

步骤5：发布评论

bash

glab mr note <mr_id> --repo <repo_ref> -m "<thai_comment>"

glab

is not authenticated or fails, output the review in the conversation instead and tell the user.

bash

glab mr note <mr_id> --repo <repo_ref> -m "<中文评论>"

如果

glab

未认证或执行失败，则在对话中输出审核结果并告知用户。

MR Fix Workflow

MR Fix工作流

When intent is detected as "fix" (user wants to fix issues from a MR), run review first then hand off to /neo-team-claude for implementation.

1. Fetch MR info, diff, and existing comments          (same as MR Review Step 1)
2. Read & summarize existing comments                   (same as MR Review Step 2)
3. code-reviewer + security + qa → review in PARALLEL   (same as MR Review Step 3)
4. Compile findings into structured handoff context
5. Ask user to invoke /neo-team-claude with compiled findings
6. Post summary comment on MR (after fix is done)

当意图检测为“fix”（用户想要修复MR中的问题）时，先执行审核，再将任务交给/neo-team-claude实施修改。

1. 获取MR信息、差异和现有评论          （与MR Review步骤1相同）
2. 读取并总结现有评论                   （与MR Review步骤2相同）
3. code-reviewer + security + qa → 并行审核   （与MR Review步骤3相同）
4. 将审核结果整理为结构化的交接上下文
5. 请用户调用/neo-team-claude并提供整理后的结果
6. （修复完成后）在MR上发布总结评论

Steps 1-3: Same as MR Review

步骤1-3：与MR Review相同

Run the exact same fetch → read comments → parallel review pipeline. The only difference is what happens after.

Important for MR Fix: When composing the agent prompts in Step 3, add this instruction to each agent:

Categorize every finding with a severity level: Blocker, Critical, Warning, or Info. Format each finding as:
[Severity] file:line — description
. This structured output is required for the handoff to the fix pipeline.

执行完全相同的获取→读取评论→并行审核流程。唯一的区别是后续步骤。

MR Fix的重要注意事项： 在步骤3撰写代理提示时，需为每个代理添加以下说明：

为每个发现标记严重级别：Blocker、Critical、Warning或Info。每个发现的格式为：
[级别] 文件:行号 — 描述
。这种结构化输出是交接给修复流程的必需内容。

Step 4: Compile Findings for Handoff

步骤4：整理交接用的审核结果

After all three review agents return, compile their findings into a structured context:

undefined

在三个审核代理返回结果后，将它们的发现整理为结构化上下文：

undefined

MR Fix Context

MR Fix上下文

MR: !<mr_id> — <mr_title> Branch: <source_branch> → <target_branch> Repository: <repo_ref>

MR: !<mr_id> — <mr_title> 分支: <source_branch> → <target_branch> 仓库: <repo_ref>

Review Findings

审核结果

Code Review Findings

代码审核结果

<code_reviewer_output — full findings with severity levels>

<code_reviewer输出 — 带严重级别的完整发现>

Security Findings

安全审核结果

<security_output — full findings with severity levels>

<security输出 — 带严重级别的完整发现>

QA Findings

QA审核结果

<qa_output — full findings with severity levels>

<qa输出 — 带严重级别的完整发现>

Severity Summary

严重级别汇总

Level	Count
Blocker	X
Critical	X
Warning	X
Info	X

级别	数量
Blocker	X
Critical	X
Warning	X
Info	X

MR Diff

MR差异

<full diff for reference> ```

Only proceed to Step 5 if there are Blocker or Critical findings. If all findings are Warning/Info only:

Post the review comment on the MR (using the MR Review template from Step 4-5 of the Review workflow)
Inform the user in the conversation: "ไม่พบ Blocker/Critical — findings ทั้งหมดเป็น Warning/Info เท่านั้น ไม่จำเป็นต้องแก้ไขเร่งด่วน"
End the workflow here. Do NOT proceed to fix. The user can manually request fixes if desired.

<供参考的完整差异>


仅当存在**Blocker或Critical**级别的发现时，才继续步骤5。如果所有发现都是Warning/Info级别：
1. 使用MR Review工作流的步骤4-5中的模板，将审核评论发布到MR
2. 在对话中告知用户：“未发现Blocker/Critical级别的问题 — 所有发现均为Warning/Info级别，无需紧急修复”
3. **在此结束工作流**。如果用户需要，可手动请求修复。

Step 5: Ask User to Invoke /neo-team-claude

步骤5：请用户调用/neo-team-claude

Since Claude Code does not have programmatic skill invocation, ask the user to load the neo-team-claude skill:

กรุณาเรียก /neo-team-claude แล้ว paste context ด้านล่างนี้:

แก้ไขโค้ดตาม review findings จาก MR

<compiled findings from Step 4>

由于Claude Code无法以编程方式调用技能，请用户加载neo-team-claude技能：

请调用/neo-team-claude并粘贴以下上下文：

根据MR的审核结果修复代码

<步骤4中整理的结果>

Instructions

说明

Fix all Blocker and Critical findings
Address Warning findings where practical
Info findings are optional improvements
The MR diff is provided for context — the code is already in the working directory
After fixing, run existing tests to verify nothing is broken


/neo-team-claude will classify this as a **Bug Fix** workflow internally and run:
1. system-analyzer → understand the codebase + findings
2. developer + qa + code-reviewer → implement fixes + test + verify (3-WAY PARALLEL)
3. Remediation if needed

修复所有Blocker和Critical级别的问题
尽可能处理Warning级别的问题
Info级别的问题为可选优化项
已提供MR差异作为上下文 — 代码已在工作目录中
修复完成后，运行现有测试以验证未引入新问题


/neo-team-claude会将此归类为**Bug Fix**工作流，并执行：
1. system-analyzer → 理解代码库和问题
2. developer + qa + code-reviewer → 实施修复+测试+验证（三方并行）
3. 必要时进行补救

Step 6: Post Summary Comment

步骤6：发布总结评论

After /neo-team-claude completes (user will come back to this conversation), post a summary comment on the MR:

bash

glab mr note <mr_id> --repo <repo_ref> -m "<summary_comment>"

The comment should follow this format:

undefined

当/neo-team-claude完成后（用户会回到此对话），在MR上发布总结评论：

bash

glab mr note <mr_id> --repo <repo_ref> -m "<总结评论>"

评论应遵循以下格式：

undefined

🤖 MR Fix Summary

🤖 MR修复总结

MR: !<mr_id> — <mr_title>

สิ่งที่แก้ไข

已修复内容

<已应用的修复列表，对应原始发现>

สถานะ

状态

Blocker: X/Y แก้แล้ว
Critical: X/Y แก้แล้ว
Warning: X/Y แก้แล้ว

ผลลัพธ์: ✅ แก้ไขเสร็จ / ⚠️ แก้ไขบางส่วน (ดูรายละเอียดด้านบน)

Fix โดย GitLab Skill + Neo Team · Claude Code

---

Blocker: X/Y 已修复
Critical: X/Y已修复
Warning: X/Y已修复

结果: ✅ 修复完成 / ⚠️ 部分修复（详见上文）

由GitLab Skill + Neo Team · Claude Code完成修复

---

MR CI Fix Workflow

MR CI Fix工作流

When the user wants to fix CI/pipeline failures for a MR, run this pipeline:

1. Fetch MR info and pipeline status
2. Identify failed jobs and fetch logs
3. Analyze failures and categorize
4. Ask user to invoke /neo-team-claude to implement fixes
5. Push fix and optionally retry pipeline

当用户想要修复MR的CI/流水线失败问题时，执行以下流程：

1. 获取MR信息和流水线状态
2. 识别失败任务并获取日志
3. 分析失败原因并分类
4. 请用户调用/neo-team-claude实施修复
5. 推送修复并可选地重试流水线

Step 1: Fetch MR + Pipeline Status

步骤1：获取MR + 流水线状态

bash

glab mr view <mr_id> --repo <repo_ref> --output json
glab ci list --repo <repo_ref> --branch <source_branch>

Extract MR metadata and identify the latest pipeline. If the MR URL wasn't provided but the user mentions a branch or "fix pipeline", use

glab ci status

to find the current pipeline.

bash

glab mr view <mr_id> --repo <repo_ref> --output json
glab ci list --repo <repo_ref> --branch <source_branch>

提取MR元数据并识别最新的流水线。如果用户未提供MR URL但提到了分支或“修复流水线”，使用

glab ci status

查找当前流水线。

Step 2: Get Failed Job Logs

步骤2：获取失败任务的日志

bash

undefined

bash

undefined

List jobs in the failed pipeline:

列出失败流水线中的任务：

glab ci view <pipeline_id> --repo <repo_ref>

Fetch logs for each failed job:

获取每个失败任务的日志：

glab ci trace <job_id> --repo <repo_ref>


Collect the last ~100 lines of each failed job's log output. These contain the actual error messages.

glab ci trace <job_id> --repo <repo_ref>


收集每个失败任务日志的最后约100行，这些包含实际的错误信息。

Step 3: Analyze Failures

步骤3：分析失败原因

Categorize each failure:

Category	Examples	Typical Fix
Build failure	Compilation errors, missing imports, type errors	Fix source code
Test failure	Unit/integration/E2E test failures	Fix code or update tests
Lint failure	Style violations, formatting issues	Run formatter, fix violations
Config failure	Docker build, missing env vars, bad CI config	Fix config files

Present a summary to the user before proceeding:

undefined

对每个失败进行分类：

分类	示例	典型修复方式
构建失败	编译错误、缺失导入、类型错误	修复源代码
测试失败	单元/集成/E2E测试失败	修复代码或更新测试
代码规范检查失败	样式违规、格式问题	运行格式化工具，修复违规项
配置失败	Docker构建失败、缺失环境变量、错误的CI配置	修复配置文件

在继续之前，向用户展示总结：

undefined

CI Failure Analysis

CI失败分析

Pipeline: #<pipeline_id> — <status> Branch: <source_branch>

流水线: #<pipeline_id> — <状态> 分支: <source_branch>

Failed Jobs

失败任务

[Build] job-name — CompilationError: missing import "pkg/util"
[Test] test-unit — FAIL TestUserCreate: expected 200, got 500

Proceed to fix?

undefined

[构建] job-name — CompilationError: 缺失导入“pkg/util”
[测试] test-unit — FAIL TestUserCreate: 预期200，实际500

是否继续修复？

undefined

Step 4: Ask User to Invoke /neo-team-claude

步骤4：请用户调用/neo-team-claude

Since Claude Code does not have programmatic skill invocation, ask the user to load the neo-team-claude skill:

กรุณาเรียก /neo-team-claude แล้ว paste context ด้านล่างนี้:

แก้ไข CI/pipeline failures จาก MR

由于Claude Code无法以编程方式调用技能，请用户加载neo-team-claude技能：

请调用/neo-team-claude并粘贴以下上下文：

修复MR的CI/流水线失败问题

CI Failure Context

CI失败上下文

MR: !<mr_id> — <mr_title> Branch: <source_branch> Pipeline: #<pipeline_id>

MR: !<mr_id> — <mr_title> 分支: <source_branch> 流水线: #<pipeline_id>

Failed Jobs

失败任务

<for each failed job:> - **Job:** <job_name> (stage: <stage>) - **Category:** <Build|Test|Lint|Config> - **Error:** <relevant error excerpt from logs>

<针对每个失败任务：>

任务: <job_name>（阶段: <stage>）
分类: <构建|测试|代码规范检查|配置>
错误: <日志中的相关错误片段>

Instructions

说明

Fix all failing jobs
Run the failing commands locally to verify fixes before pushing
Do NOT change CI configuration unless the config itself is the problem
If a test failure reveals a genuine bug, fix the code (not the test)


/neo-team-claude will classify this as a **Bug Fix** workflow and route through system-analyzer → developer → verification agents.

修复所有失败的任务
在推送前本地运行失败的命令以验证修复
除非配置本身有问题，否则不要修改CI配置
如果测试失败暴露了真正的bug，修复代码（而非测试）


/neo-team-claude会将此归类为**Bug Fix**工作流，并通过system-analyzer → developer → 验证代理进行处理。

Step 5: Push and Retry

步骤5：推送修复并重试

After /neo-team-claude completes (user returns to this conversation):

bash

git push origin <source_branch>
glab ci retry <pipeline_id> --repo <repo_ref>

Post a summary comment on the MR:

bash

glab mr note <mr_id> --repo <repo_ref> -m "<summary>"

Summary format:

undefined

当/neo-team-claude完成后（用户回到此对话）：

bash

git push origin <source_branch>
glab ci retry <pipeline_id> --repo <repo_ref>

在MR上发布总结评论：

bash

glab mr note <mr_id> --repo <repo_ref> -m "<总结>"

总结格式：

undefined

🤖 CI Fix Summary

🤖 CI修复总结

MR: !<mr_id> — <mr_title> Pipeline: #<pipeline_id>

MR: !<mr_id> — <mr_title> 流水线: #<pipeline_id>

สิ่งที่แก้ไข

已修复内容

✅ [Build] job-name — fixed missing import
✅ [Test] test-unit — fixed handler returning wrong status code

✅ [构建] job-name — 修复了缺失的导入
✅ [测试] test-unit — 修复了处理器返回错误状态码的问题

Pipeline

流水线

🔄 Retry triggered — pipeline #<new_pipeline_id>

CI Fix โดย GitLab Skill + Neo Team · Claude Code

---

🔄 已触发重试 — 流水线 #<new_pipeline_id>

由GitLab Skill + Neo Team · Claude Code完成CI修复

---

MR Feedback Workflow

MR Feedback工作流

When the user wants to address review feedback/comments on a MR, parse unresolved threads and implement fixes.

1. Fetch MR info, diff, and all comments/discussions
2. Filter and group unresolved feedback
3. Ask user to invoke /neo-team-claude with structured feedback
4. Push fix, post summary, and resolve threads

当用户想要处理MR的审核反馈/评论时，解析未解决的线程并实施修复。

1. 获取MR信息、差异和所有评论/讨论
2. 筛选并分组未解决的反馈
3. 请用户调用/neo-team-claude并提供结构化的反馈
4. 推送修复，发布总结，并解决线程

Step 1: Fetch

步骤1：获取数据

bash

glab mr view <mr_id> --repo <repo_ref> --output json
glab mr diff <mr_id> --repo <repo_ref>
glab mr note list <mr_id> --repo <repo_ref>

bash

glab mr view <mr_id> --repo <repo_ref> --output json
glab mr diff <mr_id> --repo <repo_ref>
glab mr note list <mr_id> --repo <repo_ref>

Step 2: Parse Unresolved Feedback

步骤2：解析未解决的反馈

From the notes/comments, identify:

Actionable feedback — explicit change requests ("fix this", "add error handling", "rename to X")
Suggestions — optional improvements ("consider using...", "might be better to...")
Questions — need user input before acting ("why did you choose X?", "should this handle Y?")

Group by file and classify:

undefined

从备注/评论中识别：

可操作的反馈 — 明确的修改请求（“修复这个”、“添加错误处理”、“重命名为X”）
建议 — 可选的改进（“考虑使用...”、“可能更好的方式是...”）
问题 — 需要用户输入才能继续（“你为什么选择X？”、“这个应该处理Y吗？”）

按文件分组并分类：

undefined

Unresolved Feedback

未解决的反馈

file: src/handler.go

文件: src/handler.go

@reviewer1: "Missing error handling on line 42" — Actionable
@reviewer2: "Consider using context.WithTimeout" — Suggestion

@reviewer1: “第42行缺失错误处理” — 可操作
@reviewer2: “考虑使用context.WithTimeout” — 建议

file: src/service.go

文件: src/service.go

@reviewer1: "N+1 query in GetUsers" — Actionable

@reviewer1: “GetUsers中存在N+1查询问题” — 可操作

Questions (need user input)

需要用户回复的问题

@reviewer1: "Should this endpoint support pagination?"


**If there are questions**, present them to the user before proceeding. The user's answers become part of the context for /neo-team-claude.

@reviewer1: “这个端点应该支持分页吗？”


**如果存在问题**，在继续前先向用户展示。用户的回答将成为/neo-team-claude的上下文的一部分。

Step 3: Ask User to Invoke /neo-team-claude

步骤3：请用户调用/neo-team-claude

กรุณาเรียก /neo-team-claude แล้ว paste context ด้านล่างนี้:

แก้ไขโค้ดตาม review feedback จาก MR

请调用/neo-team-claude并粘贴以下上下文：

根据MR的审核反馈修复代码

Feedback Context

反馈上下文

MR: !<mr_id> — <mr_title> Branch: <source_branch> → <target_branch>

MR: !<mr_id> — <mr_title> 分支: <source_branch> → <target_branch>

Actionable Feedback

可操作的反馈

<可操作项列表，包含文件、行号、审核者和描述>

Suggestions

建议

<建议列表 — 尽可能实施>

User Answers to Questions

用户对问题的回复

<步骤2中的用户回答（如果有）>

MR Diff

MR差异

<当前差异供参考>

Instructions

说明

Address ALL actionable feedback items
Implement suggestions where practical; explain in summary if skipped
Run existing tests after changes
Do not modify code unrelated to the feedback

undefined

处理所有可操作的反馈项
尽可能实施建议；如果跳过，请在总结中说明
修改后运行现有测试
不要修改与反馈无关的代码

undefined

Step 4: Push, Post Summary, and Resolve

步骤4：推送修复、发布总结并解决线程

After fixes are applied (user returns to this conversation):

bash

git push origin <source_branch>
glab mr note <mr_id> --repo <repo_ref> -m "<summary>"

Summary format:

undefined

当修复完成后（用户回到此对话）：

bash

git push origin <source_branch>
glab mr note <mr_id> --repo <repo_ref> -m "<总结>"

总结格式：

undefined

🤖 Feedback Addressed

🤖 反馈处理完成

MR: !<mr_id> — <mr_title>

สิ่งที่แก้ไข

已修复内容

✅ src/handler.go:42 — เพิ่ม error handling ตาม @reviewer1
✅ src/service.go:15 — แก้ N+1 query ตาม @reviewer1
✅ src/handler.go:58 — ใช้ context.WithTimeout ตาม @reviewer2
⏭️ src/config.go:10 — skipped: ไม่เกี่ยวกับ scope ของ MR นี้

✅ src/handler.go:42 — 按照@reviewer1的建议添加了错误处理
✅ src/service.go:15 — 按照@reviewer1的建议修复了N+1查询问题
✅ src/handler.go:58 — 按照@reviewer2的建议使用了context.WithTimeout
⏭️ src/config.go:10 — 跳过：不属于此MR的范围

ผลลัพธ์

结果

Actionable: X/Y แก้แล้ว
Suggestions: X/Y implemented

Feedback addressed โดย GitLab Skill + Neo Team · Claude Code

---

可操作项: X/Y已处理
建议: X/Y已实施

由GitLab Skill + Neo Team · Claude Code处理反馈

---

Common glab Operations

常见glab操作

Use these directly via

Bash

when the user asks for something other than a full review:

Task	Command
List open MRs	`glab mr list --repo <repo_ref>`
View MR details	`glab mr view <mr_id> --repo <repo_ref>`
Approve MR	`glab mr approve <mr_id> --repo <repo_ref>`
Check pipeline status	`glab ci status --repo <repo_ref>`
List pipelines	`glab ci list --repo <repo_ref>`
Retry a job	`glab ci retry <job_id> --repo <repo_ref>`
Add a note/comment	`glab mr note <mr_id> --repo <repo_ref> -m "<text>"`

For

--repo

, you can omit it if you're already inside the project directory (glab detects the remote automatically).

当用户请求的不是完整审核时，可直接通过

Bash

使用以下命令：

任务	命令
列出未关闭的MR	`glab mr list --repo <repo_ref>`
查看MR详情	`glab mr view <mr_id> --repo <repo_ref>`
批准MR	`glab mr approve <mr_id> --repo <repo_ref>`
检查流水线状态	`glab ci status --repo <repo_ref>`
列出流水线	`glab ci list --repo <repo_ref>`
重试任务	`glab ci retry <job_id> --repo <repo_ref>`
添加备注/评论	`glab mr note <mr_id> --repo <repo_ref> -m "<文本>"`

对于

--repo

参数，如果当前已在项目目录中，可省略（glab会自动检测远程仓库）。

Error Handling

错误处理

glab not authenticated: tell the user to run
```
glab auth login
```
glab command fails: output the review as conversation text instead of posting, explain what failed
Empty diff: note that the MR has no file changes and skip the review agents
Large diff (>500 lines): warn the user, proceed but note the review may miss details
Large single-line files (minified JS, large JSON): the view tool now shows partial content — note this in the review if such files are part of the diff

glab未认证：告知用户运行
```
glab auth login
```
glab命令执行失败：在对话中输出审核结果而非发布，并说明失败原因
空差异：说明MR没有文件变更，跳过审核代理
大差异（>500行）：提醒用户，继续执行但说明审核可能会遗漏细节
大单行文件（压缩后的JS、大JSON）：查看工具现在会显示部分内容 — 如果此类文件在差异中，需在审核中说明