Update to Caveman

{
  "name": "caveman-review",
  "description": "Use when the user asks for a focused review of a code diff or change using the Caveman workflow.",
  "included_files": [
    {
      "relative_path": "README.md",
      "size_in_bytes": 1210
    },
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 222
    }
  ],
  "skill_md_contents": "---\nname: caveman-review\ndescription: Use when the user asks for a focused review of a code diff or change using the Caveman workflow.\n---\n\nWrite code review comments terse and actionable. One line per finding. Location, problem, fix. No throat-clearing.\n\n## Rules\n\n**Format:** `L<line>: <problem>. <fix>.` — or `<file>:L<line>: ...` when reviewing multi-file diffs.\n\n**Severity prefix (optional, when mixed):**\n- `🔴 bug:` — broken behavior, will cause incident\n- `🟡 risk:` — works but fragile (race, missing null check, swallowed error)\n- `🔵 nit:` — style, naming, micro-optim. Author can ignore\n- `❓ q:` — genuine question, not a suggestion\n\n**Drop:**\n- \"I noticed that...\", \"It seems like...\", \"You might want to consider...\"\n- \"This is just a suggestion but...\" — use `nit:` instead\n- \"Great work!\", \"Looks good overall but...\" — say it once at the top, not per comment\n- Restating what the line does — the reviewer can read the diff\n- Hedging (\"perhaps\", \"maybe\", \"I think\") — if unsure use `q:`\n\n**Keep:**\n- Exact line numbers\n- Exact symbol/function/variable names in backticks\n- Concrete fix, not \"consider refactoring this\"\n- The *why* if the fix isn't obvious from the problem statement\n\n## Examples\n\n❌ \"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.\"\n\n✅ `L42: 🔴 bug: user can be null after .find(). Add guard before .email.`\n\n❌ \"It looks like this function is doing a lot of things and might benefit from being broken up into smaller functions for readability.\"\n\n✅ `L88-140: 🔵 nit: 50-line fn does 4 things. Extract validate/normalize/persist.`\n\n❌ \"Have you considered what happens if the API returns a 429? I think we should probably handle that case.\"\n\n✅ `L23: 🟡 risk: no retry on 429. Wrap in withBackoff(3).`\n\n## Auto-Clarity\n\nDrop 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.\n\n## Boundaries\n\nReviews 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."
}