| 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 上下文与评论
- 解析 URL 得到
project_id 和 iid。
- 调用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 上限）。
- 辅助上下文（按需）：
get_merge_request_changes(...) → 拉取最新 diff（用于核对评论指向的代码是否已变更）。get_commits_list(...) → commit 历史（用于判断"评论是否在某次修复之后又有新 commit"）。
- 识别 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 |
每条评论的初步建议必须包含：
- 核心结论（一句话）
- 理由（一句话，引用事实 / 代码 / spec 原文）
- 修复方向（接受 / 部分接受时必填）
- 预期回复语（投递时用，简短）
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）
按用户确认的"接受 / 部分接受"清单，逐条进行代码修复：
- 先汇总修复清单（一次性展示给用户最后确认）：
即将进行的修复（{M} 项）：
- #1 spec.md L77: 在「非目标」追加 `packages/iot/` 范围说明
- #3 behaviorRecord/index.vue: 错误会话筛选改为 t-select 单选
- ...
- 再次确认："开始修复吗？(yes/no)"
- 用户确认后调用
feature-implementation 风格的最小修改：
- 优先
replace_in_file，避免重写大文件
- 每条修复记录修改的文件 / 行号，用于后续回复评论时引用
- 修复完成后提示用户检查：
已完成 {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。
投递顺序：
- 按风险等级倒序（先 🔴 → 🟠 → 🟡 → 🟢），让评审人看到优先级。
- 同等级内按
note_id 升序，保持时间顺序。
- 并行批量发，但控制并发（避免触发限流，每批 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_notesget_merge_request_changes、get_commits_listreply_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 字符，简短直接。
