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 lean, highly actionable review workflow with concrete commands, an explicit pattern checklist, and clear output classifications. The main weaknesses are the undefined $SCOPE variable in step 2b, the inconsistent step numbering, and no instruction for handling failed automated checks.

Suggestions

Define the scope variable consistently: step 2b uses "$SCOPE" but the body only defines "$ARGUMENTS" — either define $SCOPE (e.g., "SCOPE=$ARGUMENTS") or use $ARGUMENTS directly in the /review-check-architecture invocation.

Renumber steps 2b and 3 into a clean 1–5 sequence so the workflow order is unambiguous.

Add a brief instruction for failed automated checks (e.g., whether failures auto-classify as VIOLATION or require inspection before classification) to close the validation feedback loop.

DimensionReasoningScore

Conciseness

"Perform a full code review of changed files, validating against `docs/ARCHITECTURE.md`" opens directly, and the rest is terse commands and bullet checklists with zero concept explanation. Lean and efficient; every token earns its place, matching the 5 anchor.

5 / 5

Actionability

Provides copy-paste-ready commands ("git diff --name-only HEAD~1", "npx tsc --noEmit", "npx eslint --ext .ts,.tsx src/ --max-warnings 0") and concrete classification labels (VIOLATION/ATTENTION/COMPLIANT/HIGHLIGHT). However, "Run /review-check-architecture $SCOPE" references an undefined variable ($SCOPE is never defined; the body defines $ARGUMENTS), a minor gap that fits the 4 anchor's "minor gaps" rather than the 5 anchor's fully executable guidance.

4 / 5

Workflow Clarity

A clear 5-step sequence (identify files → run checks → check patterns → classify → report) with automated checks serving as validation checkpoints; as a read-only review skill, the destructive-operation cap does not apply. The out-of-order "2b." step numbering and the absence of any guidance on what to do when automated checks fail keep it below the 5 anchor's "feedback loops for error recovery".

4 / 5

Progressive Disclosure

No bundle files exist (no references/, scripts/, or assets/ directories), and the body is ~35 lines with well-organized sections and an appropriate pointer to the project's docs/ARCHITECTURE.md. Per the rubric's simple-skill exception (under 50 lines, no need for external references), well-organized sections alone warrant a 5.

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 strong description with an explicit third-person "Use when..." trigger clause and four named validation areas. It is concise and specific, falling just short of top marks only in trigger synonym coverage (no PR/diff phrasing) and action concreteness.

DimensionReasoningScore

Specificity

Lists several specific validation actions — "validates architecture, types, security, and test coverage" — covering four distinct areas. These are category-level actions rather than the fully concrete operations of the 5 anchor (e.g., "extract text and tables, fill forms, merge documents"), but well beyond the 1–2 actions of the 3 anchor.

4 / 5

Completeness

Explicitly answers both: what ("validates architecture, types, security, and test coverage") and when ("Use when code changes need review before merge"). The when clause is a single condition rather than the multiple concrete trigger phrases of the 5 anchor, matching the 4 anchor example ("Extract text from PDFs and fill forms. Use when working with PDF files.") closely.

4 / 5

Trigger Term Quality

Includes natural phrases users would say — "code changes", "review", "before merge" — plus domain terms like "architecture", "types", "security", and "test coverage". Missing common variations such as "PR", "pull request", "diff", or "code review" as a noun phrase, which the 5 anchor requires.

4 / 5

Distinctiveness Conflict Risk

The specific validation stack (architecture, types, security, test coverage) gives it a distinct profile within the code-review niche. Minor overlap risk remains with generic code-review or linting skills since "review before merge" is a broadly claimed trigger, keeping it below the clear-niche 5 anchor.

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/react/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.