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.
67
50%
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 communicates the core purpose (code review) and distinguishes between local and remote review modes, which is helpful. However, it lacks an explicit 'Use when...' clause with natural trigger terms, and the review actions described are high-level rather than concrete. It also uses second-person framing ('Use this skill') rather than third-person voice, though this is borderline since it's instructional rather than 'you can use this'.
Suggestions
Add an explicit 'Use when...' clause with natural trigger terms like 'review my code', 'PR review', 'check my diff', 'review pull request', 'code feedback'.
List more concrete review actions such as 'identifies bugs, suggests refactors, checks for security issues, flags style violations' to improve specificity.
Rephrase to third person voice, e.g., 'Reviews code for correctness, maintainability, and adherence to project standards. Supports both local changes (staged or working tree) and remote Pull Requests (by ID or URL).'
| 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 addressed (review code for correctness, maintainability, project standards) and there's an implicit 'when' via 'Use this skill to review code', but there's no explicit 'Use when...' clause with trigger scenarios or terms. Per rubric guidelines, missing explicit trigger guidance caps this at 2. | 2 / 3 |
Trigger Term Quality | Includes some natural keywords like 'review code', 'Pull Requests', 'staged', and 'PR' (implied via 'Pull Requests'), but misses common user variations like 'PR review', 'code review', 'diff', 'CR', or 'review my changes'. Coverage is partial. | 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 'correctness, maintainability, and adherence to project standards' is generic enough to overlap with linting, static analysis, or general coding assistance skills. | 2 / 3 |
Total | 8 / 12 Passed |
Implementation
50%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 but somewhat generic code review skill. Its strengths are a clear workflow structure with concrete CLI commands for the preparation phase. Its weaknesses are verbosity in explaining review concepts Claude already understands (correctness, maintainability, etc.), lack of concrete example outputs showing what a good review looks like, and missing validation/error-handling checkpoints in the workflow.
Suggestions
Remove or drastically condense the analysis pillars in Step 3 — Claude already knows how to evaluate correctness, security, etc. Instead, focus on project-specific patterns or anti-patterns to watch for.
Add a concrete example of a complete review output (summary, findings with specific code references, conclusion) so Claude knows the exact format expected.
Add validation checkpoints: what to do if `gh pr checkout` fails, what to do if preflight fails (stop review? continue with caveats?), and an explicit re-review loop.
Consider extracting the feedback format/tone guidelines into a separate reference file to keep SKILL.md focused on the workflow.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill includes some unnecessary explanation (e.g., the analysis pillars like 'Correctness', 'Maintainability' are concepts Claude already knows well). The tone guidance section is also largely redundant. However, the workflow steps and commands are reasonably efficient. | 2 / 3 |
Actionability | Provides concrete commands for git and gh CLI operations (e.g., `gh pr checkout`, `git diff --staged`), but the core review analysis section (Step 3) is entirely descriptive rather than providing concrete examples of review comments or specific patterns to look for. The feedback structure is a template but lacks an actual example output. | 2 / 3 |
Workflow Clarity | The workflow is clearly sequenced with numbered steps and a logical flow from target determination through cleanup. However, there are no validation checkpoints or feedback loops — for instance, no step to verify the checkout succeeded, no guidance on what to do if preflight fails, and no explicit re-review cycle after changes are requested. | 2 / 3 |
Progressive Disclosure | The content is reasonably well-structured with clear headers and subsections, but it's somewhat monolithic — the analysis pillars and feedback structure could be split into referenced files. With no bundle files provided, there's no progressive disclosure to external references, and the inline content is borderline too detailed for a single SKILL.md. | 2 / 3 |
Total | 8 / 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.
77e65c0
Table of Contents
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.