agentsclimarketplace
Sign in

Code reviewer

Skill aiskillstore/marketplace/skills/google-gemini/code-reviewer

Security-audited skills for Claude, Codex & Claude Code. One-click install, quality verified.From the repository description

Install
npx -y skills add aiskillstore/marketplace --skill code-reviewer

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.

SKILL.md

3.1 KB, 658 tokens by cl100k_base, as published. Nobody here has run it

Code Reviewer

This skill guides the agent in conducting professional and thorough code reviews for both local development and remote Pull Requests.

Workflow

1. Determine Review Target

  • Remote PR: If the user provides a PR number or URL (e.g., "Review PR #123"), target that remote PR.
  • Local Changes: If no specific PR is mentioned, or if the user asks to "review my changes", target the current local file system states (staged and unstaged changes).

2. Preparation

For Remote PRs:

  1. Checkout: Use the GitHub CLI to checkout the PR. 
    gh pr checkout <PR_NUMBER>
  2. Preflight: Execute the project's standard verification suite to catch automated failures early. 
    npm run preflight
  3. Context: Read the PR description and any existing comments to understand the goal and history.

For Local Changes:

  1. Identify Changes:
    • Check status: git status
    • Read diffs: git diff (working tree) and/or git diff --staged (staged).
  2. Preflight (Optional): If the changes are substantial, ask the user if they want to run npm run preflight before reviewing.

3. In-Depth Analysis

Analyze the code changes based on the following pillars:

  • Correctness: Does the code achieve its stated purpose without bugs or logical errors?
  • Maintainability: Is the code clean, well-structured, and easy to understand and modify in the future? Consider factors like code clarity, modularity, and adherence to established design patterns.
  • Readability: Is the code well-commented (where necessary) and consistently formatted according to our project's coding style guidelines?
  • Efficiency: Are there any obvious performance bottlenecks or resource inefficiencies introduced by the changes?
  • Security: Are there any potential security vulnerabilities or insecure coding practices?
  • Edge Cases and Error Handling: Does the code appropriately handle edge cases and potential errors?
  • Testability: Is the new or modified code adequately covered by tests (even if preflight checks pass)? Suggest additional test cases that would improve coverage or robustness.

4. Provide Feedback

Structure

  • Summary: A high-level overview of the review.
  • Findings:
    • Critical: Bugs, security issues, or breaking changes.
    • Improvements: Suggestions for better code quality or performance.
    • Nitpicks: Formatting or minor style issues (optional).
  • Conclusion: Clear recommendation (Approved / Request Changes).

Tone

  • Be constructive, professional, and friendly.
  • Explain why a change is requested.
  • For approvals, acknowledge the specific value of the contribution.

5. Cleanup (Remote PRs only)

  • After the review, ask the user if they want to switch back to the default branch (e.g., main or master).

What ships with it: 1 file

14.9 KB alongside SKILL.md

Gives 0 of the 12 instructions most code review skills give in 658 tokens

Counted across 668 of the 814 authors here whose files we hold, read 2026-09-06

  • Provide technical reasoning when pushing backin 84 of 668, across 70 files
  • Fix critical issues immediatelyin 77 of 668, across 60 files
  • Dispatch a code reviewer subagentin 76 of 668, across 59 files
  • Fix important issues before proceedingin 73 of 668, across 56 files
  • Ask for clarification on unclear itemsin 68 of 668, across 56 files
  • Verify feedback against codebase before implementationin 66 of 668, across 55 files
  • Implement fixes one at a timein 64 of 668, across 53 files
  • Test each fix individuallyin 62 of 668, across 51 files
  • Restate technical requirements in own wordsin 57 of 668, across 46 files
  • Reply to inline comments in the specific threadin 51 of 668, across 40 files
  • Note minor issues for laterin 49 of 668, across 34 files
  • Group findings by severityin 48 of 668, across 47 files

Said here and by no other author read

  • Checkout remote pull requests using CLI
  • Run verification suite before reviewing
  • Identify local changes using git status
  • Provide clear approval or change request
  • Ask to switch branches after remote review

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.

Keep looking

Skills are one crate of 325,949. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.