CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

review-review

Use when code changes need review before merge - validates architecture, types, security, and test coverage.

Quality

83%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide
SecuritybySnyk

Passed

No findings from the security scan

SKILL.md
Quality
Evals
Security

Quality

Content

86%Weight 40%Scale 1-5

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

A tight, command-driven review workflow that respects token budget and gives concrete executable checks throughout. The main gaps are an inconsistent $SCOPE/$ARGUMENTS variable reference and the absence of an explicit failure-handling path for the automated checks.

Suggestions

Replace the undefined $SCOPE variable in '/review-check-architecture $SCOPE' with $ARGUMENTS (or define SCOPE in terms of $ARGUMENTS) so the invocation is executable as written.

Add a brief step for what to do when the automated checks fail (e.g., classify the failure output as VIOLATION findings before proceeding to the architecture check), creating an explicit validate-and-recover loop.

Renumber the steps cleanly (absorb '2b' into a single ordered sequence) so the workflow reads as one coherent sequence.

DimensionReasoningScore

Conciseness

The ~40-line body is lean and assumes Claude's competence: 'Perform a full code review of changed files, validating against docs/ARCHITECTURE.md' plus terse commands and a one-line-per-item checklist — no padding and no explanation of concepts Claude already knows.

5 / 5

Actionability

Commands are mostly copy-paste ready ('npx tsc --noEmit', 'npx eslint --ext .ts,.tsx src/ app/ --max-warnings 0', the git diff fallback chain), but '/review-check-architecture $SCOPE' uses an undefined variable ($ARGUMENTS is what's defined) and 'git diff HEAD~1' silently assumes a prior commit exists.

4 / 5

Workflow Clarity

A clear numbered sequence (identify files → automated checks → architecture check → classify → report) with the automated checks serving as validation checkpoints, but there is no explicit feedback loop for what to do when checks fail and the awkward '2b' numbering signals a patched-in step rather than a coherent sequence.

4 / 5

Progressive Disclosure

The skill is under 50 lines with no external references needed (no references/, scripts/, or assets/ directories exist), and its single '## Steps' section with a compact inline checklist is well organized — the simple-skill exception applies.

5 / 5

Total

18

/

20

Passed

Description

75%Weight 40%Scale 1-5

Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.

A well-formed description with third-person voice, an explicit 'Use when...' trigger, and a concrete list of validation areas. It scores consistently at 4 due to missing natural synonyms (PR, pull request, diff) and a when-clause that could name concrete trigger phrases.

Suggestions

Add common user phrasings to the when-clause, e.g., 'Use when the user asks to review a PR, pull request, diff, or code changes before merge'.

Include synonyms such as 'pull request', 'PR', and 'diff' alongside 'code changes' to broaden natural trigger coverage.

Sharpen the what-clause by naming the output (e.g., 'classifies findings and produces an approval verdict') to distinguish it from other review skills.

DimensionReasoningScore

Specificity

'validates architecture, types, security, and test coverage' lists several specific actions within the code-review domain, but coverage has minor gaps (e.g., nothing about producing findings or a verdict), matching the 'several specific actions; minor gaps' anchor rather than the comprehensive level 5.

4 / 5

Completeness

Both parts are explicit: what ('validates architecture, types, security, and test coverage') and when ('Use when code changes need review before merge'), but the when-clause lacks concrete trigger phrases (e.g., 'review my PR' or 'review staged changes'), so it sits at level 4 rather than 5 and well above level 3.

4 / 5

Trigger Term Quality

Natural terms users would say are present ('code changes', 'review', 'merge', 'test coverage'), but common variations like 'pull request', 'PR', and 'diff' are missing, which fits 'good keyword coverage; a few natural terms missing' rather than the comprehensive synonym coverage of level 5.

4 / 5

Distinctiveness Conflict Risk

The pre-merge change-review framing with architecture validation is a mostly distinct niche, though 'security' and general code-review language create minor overlap risk with closely related review skills — level 4, not 3 (far more specific than a generic 'works with files' style) and not 5 (triggers aren't uniquely distinguishable from sibling review skills).

4 / 5

Total

16

/

20

Passed

Validation

87%

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation — 14 / 16 Passed

Validation for skill structure

CriteriaDescriptionResult

allowed_tools_field

'allowed-tools' contains unusual tool name(s)

Warning

frontmatter_unknown_keys

Unknown frontmatter key(s) found; consider removing or moving to metadata

Warning

Total

14

/

16

Passed

Repository

fernandezbaptiste/specialist-agent

Path

packs/nextjs/skills/review-review/SKILL.md

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.