mr-review-resolve

name	mr-review-resolve
description	MR 评审意见处理技能。当作者收到 MR 评审评论后，给出 MR 地址，要求"和 AI 一起评估这些评审意见、决定哪些需要修正"时使用。skill 拉取未解决评论 → 按风险+主题分组 → 与用户逐条评估 → 用户决策处置 → （可选）AI 自动修复 → （可选）回写评论并标 resolved。适用于代码 MR 和 spec MR，spec MR 时自动关联本地 spec 文档辅助评估。

MR 评审意见处理（MR Review Resolve）

作者收到 MR 评审评论后，和用户一起逐条评估处置、（可选）让 AI 自动修复、（可选）回写评论并标 resolved。

何时使用

• 用户给出一个 MR 地址，并说"看看哪些要改"、"帮我评估这些评审意见"、"评论太多帮我梳理一下"、"哪些建议是对的"。
• 用户作为 MR 作者，想批量处理评审意见。

何时不使用

• 评审他人提交的 MR（用 mr-spec-review skill）。
• 不想看评论、只想直接改代码（用 feature-implementation skill）。

---

输入

参数	必选	来源	说明
MR 地址	是	用户提供	形如 <GIT-HOST>/<group>/<project>/-/merge_requests/<iid>
处理范围	否	默认未解决	可指定"包含已解决"或"只看某文件"

---

执行步骤

Step 1: 拉取 MR 上下文与评论

1. 解析 URL 得到 project_id 和 iid。
2. 调用Git 平台（GitHub / GitLab / 工蜂） MCP：
   • search_merge_request(project_id, iid) → 取 merge_request_id、source_branch、最新 source_commit、作者、状态、文件清单。
   • search_merge_request_notes(project_id, merge_request_id, resolve_states=[1], system=false, sort=created_asc, per_page=50) → 拉未解决的非系统评论（默认范围）。
   • 若用户要求看全部 → resolve_states 不传。
   • 评论很多时分页拉取（注意 per_page 上限）。
3. 辅助上下文（按需）：
   • get_merge_request_changes(...) → 拉取最新 diff（用于核对评论指向的代码是否已变更）。
   • get_commits_list(...) → commit 历史（用于判断"评论是否在某次修复之后又有新 commit"）。
