Trigger when the user requests a review of frontend files (e.g., `.tsx`, `.ts`, `.js`). Support both pending-change reviews and focused file reviews while applying the checklist rules.
68
50%
Does it follow best practices?
Impact
100%
1.92xAverage score across 3 eval scenarios
Risky
Do not use without reviewing
Optimize this skill with Tessl
npx tessl skill review --optimize ./.agents/skills/frontend-code-review/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 establishes a clear trigger condition and narrows scope to frontend file reviews, which is a reasonable start. However, it lacks specificity about what the review actually checks, references opaque 'checklist rules' without elaboration, and misses common user-facing trigger terms like 'code review', 'React', or 'PR review'. It would benefit from listing concrete review actions and expanding trigger term coverage.
Suggestions
List specific review actions (e.g., 'checks accessibility, component structure, prop validation, styling consistency') instead of the vague 'applying the checklist rules'.
Add more natural trigger terms users would say, such as 'code review', 'React components', 'PR review', 'frontend code', or 'UI review'.
Clarify the distinction between 'pending-change reviews' and 'focused file reviews' so Claude can better match user intent to the correct mode.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | It names the domain (frontend file review) and mentions two modes ('pending-change reviews' and 'focused file reviews') plus 'checklist rules', but doesn't list specific concrete actions like identifying accessibility issues, checking component patterns, or validating prop types. | 2 / 3 |
Completeness | It has a 'when' clause ('Trigger when the user requests a review of frontend files') and a partial 'what' (support pending-change and focused file reviews with checklist rules), but the 'what' is vague—'applying the checklist rules' is unexplained. The trigger guidance exists but is somewhat thin. | 2 / 3 |
Trigger Term Quality | Includes some natural keywords like 'review', '.tsx', '.ts', '.js', and 'frontend files', but misses common variations users might say such as 'code review', 'React', 'component review', 'PR review', or 'lint'. | 2 / 3 |
Distinctiveness Conflict Risk | Scoping to frontend file extensions (.tsx, .ts, .js) helps distinguish it, but 'review' is broad and could overlap with general code review skills, backend review skills, or linting skills. The .ts and .js extensions are not exclusively frontend. | 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 skill provides a well-structured framework for frontend code reviews with clear output templates and appropriate delegation to reference files for the checklist rules. However, it falls short on actionability—the review process steps are descriptive rather than executable, lacking specific tool commands for file gathering and inspection. The missing bundle files for the referenced checklists significantly limit the skill's standalone utility.
Suggestions
Add concrete tool-use examples in the Review Process section, e.g., specific commands like `git diff --cached --name-only '*.tsx' '*.ts' '*.js'` for pending-change mode, and `cat <filepath>` or equivalent for file-targeted mode.
Include at least one complete worked example showing a sample code snippet, the checklist rule it violates, and the resulting Template A output—this would make the skill much more actionable.
Provide the referenced bundle files (references/code-quality.md, references/performance.md, references/business-logic.md) or inline a minimal version of the checklist rules so the skill is functional without external dependencies.
Add a brief validation step in the review process, e.g., 'Verify each flagged violation against the checklist rule definition to avoid false positives before composing the output.'
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill is mostly efficient but includes some unnecessary explanation (e.g., the 'Intent' section restates what the trigger description already covers, and the two review modes are described somewhat verbosely). The template section is appropriately detailed since it defines exact output format, but the overall content could be tightened. | 2 / 3 |
Actionability | The review process steps are concrete but lack executable commands (e.g., no specific git commands for gathering staged files, no example of how to open/read files). The output templates are well-defined and copy-paste ready, but the actual review steps are more descriptive than prescriptive—step 1 says 'Open the relevant component/module' without specifying how. | 2 / 3 |
Workflow Clarity | The 3-step review process provides a clear sequence, but there are no validation checkpoints or feedback loops. For a code review skill that could flag false positives or miss context, there's no step to verify findings against actual runtime behavior or to confirm the checklist rules were fully applied. The workflow is present but lacks explicit verification. | 2 / 3 |
Progressive Disclosure | The skill references three external checklist files (code-quality.md, performance.md, business-logic.md) which is good progressive disclosure design. However, no bundle files were provided, so we cannot verify these references exist or are well-structured. The SKILL.md itself keeps the overview concise and delegates detail appropriately, but the referenced files are missing, which undermines the actual utility. | 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.
9cdeffd
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.