reply-review

name	reply-review
description	阅读代码审查报告，逐项核实问题，决定是否需要修改， 并在报告末尾追加「报告回执」章节。 当用户说"写回执"、"回复审查"、"处理 review"时触发。
license	MIT
compatibility	Hit 项目
metadata	{"author":"QoderCN","version":"1.0.0"}
allowed-tools	Read Edit Bash(cargo:*) Bash(git:*) Glob Grep
user_invocable	true
disable_model_invocation	false

Reply Review — 审查报告回执

阅读指定的代码审查报告，逐项核实每个问题，决定是否需要修改代码，并在报告末尾追加「报告回执」章节。

---

输入

通过 $ARGUMENTS 传入审查报告路径（如 docs/review/REVIEW_1.3.md）。 若未传入，提示用户指定报告文件路径，或用 Glob 扫描 docs/review/REVIEW_*.md 列出候选。

---

工作流程

Step 1：读取审查报告

用 Read 工具读取指定报告全文。提取以下关键信息：

1. 审查范围：Phase/模块、涉及的文件
2. 用户意见：## 📋 用户意见（必须遵从） 章节的内容（如有）
3. 问题汇总表：## 问题汇总 章节中的每一行（序号、任务、问题、严重度、建议）

Step 2：逐项核实

对问题汇总表中的每一条，执行以下操作：

1. 定位代码：根据问题描述找到对应源文件和行号
2. 阅读源码：用 Read 工具读取相关代码上下文
3. 判断结论：归入以下四类之一

结论标记	含义	何时使用
✅ 已修复	问题确实存在，本次已修改代码修复	问题有效且应立即修复
❌ 审查有误	审查者的判断有误，代码实际行为正确	审查者误解了代码逻辑或遗漏了上下文
🟡 已知取舍	问题存在但属于已知设计决策，当前不改	MVP 阶段可接受的 trade-off
⏸️ 延后	问题有效但优先级低，留待后续 Phase 处理	Phase 2+ 再优化

核实原则：

• 必须以实际代码为准，不能仅凭审查报告的文字描述下结论
• 对「审查有误」的结论，必须在回执中给出具体的代码证据（文件:行号）
• 对「已修复」的结论，必须实际修改代码并验证

Step 3：处理用户意见

如果报告中 ## 📋 用户意见 章节有具体内容（非空）：

1. 逐条理解用户的决策意图
2. 按用户意见执行代码修改（用户意见具有最高优先级）
3. 在回执中记录每条意见的落地情况

如果用户意见章节为空或仅有占位说明文字，则跳过此步。

Step 4：执行修改（如有）

对需要修复的问题：

1. 用 Edit 工具修改源码
2. 运行 cargo check -p <crate> 确认编译通过
3. 运行 cargo test -p <crate> 确认测试通过
4. 运行 cargo clippy -p <crate> --all-targets 确认无新增 warning

Step 5：运行验证

无论是否有代码修改，都执行全量验证：

cargo check --workspace
cargo test --workspace
cargo clippy -p <涉及的crate> --all-targets

记录测试结果（通过数/失败数/忽略数）。

Step 6：撰写报告回执

在审查报告文件末尾追加「报告回执」章节，使用下方模板。

Step 7：提交

如果有代码修改：

git add <修改的文件>
git commit -m "fix: 根据审查报告修复 <Phase> 问题"

追加回执后单独提交：

git add docs/review/REVIEW_*.md
git commit -m "docs: 添加 Phase <N> 审查报告回执"

---

报告回执模板

追加到审查报告文件末尾，用 --- 分隔：

---

# 报告回执

**审查时间**：<报告中的审查日期>
**回执人**：QoderCN（代码作者）

## 用户意见落地

> 仅当报告中有具体用户意见时包含此节，否则省略。

| # | 决策 | 状态 | 实施要点 |
|---|------|:----:|----------|
| 1 | 用户意见摘要 | ✅ 已落地 | 具体修改说明 |

## 逐项核实

| # | 问题 | 核实结论 | 处理 |
|---|------|----------|------|
| 1 | 问题摘要 | 结论标记 + 一句话理由 | 已修复 / 不改 / 不改（Phase N） |

## 验证

修改后全量验证：

- `cargo check --workspace` — ✅/❌
- `cargo test --workspace` — N/N ✅
- `cargo clippy` — N warning(s)

可选附加章节

根据实际情况，在「验证」之后追加：

• 测试覆盖提升：如果修复过程中新增了测试，列出修改前后的测试数量对比
• 值得注意的技术细节：如果核实过程中发现了审查者未提及的有趣技术点
• Phase 最终结论：一句话总结该 Phase 的最终状态

---

注意事项

1. 不要盲目修复：审查者可能遗漏上下文。先理解代码意图，再决定是否修改。
2. 不要修改无关代码：只修改与审查问题直接相关的代码。不要顺手重构。
3. 保持回执简洁：每个问题的「处理」列用一句话说明，不要长篇大论。
4. 用中文撰写：回执全文使用中文，代码引用保持英文。
5. 先核实再修改：不要跳过 Step 2 直接改代码。先确认问题真实存在。