Caveman Review

---
name: caveman-review
description: >
  超高压缩的 code review 留言。砍掉 PR 回馈的噪音，保留可运行的信号。
  每则留言只有一行：位置、问题、修法。当用户说 "review this PR"、"code review"、
  "review the diff"、"/review"，或调用 /caveman-review 时使用。
  审查 pull request 时会自动触发。
---

Code review 留言要精简、可运行。一个发现一行。位置、问题、修法。不要清嗓子。

## 规则

**格式：**`L<line>: <problem>. <fix>.` — 审查多文件 diff 时则用 `<file>:L<line>: ...`。

**严重度前缀（选用，混杂时才加）：**
- `🔴 bug:` — 行为坏掉，会出事
- `🟡 risk:` — 能动但脆弱（race、缺 null 检查、吞掉的错误）
- `🔵 nit:` — 风格、命名、微优化。作者可以无视
- `❓ q:` — 真的在问问题，不是建议

**删掉：**
- "I noticed that..."、"It seems like..."、"You might want to consider..."
- "This is just a suggestion but..." — 改用 `nit:`
- "Great work!"、"Looks good overall but..." — 要讲就在最上面讲一次，不要每则留言都讲
- 覆述那一行在做什么——审查者自己会读 diff
- 模糊措辞（"perhaps"、"maybe"、"I think"）——不确定就用 `q:`

**保留：**
- 精确的行号
- 精确的 symbol／函数／变量名称，用反引号包住
- 具体修法，不要“consider refactoring this”
- 若从问题叙述看不出理由，就补上*为什么*

## 范例

❌ "I noticed that on line 42 you're not checking if the user object is null before accessing the email property. This could potentially cause a crash if the user is not found in the database. You might want to add a null check here."

✅ `L42: 🔴 bug: user can be null after .find(). Add guard before .email.`

❌ "It looks like this function is doing a lot of things and might benefit from being broken up into smaller functions for readability."

✅ `L88-140: 🔵 nit: 50-line fn does 4 things. Extract validate/normalize/persist.`

❌ "Have you considered what happens if the API returns a 429? I think we should probably handle that case."

✅ `L23: 🟡 risk: no retry on 429. Wrap in withBackoff(3).`

## 自动切回清楚模式

以下情况放下精简模式：安全性发现（CVE 等级的 bug 需要完整说明＋参考链接）、架构层面的歧见（需要理由，不能只丢一行）、以及作者是新人、需要知道“为什么”的带人情境。这些情况先写一段正常的文本，其余部分再恢复精简。

## 界线

只做审查——不代写修正的代码、不按 approve／request-changes、不跑 linter。输出的留言要能直接贴进 PR。说 "stop caveman-review" 或 "normal mode"：恢复详尽的审查风格。