Caveman 审查
- 作者仓库星标 68,344
- 作者仓库 caveman
Write code review comments terse and actionable. One line per finding. Location, problem, fix. No throat-clearing.
Rules
Format: L<line>: <problem>. <fix>. — or <file>:L<line>: ... when reviewing multi-file diffs.
Severity prefix (optional, when mixed):
🔴 bug:— broken behavior, will cause incident🟡 risk:— works but fragile (race, missing null check, swallowed error)🔵 nit:— style, naming, micro-optim. Author can ignore❓ q:— genuine question, not a suggestion
Drop:
- "I noticed that...", "It seems like...", "You might want to consider..."
- "This is just a suggestion but..." — use
nit:instead - "Great work!", "Looks good overall but..." — say it once at the top, not per comment
- Restating what the line does — the reviewer can read the diff
- Hedging ("perhaps", "maybe", "I think") — if unsure use
q:
Keep:
- Exact line numbers
- Exact symbol/function/variable names in backticks
- Concrete fix, not "consider refactoring this"
- The why if the fix isn't obvious from the problem statement
Examples
❌ "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).
Auto-Clarity
Drop terse mode for: security findings (CVE-class bugs need full explanation + reference), architectural disagreements (need rationale, not just a one-liner), and onboarding contexts where the author is new and needs the "why". In those cases write a normal paragraph, then resume terse for the rest.
Boundaries
Reviews only — does not write the code fix, does not approve/request-changes, does not run linters. Output the comment(s) ready to paste into the PR. "stop caveman-review" or "normal mode": revert to verbose review style.
- 流狐分类
- 工程开发
- 作者声明 Agent
- 未找到明确声明;不据此推断已兼容或已测试
- 静态检查
- 88 / 100 · 启发式扫描,不代表运行安全
- 作者 / 版本 / 许可
- @JuliusBrussee · 未声明 license
- 流狐 Token 估算
- 低消耗
- 流狐接入估算
- 即装即用
- 是否需要外部 API Key
- 未发现要求
- 检测到的系统要求
- 未声明
- 底层运行要求
- 未声明
- 检测到的文件与系统行为
-
- 只读
- 允许写入 / 修改
- 检测到的网络行为
- 仅限本地
- 安装命令数
- 无(仅作为资料)
档案由构建时根据 SKILL.md 与安装命令自动衍生,可能与作者实际意图存在差异。
需要注意: 未限定 allowed-tools,默认拥有全部工具权限。
作者没有在当前 SKILL.md 中定义固定输出样例。 Format: L<line>: <problem>. <fix>. — or <file>:L<line>: ... when reviewing multi-file diffs. Severity prefix (optional, when mixed): 🔴 bug: — broken behavior, will cause incident
❌ "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."
Drop terse mode for: security findings (CVE-class bugs need full explanation + reference), architectural disagreements (need rationale, not just a one-liner), and onboarding contexts where the author is new and needs the "why". In those cases write a normal…
Reviews only — does not write the code fix, does not approve/request-changes, does not run linters. Output the comment(s) ready to paste into the PR. "stop caveman-review" or "normal mode": revert to verbose review style.
Write code review comments terse and actionable. One line per finding. Location, problem, fix. No throat-clearing.
## Rules
**Format:** `L<line>: <problem>. <fix>.` — or `<file>:L<line>: ...` when reviewing multi-file diffs.
**Severity prefix (optional, when mixed):**
- `🔴 bug:` — broken behavior, will cause incident
- `🟡 risk:` — works but fragile (race, missing null check, swallowed error)
- `🔵 nit:` — style, naming, micro-optim. Author can ignore
- `❓ q:` — genuine question, not a suggestion
**Drop:**
- "I noticed that...", "It seems like...", "You might want to consider..."
- "This is just a suggestion but..." — use `nit:` instead
- "Great work!", "Looks good overall but..." — say it once at the top, not per comment
- Restating what the line does — the reviewer can read the diff
- Hedging ("perhaps", "maybe", "I think") — if unsure use `q:`
**Keep:**
- Exact line numbers
- Exact symbol/function/variable names in backticks
- Concrete fix, not "consider refactoring this"
- The *why* if the fix isn't obvious from the problem statement
## Examples
❌ "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).`
## Auto-Clarity
… 作者原文负责流程事实;流狐只索引当前章节、要点、文件与命令。
章节 -> Rules → Examples → Auto-Clarity → Boundaries
要点 -> Format · Severity prefix (optional, when mixed) · Drop · Keep
文件/命令 -> L<line>: <problem>. <fix>. · <file>:L<line>: ... · 🔴 bug: · 🟡 risk: · 🔵 nit: · ❓ q: · nit: · L42: 🔴 bug: user can be null after .find(). Add guard before .email.
内容 SHA-256 -> 045a9cbe4d51
原文结构
适用与边界
原文中的明确线索
L<line>: <problem>. <fix>.、<file>:L<line>: ...、🔴 bug:、🟡 risk:、🔵 nit:、❓ q:、nit:、L42: 🔴 bug: user can be null after .find(). Add guard before .email.