| 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 工具读取指定报告全文。提取以下关键信息:
- 审查范围:Phase/模块、涉及的文件
- 用户意见:
## 📋 用户意见(必须遵从) 章节的内容(如有)
- 问题汇总表:
## 问题汇总 章节中的每一行(序号、任务、问题、严重度、建议)
Step 2:逐项核实
对问题汇总表中的每一条,执行以下操作:
- 定位代码:根据问题描述找到对应源文件和行号
- 阅读源码:用 Read 工具读取相关代码上下文
- 判断结论:归入以下四类之一
| 结论标记 | 含义 | 何时使用 |
|---|
| ✅ 已修复 | 问题确实存在,本次已修改代码修复 | 问题有效且应立即修复 |
| ❌ 审查有误 | 审查者的判断有误,代码实际行为正确 | 审查者误解了代码逻辑或遗漏了上下文 |
| 🟡 已知取舍 | 问题存在但属于已知设计决策,当前不改 | MVP 阶段可接受的 trade-off |
| ⏸️ 延后 | 问题有效但优先级低,留待后续 Phase 处理 | Phase 2+ 再优化 |
核实原则:
- 必须以实际代码为准,不能仅凭审查报告的文字描述下结论
- 对「审查有误」的结论,必须在回执中给出具体的代码证据(文件:行号)
- 对「已修复」的结论,必须实际修改代码并验证
Step 3:处理用户意见
如果报告中 ## 📋 用户意见 章节有具体内容(非空):
- 逐条理解用户的决策意图
- 按用户意见执行代码修改(用户意见具有最高优先级)
- 在回执中记录每条意见的落地情况
如果用户意见章节为空或仅有占位说明文字,则跳过此步。
Step 4:执行修改(如有)
对需要修复的问题:
- 用 Edit 工具修改源码
- 运行
cargo check -p <crate> 确认编译通过
- 运行
cargo test -p <crate> 确认测试通过
- 运行
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 的最终状态
注意事项
- 不要盲目修复:审查者可能遗漏上下文。先理解代码意图,再决定是否修改。
- 不要修改无关代码:只修改与审查问题直接相关的代码。不要顺手重构。
- 保持回执简洁:每个问题的「处理」列用一句话说明,不要长篇大论。
- 用中文撰写:回执全文使用中文,代码引用保持英文。
- 先核实再修改:不要跳过 Step 2 直接改代码。先确认问题真实存在。