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