审查 PR/diff 时：用一行一条的压缩代码审查意见快速指…

适用于 /caveman-review、review this PR 或 review the diff 时，生成简洁、可操作、可直接粘贴到 PR 的代码审查评论。

适用场景

解决思路

1. 写代码审查评论时保持简洁、可操作：每条发现一行，包含位置、问题、修复，不要开场白。
2. 格式使用 `L<line>: <problem>. <fix>.`；审查多文件 diff 时使用 `<file>:L<line>: ...`。
3. 当严重性混合时，可选地使用严重性前缀。
4. 用 `🔴 bug:` 标记破坏行为，会导致事故。
5. 用 `🟡 risk:` 标记能工作但脆弱，例如竞态、缺少 null 检查、吞掉错误。
6. 用 `🔵 nit:` 标记风格、命名、微优化；作者可以忽略。
7. 用 `❓ q:` 标记真正的问题，而不是建议。
8. 删除 `I noticed that...`、`It seems like...`、`You might want to consider...` 这类开头。
9. 删除 `This is just a suggestion but...`，改用 `nit:`。
10. 删除 `Great work!`、`Looks good overall but...`；只在顶部说一次，不要每条评论都说。
11. 删除复述该行代码做什么；审查者可以读 diff。
12. 删除模糊措辞（`perhaps`、`maybe`、`I think`）；如果不确定用 `q:`。
13. 保留精确行号。
14. 保留反引号中的精确 symbol/function/variable 名称。
15. 保留具体修复，不要写 `consider refactoring this`。
16. 如果修复从问题描述不明显，保留 why。
17. 示例改写：把冗长评论改成 `L42: 🔴 bug: user can be null after .find(). Add guard before .email.`。
18. 示例改写：把冗长评论改成 `L88-140: 🔵 nit: 50-line fn does 4 things. Extract validate/normalize/persist.`。
19. 示例改写：把冗长评论改成 `L23: 🟡 risk: no retry on 429. Wrap in withBackoff(3).`。
20. 遇到安全发现（CVE 类 bug）时放弃简洁模式，写完整解释和引用。
21. 遇到架构分歧时放弃简洁模式，写理由，而不是一句话。
22. 遇到 onboarding 上下文且作者是新人、需要 why 时放弃简洁模式，写正常段落。
23. 在安全发现、架构分歧、onboarding 这些例外之后，对剩余评论恢复简洁模式。
24. 只做审查：不写代码修复，不批准/请求变更，不运行 linters。
25. 输出可直接粘贴到 PR 的评论。
26. 当用户说 `stop caveman-review` 或 `normal mode` 时，恢复冗长审查风格。

适用边界 · 注意事项

• 安全发现（CVE 类 bug）需要完整解释和引用时，不适用简洁模式；应切换为正常段落。
• 架构分歧需要理由，或新人 onboarding 需要 why 时，不适用简洁模式；应切换为正常段落。
• 不适用于写代码修复、批准/请求变更、运行 linters；这些不在本技能范围内。