GitLab Resolve

Overview

逐一处理 GitLab MR 中的评论线程，按难易程度分类后规划执行任务，用户确认计划后按任务顺序依次解决并提交。

Workflow

Step 1: 确认 MR 与当前分支一致

获取当前分支并与目标 MR 的源分支对比：

# 获取当前分支
git branch --show-current

# 获取 MR 的源分支
glab mr view <MR_ID> --output json | jq -r '.source_branch'

若当前分支与 MR 的源分支不一致，提示用户：

• 确认 MR ID 是否正确
• 或切换到对应分支：git checkout <source-branch>

用户确认后再继续。

Step 2: 获取 MR 评论

使用当前 skill 的 scripts 目录中的 fetch_discussions.sh <MR_ID> 拉取所有未处理的讨论线程, 执行脚本时不要输出结果到控制台。

脚本自动获取 URL 编码的项目路径并调用 glab api --paginate，输出过滤后的讨论线程 JSON 列表。

过滤条件：首条 note 的 type == "DiffNote"、resolvable == true、resolved == false，只保留未解决的 diff 评论线程。每条线程包含 discussion_id（用于后续 API resolve）、author、comment、position（文件与行号）、replies（回复列表）。

前置依赖：需安装 glab、jq、uv（用于执行 Python 脚本）。

获取评论的错误和结果处理

• 若未提供 MR ID，询问用户。
• 若命令失败，提示用户检查 glab auth status 和项目权限。
• 如果获取到 JSON 列表，继续下一步。
• 如果是空列表，提示用户 MR 中没有未处理的 diff 评论线程，结束流程。

Step 3: 分析并分类问题

按难度分类：

| 难度 | 描述 | 示例 | |------|------|------| | 简单 | 直接回答或小改动 | typo、添加注释、重命名 | | 中等 | 需要分析，涉及逻辑调整 | 函数修改、逻辑重构 | | 复杂 | 需深入分析，可能影响架构 | 设计变更、跨模块改动 | | 其他 | 无需代码修改 | 已过期、需继续讨论 |

Step 4: 规划执行任务

难度和合并是两个独立维度：

• 合并只能发生在同一难度内，跨难度问题不可合并
• 将同一难度下关联紧密的问题合并为一个执行任务（如同一文件的多个 typo、同一模块的相关修改）
• 复杂问题默认不合并，除非关联极为明显且改动范围确定
• commit 时机由用户决定，可单个任务提交，也可多个任务完成后统一提交

Step 5: 展示分类概览

按难度分组展示所有问题，供用户了解全貌：

简单问题

| # | Thread ID | 问题摘要 | 解决方案 | |---|-----------|---------|---------| | 1 | #<id> | <摘要> | <方案，如：直接修正、添加注释> |

中等问题

| # | Thread ID | 问题摘要 | 解决方案 | |---|-----------|---------|---------| | 1 | #<id> | <摘要> | <方案，如：需要深入分析、重构逻辑> |

复杂问题

| # | Thread ID | 问题摘要 | 解决方案 | |---|-----------|---------|---------| | 1 | #<id> | <摘要> | <方案，如：需继续讨论、涉及架构调整> |

其他问题

| # | Thread ID | 问题摘要 | 解决方案 | |---|-----------|---------|---------| | 1 | #<id> | <摘要> | <方案，如：已过期、无需处理> |

所有难度组必须展示，无对应问题时表格内容显示一行 - | - | 暂无 | -。

Step 6: 展示执行任务计划

将问题组织为有序的执行任务（Task），每个 Task 修复完成后可提交，也可跳过等多个 Task 完成后统一提交：

| 任务 | 难度 | 包含问题 | 修复说明 | |------|------|---------|---------| | Task 1 | 简单 | #12, #15 | 修正两处 typo | | Task 2 | 简单 | #18 | 添加缺失注释 | | Task 3 | 中等 | #22 | 重构校验逻辑 | | Task 4 | 复杂 | #31 | 调整错误处理架构 | | Task 5 | 复杂 | #35 | 优化模块依赖关系 |

展示后等待用户确认或调整，用户可以：

• 拆分某个 Task（将合并的问题分开）
• 合并某些 Task（前提：同一难度）
• 调整执行顺序

Step 7: 按任务顺序循环执行

用户确认计划后，严格按 Task 顺序逐一执行，不得跳跃或乱序。立即从 Task 1 开始，每个 Task 无论是第几个，都必须独立展示方案并等待用户确认后才能执行——Step 6 的整体计划确认不能替代每个 Task 的执行确认。

每个 Task 的执行流程

1. 展示当前 Task 的问题详情和建议的解决方案
2. 等待用户响应，用户可以：
   • 直接确认方案，进入执行
   • 对方案提出细节调整或进行讨论，直到用户明确确认后才执行
   • 跳过当前 Task
3. 用户确认后，实施修改
4. 验证修改是否正确（以下均通过才可继续）：
   • 编译通过：确保项目可以正常构建
   • 单元测试通过：运行受影响模块的相关测试
   • 若验证失败，修复问题后重新验证，不得跳过此步骤
5. 使用 git-commit skill 生成 commit 信息；若不可用，直接运行 git commit
   • commit 内容为当前仓库所有未提交的变更（可能包含多个 Task 的修改）
   • Footer 列出本次 commit 涵盖的所有 thread：Resolve #<id1>, #<id2>, #<id3>
   • 示例：Resolve #12, #15, #18 修正 typo 并添加注释
6. 等待用户确认是否提交：
   • 确认：执行提交，再展示下一个 Task
   • 跳过：不提交，直接继续下一个 Task 的修复，累积变更留待后续统一提交

严禁在完成修复或 commit 后自动跳入下一个 Task 的修复执行。每个 Task 必须经过用户明确确认方案后才能开始实施。

Step 8: 展示执行汇总

所有 Task 执行完毕后，展示汇总表格：

| 任务 | 难度 | 包含问题 | 状态 | 备注 | |------|------|---------|------|------| | Task 1 | 简单 | #12, #15 | ✅ 已完成 | commit abc1234 | | Task 2 | 简单 | #18 | ⏭️ 已跳过 | 用户跳过 | | Task 3 | 中等 | #22 | ✅ 已完成 | commit def5678 | | Task 4 | 复杂 | #31 | ✅ 已完成 | commit ghi9012 |

汇总统计：

• 已完成：X 个 Task（涉及 N 个问题）
• 已跳过：X 个 Task（涉及 N 个问题）
• 总计：X 个 Task

展示汇总后，询问用户是否对本次所有变更进行整体 code review：

本次共完成 X 个 Task 的修改，是否需要对所有变更做一次整体 code review？

若用户确认，使用 git diff <first-commit>^..HEAD 展示本次全部改动，并逐文件进行 review 分析。

错误处理

• glab 命令失败：提示检查 glab auth status 和网络连接
• 无未解决线程：告知用户所有线程已解决
• 权限不足：提示用户确认是否有该项目的访问权限