Skill Market

caveman review

Ultra-compressed code review comments. Cuts noise from PR feedback while preserving the actionable signal. Each comment is one line: location, problem, fix. Use when user says "review this PR", "code review", "review the diff", "/review", or invokes /caveman-review. Auto-triggers when reviewing pull requests.

GitHub
githubcommunityaianthropiccavemanclaudeclaude-codellm
0.0
0 installs105.6K GitHub starsby JuliusBrussee

Skill Introduction

Overview
Ultra-compressed code review comments. Cuts noise from PR feedback while preserving the actionable signal. Each comment is one line: location, problem, fix. Use when user says "review this PR", "code review", "review the diff", "/review", or invokes /caveman-review. Auto-triggers when reviewing pull requests.

Core value

Turns reusable Debugging know-how into an installable skill, helping users complete github, community, ai, anthropic work faster.

Target users

  • Developers, testers, and maintainers who handle Debugging tasks in Focus Code.
  • Teams that already trust workflows or content from JuliusBrussee.
  • Users who want standardized prompts, steps, or conventions instead of repeating setup work.

Best practices

  • Read the skill content first to confirm required inputs, expected outputs, and dependencies.
  • Try it on a small task before relying on it for critical work.
  • Add project-specific constraints such as coding style, target platform, test expectations, and delivery format.
  • For external sources, verify the source link, version, and recent maintenance activity.

Best use cases

  • Tasks related to github, community, ai, anthropic that need a reusable execution flow.
  • Converting a community repo, team convention, or personal workflow into day-to-day assistance.
  • Starting from a proven skill instead of writing prompts or procedures from scratch.

Limits and boundaries

  • Results depend on the quality of the original skill content and may need human correction.
  • It does not replace code review, tests, security review, or professional judgment.
  • External tools, APIs, account permissions, and local dependencies still need separate setup.

Differentiation

  • Structured around Debugging, making it easier to discover and reuse than loose prompt snippets.
  • Marked as GitHub, which helps users judge trust and maintenance expectations.
  • Keeps the original source link available for repository, documentation, or discussion follow-up.
  • Tagged with github, community, ai, anthropic, so it can be filtered by concrete task intent.

Install and use

Install
Copy Install Command
focus install caveman-review-778349
View source

Detail Preview

SKILL.md

Primary filemarkdown3 KB

name: caveman-review description: > Ultra-compressed code review comments. Cuts noise from PR feedback while preserving the actionable signal. Each comment is one line: location, problem, fix. Use when user says "review this PR", "code review", "review the diff", "/review", or invokes /caveman-review. Auto-triggers when reviewing pull requests.

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.

Reviews

Overall rating

0.0
0.0

0 comments

No reviews yet