4. 识别 MR 类型：
   • 若文件清单含 specs/<VERSION>/*.md → spec MR，记录 spec 路径用于 Step 3 关联本地文档。
   • 否则视为代码 MR。

Step 2: 评论数据归一化

把每条评论整理成统一结构（用于后续展示与处置）：

{
  note_id, parent_id（若为回复）,
  author, created_at,
  body（评论正文）,
  path, line, line_type（行内位置，可空）,
  risk（0-3）, resolve_state, labels,
  related_diff_snippet（从 diff 抽取的相邻 5-10 行代码，便于讨论）,
  is_stale（评论行在最新 diff 中是否已被改动）,
  is_thread_root（是否为评论串根节点）,
  replies[]（若已有作者回复，列出）
}

关键判定：

• is_stale：评论指向的 path:line 在最新 diff 中是否已被作者改过？若改过 → 候选"已修复"，但仍需用户确认实际是否对应。
• 串起 thread：把 parent_id 链上的所有回复合并展示。

Step 3: 关联本地资产

• spec MR：尝试读 specs/<VERSION>/<STORYID>-<slug>.md 完整内容，把"非目标 / 风险表（已 resolved）/ 修订记录"提取出来，用于判断评论是否与既有决议冲突。
• 代码 MR：尝试读评论 path 对应的本地文件最新内容（若本地有对应分支）。如本地代码与 MR diff 不一致 → 提示用户决定以哪边为准。
• 拉取仓库基线约定：docs/git-workflow.md、rules/20-coding-rules.md、rules/30-testing-rules.md、@security_rules。

Step 4: 评估每条评论（核心）

按以下维度逐条评估，得出 AI 初步建议（不是最终决定）：

维度	关注点
正确性	评审意见是否准确？有无误判、看了老版本代码、引用错位
重要性	风险等级（🔴 / 🟠 / 🟡）
改动成本	一行 / 数文件 / 大重构
修复风险	修复本身会不会引入新问题（如改字段名影响调用方）
范围契合	是否在本 MR 范围内？还是越权要求扩范围
历史决议冲突	是否与 spec「非目标」或「风险表 resolved 项」冲突
已修复检测	is_stale=true 时，结合 diff 判断是否已实际处理

每条评论给出推荐处置（六选一）：

处置	符号	含义
接受	✅	同意修正，给出具体修复方向
部分接受	🔄	折中方案（如简化版修复、加 TODO 标记不立即改）
拒绝	❌	给出理由（基于事实，非态度）
延后	⏸️	本 MR 不处理，记入下次迭代 / 留 TODO
澄清	💬	信息不足，建议向评审人追问
已修复	🟢	diff 显示已实际处理，直接 resolve

每条评论的初步建议必须包含：

1. 核心结论（一句话）
2. 理由（一句话，引用事实 / 代码 / spec 原文）
3. 修复方向（接受 / 部分接受时必填）
4. 预期回复语（投递时用，简短）

Step 5: 分组呈现（按风险等级 + 主题）

输出分组报告给用户，禁止直接调 MCP 写回复。报告结构：

# MR 评审处理建议：!{iid} {标题}

## 概览
- 评论总数：{N}（未解决 {X}，已解决 {Y}）
- 作者：@{author}
- 类型：spec MR / 代码 MR
- AI 初步分组：🔴 {a} / 🟠 {b} / 🟡 {c} / 🟢已修复 {d}

## 🔴 严重（{a} 条）

### #1 [path:line] 评审人 @xxx
> 评审原文：[≤30 字精简引用]

**AI 建议**：✅ 接受
- 理由：[一句话]
- 修复方向：[一句话]
- 预期回复：「{简短回复}」

### #2 ...

## 🟠 一般（{b} 条）
（按主题二级分组：安全 / 性能 / 边界 / 兼容性 / 命名 / i18n / 测试 ...）

### 主题：安全
#### #5 [path:line] ...

### 主题：i18n
#### #7 [path:line] ...

## 🟡 轻微（{c} 条）
...

## 🟢 疑似已修复（{d} 条）
（diff 显示作者已动相关代码，需用户确认是否对应）

#### #12 [path:line]
- diff 变化：[摘要]
- AI 建议：✅ 直接标 resolved 并回复「已修复，详见 commit xxx」

Step 6: 与用户澄清决策

明确询问用户三件事：

问题 1：批量决策 or 逐条决策？

你想： A. 全部接受 AI 初步建议 B. 按风险等级批量决策（如"接受全部 🔴+🟠，🟡 全拒绝"） C. 逐条决策（适合评论数 ≤ 10）

问题 2：对个别条目做调整？

比如：#3 我想改成"部分接受"、#7 改成"拒绝（理由是 ...）"

问题 3：处置完后的动作？

A. 仅生成处置清单（不调 MCP，我自己手动处理） B. AI 自动修复代码 / spec + 回复 MR 评论标 resolved C. 只回复 MR 评论标 resolved（不自动修复，我自己改代码）

⚠️ 等用户对三个问题都明确回答后才进入 Step 7。

Step 7: 执行（根据用户选择）

7.1 自动修复模式（用户选 B）

按用户确认的"接受 / 部分接受"清单，逐条进行代码修复：

1. 先汇总修复清单（一次性展示给用户最后确认）：

   即将进行的修复（{M} 项）：
   - #1 spec.md L77: 在「非目标」追加 `packages/iot/` 范围说明
   - #3 behaviorRecord/index.vue: 错误会话筛选改为 t-select 单选
   - ...
   

2. 再次确认："开始修复吗？(yes/no)"
3. 用户确认后调用 feature-implementation 风格的最小修改：
   • 优先 replace_in_file，避免重写大文件
   • 每条修复记录修改的文件 / 行号，用于后续回复评论时引用
4. 修复完成后提示用户检查：

   已完成 {M} 项修复：
   - #1 → 已修改 specs/v1.7.0/xxx.md（追加 3 行）
   - #3 → 已修改 src/.../behaviorRecord/index.vue（L140-L152）
   请用户自行 review 改动后告知是否进入 Step 7.2 回复评论。
   

⚠️ 跨仓库代码修复：先确认本地是否有对应分支 checkout；没有则报错让用户处理，不要硬猜。

7.2 回复评论模式（用户选 B 或 C）

调用 reply_merge_request_note 逐条回复 + 同时标 resolve_state：

回复内容规范（与 mr-spec-review 投递规范对称）：

处置类型	回复语模板	resolve_state
✅ 接受	感谢，已修复：{commit_sha 短哈希 / 文件 L行号}	2 (resolved)
🔄 部分接受	部分采纳：{方案简述}；{未采纳点 + 理由}	2 (resolved)
❌ 拒绝	不修改：{理由，引用 spec 非目标 / 既有约定 / 数据}	2 (resolved)
⏸️ 延后	本 MR 不处理，已记入 TODO/下个 spec：{链接或描述}	1 (unresolved，留作追踪)
💬 澄清	想澄清一下：{具体问题}	1 (unresolved)
🟢 已修复	已在 commit {sha} 处理，详见 {path:line}	2 (resolved)

回复规范：

• ✅ 简短：单条 ≤ 150 字符为佳，超过则砍。
• ✅ 有事实：引用具体 commit / 文件路径 / spec 原文，不要空话。
• ✅ 态度中性：拒绝时也要给出客观理由，不要带情绪。
• ❌ 不要复述评审意见（评审人能看到自己的原评论）。
• ❌ 不要说"已修复"但没真改（自动修复模式下必须有对应 commit / 文件改动）。
• ❌ 不要默认全部 resolved，⏸️ 延后和 💬 澄清类必须保持 unresolved。

投递顺序：

1. 按风险等级倒序（先 🔴 → 🟠 → 🟡 → 🟢），让评审人看到优先级。
2. 同等级内按 note_id 升序，保持时间顺序。
3. 并行批量发，但控制并发（避免触发限流，每批 5-10 条）。

7.3 仅清单模式（用户选 A）

输出一份 Markdown 清单到对话：

## MR !{iid} 处置清单（手动执行版）

| # | 风险 | 路径 | 处置 | 修复方向 | 回复语 |
|---|------|------|------|---------|--------|
| 1 | 🔴 | spec.md L77 | ✅ 接受 | 追加 packages/iot/ 范围说明 | 「已修复，详见 commit xxx」 |
| ... |

用户自己拿去执行，skill 在此结束。

Step 8: 收尾汇报

✅ 已处理 !{iid} 评审意见
  - 评估总数：{N}
  - 接受 {a} / 部分 {b} / 拒绝 {c} / 延后 {d} / 澄清 {e} / 已修复 {f}
  - 自动修复：{M} 项已完成（详见上方文件清单）
  - 回复评论：{K} 条已投递（{P} resolved，{Q} 保持 unresolved）

后续动作（提示用户）：
- [ ] review 自动修复改动
- [ ] commit + push 修复（可走 /spec-push）
- [ ] 跟进 unresolved 的澄清类评论

---

常见坑与对策

坑	对策
merge_request_id vs iid 混淆	先 search_merge_request 拿真实 id
system=true 的系统评论混入	system=false 过滤掉
评论 thread（评审人 + 作者已回复）	用 parent_id 串起来，避免重复评估父子评论
评论指向的代码已变更（is_stale）	候选"已修复"，但必须用户确认对应关系
跨仓库修复时本地无对应分支	不要硬猜，让用户先 clone / checkout
评审人是 leader / 强势角色	AI 评估只看事实，不要因身份偏向"接受"；用户自己决策
评论本身就是问题（如评审人误读）	AI 标 ❌ 拒绝 + 客观理由，让用户最终拍板
修复完忘了回复	Step 7.2 投递前再核对一遍清单
reply 限流	控制并发 5-10 条/批
同一 path:line 多条评论	合并讨论但分别回复（每条评论都有独立 note_id）

---

处置决策小贴士

AI 应该建议「✅ 接受」的典型场景

• 评审指出的事实错误（如字段名拼错、引用不存在的常量）
• 安全漏洞（XSS / SQLi / 鉴权缺失）—— 几乎无理由拒绝
• 评审引用了项目规则文档（rules/）并指出违反

AI 应该建议「❌ 拒绝」的典型场景

• 与 spec 「非目标」明确冲突（如评审要求做某事而 spec 已声明不做）
• 与 「风险表 resolved」决议冲突（已有共识的事被重新提起）
• 评审看错版本（基于老代码评的，已修过）
• 范围越权（要求做超出本 spec 的事，应另开 spec）

AI 应该建议「💬 澄清」的典型场景

• 评审意见模糊（"这里写得不清楚"但没说具体哪里）
• 评审基于错误假设（需要追问其依据）
• 多种修复方案需评审人选

AI 应该建议「⏸️ 延后」的典型场景

• 修复成本大、本 MR 截止时间紧
• 评审建议的是性能优化 / 重构，与本 MR 主线无关
• 需要跨团队协调（如后端改契约）

---

输出风险分级标准（沿用 mr-spec-review）

级别	适用情形	risk
🔴 严重	安全 / 破坏性变更 / 设备端不兼容 / 逻辑错误	3
🟠 一般	边界遗漏 / 性能隐患 / 字段不一致 / 灰度缺失	2
🟡 轻微	i18n 留白 / 命名 / 风格 / 缺测试要求	1

---

关联资产

• 依赖 MCP：
  • search_merge_request、search_merge_request_notes
  • get_merge_request_changes、get_commits_list
  • reply_merge_request_note（回复 + resolve 一步搞定）
  • update_merge_request_note（仅当需要修改已发评论时用）
• 关联规则：
  • rules/10-spec-workflow.md（spec 工作流，含偏离回流）
  • rules/20-coding-rules.md、rules/30-testing-rules.md
  • @security_rules（安全类评论评估必参考）
• 关联文档：
  • docs/git-workflow.md（仓库 / 基线分支对照）
• 关联 Skill：
  • mr-spec-review（评审他人 spec/plan/tasks MR，发出评论 → 本 skill 是其作者侧的镜像处理）
  • feature-implementation（自动修复时复用其修改规范）
  • code-review（评估代码类评论时可参考其维度表）

---

注意事项

❌ 不要做

• 不要未经用户三步确认（处置 / 调整 / 动作）就调 MCP。
• 不要在「已修复」回复里说谎（必须有真实 commit / 文件改动支撑）。
• 不要因评审人身份偏向"接受"（AI 评估只看事实）。
• 不要把 ⏸️ 延后 / 💬 澄清类评论标 resolved。
• 不要重写大文件，自动修复优先 replace_in_file。
• 不要遗漏 is_stale 检测（评论可能已过时）。

✅ 应该做

• 拉评论时默认 resolve_states=[1] + system=false。
• 每条评论给出事实型理由（引用 spec 原文 / 代码 / 规则文档）。
• 评论 thread 合并展示，避免割裂。
• 自动修复后给出文件 + 行号便于评审人 verify。
• 投递回复前最后一次展示清单给用户。
• 单条回复 ≤ 150 字符，简短直接。