Conduct high-quality, persona-driven code reviews. Use when reviewing PRs, critiquing code quality, or analyzing changes for team feedback.
64
77%
Does it follow best practices?
Impact
—
No eval scenarios have been run
Passed
No known issues
Optimize this skill with Tessl
npx tessl skill review --optimize ./.github/skills/common/common-code-review/SKILL.mdQuality
Discovery
82%Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.
This is a solid description that clearly communicates both what the skill does and when to use it, with good trigger terms that developers would naturally use. Its main weaknesses are the somewhat vague 'persona-driven' qualifier that isn't explained, and the lack of more specific concrete actions beyond the general 'code review' umbrella. The description could also be more distinctive to avoid overlap with general code analysis skills.
Suggestions
Elaborate on what 'persona-driven' means concretely (e.g., 'simulates reviewers with different expertise like security, performance, readability') to improve specificity and distinctiveness.
Add more specific concrete actions such as 'identifies bugs, suggests refactors, checks naming conventions, evaluates error handling' to strengthen specificity.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Names the domain (code reviews) and mentions some actions like 'reviewing PRs', 'critiquing code quality', and 'analyzing changes', but doesn't list specific concrete actions like checking for security issues, suggesting refactors, evaluating test coverage, etc. 'Persona-driven' is somewhat vague without elaboration. | 2 / 3 |
Completeness | Clearly answers both what ('Conduct high-quality, persona-driven code reviews') and when ('Use when reviewing PRs, critiquing code quality, or analyzing changes for team feedback') with an explicit 'Use when...' clause. | 3 / 3 |
Trigger Term Quality | Includes strong natural trigger terms users would say: 'code reviews', 'PRs', 'code quality', 'changes', 'team feedback'. These are terms developers naturally use when requesting review help. | 3 / 3 |
Distinctiveness Conflict Risk | While 'code reviews' and 'PRs' are fairly specific, terms like 'code quality' and 'analyzing changes' could overlap with general code analysis or linting skills. The 'persona-driven' aspect adds some distinctiveness but isn't well-defined enough to fully differentiate. | 2 / 3 |
Total | 10 / 12 Passed |
Implementation
72%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This is a well-structured, concise skill that effectively defines a code review persona with clear severity classifications and a mandatory checklist. Its main weakness is the lack of concrete, worked examples showing a real review comment applied to actual code, which would significantly improve actionability. The workflow could also benefit from an explicit end-to-end sequence with a completeness verification step.
Suggestions
Add a concrete worked example showing a real code snippet and the corresponding review comment using the [SEVERITY] output format, so Claude can see exactly what a good review looks like.
Add an explicit end-to-end workflow (e.g., 1. Read the diff 2. Run through checklist 3. Produce output 4. Verify all checklist items addressed) to improve workflow clarity.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | Every line earns its place. No unnecessary explanations of what code review is or how it works. Assumes Claude's competence as a principal engineer and provides only the operational constraints and structure needed. | 3 / 3 |
Actionability | The checklist and severity classification are concrete, and the output format template is specific. However, the guidance remains somewhat high-level—there are no concrete code examples showing a real review comment applied to actual code, and the 'Fix' line in the output format is described rather than demonstrated with a real example. | 2 / 3 |
Workflow Clarity | The checklist provides a clear sequence of what to check, and the output format defines how to report findings. However, there's no explicit workflow for how to conduct the review end-to-end (e.g., read diff → run checklist → produce output → verify completeness), and no validation/verification step to ensure all checklist items were actually addressed. | 2 / 3 |
Progressive Disclosure | The skill is concise with a clear overview and well-signaled one-level-deep references to references/checklist.md and references/output-format.md. Content is appropriately split between the main skill and supporting files. | 3 / 3 |
Total | 10 / 12 Passed |
Validation
81%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 9 / 11 Passed
Validation for skill structure
| Criteria | Description | Result |
|---|---|---|
metadata_version | 'metadata.version' is missing | Warning |
metadata_field | 'metadata' should map string keys to string values | Warning |
Total | 9 / 11 Passed | |
3df717f
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.