code-reviewer
Use this skill to review code. It supports both local changes (staged or working tree) and remote Pull Requests (by ID or URL). It focuses on correctness, maintainability, and adherence to project standards.
71
56%
Does it follow best practices?
Impact
99%
1.54xAverage score across 3 eval scenarios
Advisory
Suggest reviewing before use
Optimize this skill with Tessl
npx tessl skill review --optimize ./.gemini/skills/code-reviewer/SKILL.mdQuality
Discovery
50%Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.
The description adequately conveys that this skill is for code review and supports both local and remote changes, which provides reasonable context. However, it lacks explicit trigger guidance ('Use when...'), misses common user-facing trigger terms like 'PR', 'diff', 'review my code', and the specific review actions are described in general terms rather than concrete outputs (e.g., 'identifies bugs, suggests refactors, checks style compliance').
Suggestions
Add an explicit 'Use when...' clause with natural trigger terms like 'review my code', 'PR review', 'check my diff', 'code review', 'review pull request', 'review changes'.
List more concrete review actions such as 'identifies bugs, suggests refactors, checks naming conventions, flags security issues' instead of abstract focus areas.
Include common file/term variations users might mention: 'PR', 'MR', 'merge request', 'diff', 'code changes', 'git diff'.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Names the domain (code review) and mentions some specific modes (local changes, staged/working tree, remote Pull Requests by ID or URL), but doesn't list concrete review actions beyond general focus areas like 'correctness, maintainability, and adherence to project standards'. | 2 / 3 |
Completeness | The 'what' is partially addressed (review code for correctness, maintainability, project standards) and the 'when' is somewhat implied by 'Use this skill to review code' but there is no explicit 'Use when...' clause with trigger conditions. The opening 'Use this skill to...' is close but not as explicit as a dedicated trigger guidance section. | 2 / 3 |
Trigger Term Quality | Includes some natural keywords like 'review code', 'Pull Requests', 'staged', and 'PR' (implied via 'Pull Requests'), but misses common variations users would say such as 'PR review', 'code review', 'diff', 'CR', 'merge request', or 'review my changes'. | 2 / 3 |
Distinctiveness Conflict Risk | Code review is a fairly specific niche, and the mention of Pull Requests and local changes helps distinguish it, but it could overlap with general coding assistance skills or linting/static analysis skills due to the broad 'correctness, maintainability' language. | 2 / 3 |
Total | 8 / 12 Passed |
Implementation
62%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This is a competent code review skill with a well-structured workflow that clearly distinguishes between remote PR and local change review paths. Its main weaknesses are explaining review concepts Claude already understands (correctness, maintainability, etc.) and lacking concrete examples of good review output. The workflow sequencing and feedback structure are strong points.
Suggestions
Remove or heavily condense the analysis pillars descriptions—Claude already knows what correctness, security, and maintainability mean. A simple bullet list of focus areas suffices.
Add a concrete example of expected review output (e.g., a sample finding with severity, file reference, and explanation) to make the feedback format actionable rather than abstract.
Consider extracting the detailed review criteria into a separate reference file and keeping only a concise checklist in the main skill.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill includes some unnecessary elaboration—e.g., explaining what correctness, maintainability, and readability mean, which Claude already knows. The analysis pillars section could be condensed to a bullet list without definitions. However, it's not egregiously verbose. | 2 / 3 |
Actionability | The skill provides concrete commands for git and gh CLI operations (checkout, diff, status), but the core review analysis section is descriptive rather than executable—it lists abstract qualities to check without concrete examples of what good feedback looks like or specific patterns to flag. | 2 / 3 |
Workflow Clarity | The workflow is clearly sequenced with numbered steps, branching paths for remote vs. local reviews, a preflight validation step before analysis, and a structured feedback format with severity tiers and a clear conclusion recommendation. The feedback loop is implicit but the validation checkpoint (preflight) is explicit. | 3 / 3 |
Progressive Disclosure | The content is well-structured with clear headers and subsections, but the analysis pillars section is fairly lengthy inline content that could be referenced separately. For a skill of this length (~80 lines), it's acceptable but the review criteria could be split into a reference file to keep the main skill leaner. | 2 / 3 |
Total | 9 / 12 Passed |
Validation
100%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 11 / 11 Passed
Validation for skill structure
No warnings or errors.
- Repository
- google-gemini/gemini-cli
- Commit
0758a5e
- Reviewed
Table of Contents
Is this your skill?
If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.