CtrlK
BlogDocsLog inGet started
Tessl Logo

code-review

Perform a pedantic, multi-perspective code review on the current diff or git changes against the styleguide and software engineering best practices.

49

Quality

53%

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

Fix and improve this skill with Tessl

tessl review fix ./.agents/skills/code-review/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

57%

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

The content is well-structured and reasonably actionable for an instruction-only review skill, with genuinely concrete bash and regex examples, but it carries some redundant concept explanations and lacks an explicit validation/feedback checkpoint in its workflow. Progressive disclosure is strong thanks to clean sectioning within a compact single file.

Suggestions

Trim restatements of well-known concepts (edge-case lists, DRY definition, leak-type catalog) to tighten conciseness toward a 3.

Add an explicit validation checkpoint, e.g. a final self-check that all three passes were completed and every [MUST-FIX] has a concrete recommendation.

Convert key abstract directives into copy-paste-ready examples (e.g. a sample grep for swallowed catch blocks) to lift actionability.

DimensionReasoningScore

Conciseness

The body is mostly a lean checklist, but it re-explains concepts Claude already knows ("Check boundary conditions (empty lists, null values, division by zero)", the DRY definition, leak-type enumeration), fitting anchor 2; not a 1 (not padded prose) and not a 3 (some unnecessary explanation remains).

2 / 3

Actionability

Concrete bits exist (regex `^[0-9]+$`, bash expansions like `${var##*/}`, `grep -F`, `git diff`) but the bulk is abstract directive language ("Check...", "Look for...", "Watch out for..."), matching anchor 2; not a 1 (some concrete executable guidance present) and not a 3 (not consistently copy-paste-ready).

2 / 3

Workflow Clarity

A clear 4-step "Step-by-Step Execution" plus a 3-pass checklist gives a real sequence, but there are no explicit validation or feedback-loop checkpoints, fitting anchor 2; not a 1 (sequence is present) and not a 3 (no validation steps or error-recovery loops).

2 / 3

Progressive Disclosure

The body is under 50 lines with no bundle files needed and is organized into clear, well-labeled sections (Context, Review Protocol, 3-pass Checklist, Step-by-Step), so per the rubric's simple-skill guideline it qualifies for anchor 3; not a 2 (structure is clean, not monolithic).

3 / 3

Total

9

/

12

Passed

Description

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 clearly states what the skill does but omits any explicit "Use when..." trigger guidance and lists only a single high-level action. It is competent but capped at the middle level across all dimensions.

Suggestions

Add an explicit trigger clause, e.g. "Use when the user asks to review code, a diff, or uncommitted changes before committing or pushing a PR."

Include common natural trigger variations such as "review my changes", "review the diff", "pre-commit review", and "PR review".

Enumerate multiple concrete actions (e.g. "find logic bugs, security vulnerabilities, resource leaks, and style violations") to lift specificity to a 3.

DimensionReasoningScore

Specificity

Quotes "Perform a pedantic, multi-perspective code review on the current diff or git changes" name the domain and a main action, but it is a single action rather than multiple listed concrete actions, matching anchor 2; not a 1 (not vague) and not a 3 (no enumeration of several concrete actions).

2 / 3

Completeness

The "what" is clear (code review on diffs against styleguide/best practices) but there is no "Use when..." clause or equivalent explicit trigger, so per the rubric guideline completeness caps at 2; not a 1 (what is present) and not a 3 (no explicit when).

2 / 3

Trigger Term Quality

Natural terms like "code review", "diff", and "git changes" are present and would be said by users, but common variations ("review my changes", "pre-commit review", "PR review") are missing, fitting anchor 2; not a 1 (terms are natural, not jargon) and not a 3 (coverage is partial).

2 / 3

Distinctiveness Conflict Risk

The niche "code review on the current diff or git changes against the styleguide" is fairly specific, but without explicit triggers it could still overlap with general git or styleguide skills, matching anchor 2; not a 1 (not generic) and not a 3 (triggers not explicit enough to fully distinguish).

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.

Validation16 / 16 Passed

Validation for skill structure

No warnings or errors.

Repository
flutter/flutter-intellij
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.