关于 caveman-review
用于编写简短、可执行代码审查评论的技能，面向需要将审查发现整理为可直接贴入 PR 评论的开发者。它要求指出位置、问题和修复方式，并区分错误、风险、细节和疑问。
主要功能
- 01每条发现限制为一行
- 02标明代码位置与具体修复
- 03支持错误、风险、细节和疑问标签
- 04安全与架构问题可使用完整说明
- 05仅输出审查评论，不修改代码
适用场景
- 01将代码审查发现整理为 PR 评论
- 02指出缺少空值检查或错误处理
- 03为脆弱逻辑提供明确修复建议
- 04在需要时切换回常规审查风格
安装
复制下面的命令，在终端中运行。
npx skills add https:/安装后在 Claude Code 中输入/caveman-review确认已加载。
附带文件README.md
详细介绍
代码评审评论应简洁且可执行。每条发现占一行。包括位置、问题和修复方案。不要有任何铺垫。
规则
格式： L<line>: <problem>. <fix>.，在评审多文件 diff 时使用 <file>:L<line>: ...。
严重程度前缀（可选，混合使用时）：
🔴 bug:— 行为错误，会引发事故🟡 risk:— 能运行但脆弱（竞态、缺少 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:
保留：
- 精确的行号
- 精确的符号、函数、变量名，用反引号包裹
- 具体的修复方案，而不是"考虑重构这里"
- 如果从问题描述看不出修复方式，保留原因
示例
❌ "我注意到第 42 行在访问 email 属性之前没有检查 user 对象是否为 null。如果数据库中找不到该用户，这可能会导致崩溃。你可能需要在这里加一个 null 检查。"
✅ L42: 🔴 bug: user can be null after .find(). Add guard before .email.
❌ "这个函数做了太多事情，拆分成更小的函数可能会提高可读性。"
✅ L88-140: 🔵 nit: 50-line fn does 4 things. Extract validate/normalize/persist.
❌ "你有没有考虑过 API 返回 429 时会怎样？我觉得我们应该处理这种情况。"
✅ L23: 🟡 risk: no retry on 429. Wrap in withBackoff(3).
自动清晰模式
以下情况取消简洁模式：安全问题（CVE 级别的缺陷需要完整说明并附参考）、架构分歧（需要理由，不能只是一行）、以及新人入职场景，即作者是新手且需要"为什么"。这些情况下先写一段正常段落，其余部分再恢复简洁。
边界
仅做评审——不编写代码修复，不批准或请求修改，不运行 linter。输出可直接粘贴到 PR 中的评论。"stop caveman-review"或"normal mode"：恢复为详细的评审风格。