CtrlK
BlogDocsLog inGet started
Tessl Logo

code-review

Review the changed lines of a single file in a pull request for bugs, correctness, error handling, security, and maintainability, and return structured findings.

58

Quality

66%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

SecuritybySnyk

Low

Low-risk findings worth noting

Fix and improve this skill with Tessl

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

Quality

Content

75%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.

The body is well-structured, actionable, and appropriately concise, providing a clear procedure, concrete tool usage, severity definitions, and a copy-paste-ready result schema. It is a strong, self-contained skill with only minor room for tightening and an optional worked example.

DimensionReasoningScore

Conciseness

The body is direct and assumes Claude's competence (no explanation of what a PR or code review is), but the style-review exclusion is stated twice (opening paragraph and the 'What NOT to review' section) and the triple 'Do not write/narrate/explain' could be collapsed, so it is efficient with minor instances that could be trimmed rather than fully lean.

4 / 5

Actionability

It gives a concrete procedure, specific tool names (submit_code_review, read_repo_file, search_repo), defined severity levels, and a copy-paste-ready JSON result shape; it stops short of a 5 only because there is no worked example showing an actual changed line mapped to a finding.

4 / 5

Workflow Clarity

The four-step Procedure is a clear, ordered sequence with an implicit self-check guardrail ('Only report a finding when you can point to a specific changed line'); this is a review task with no destructive/batch operation, so the destructive cap does not apply, and the only gap is that the validation guardrails live outside the numbered procedure rather than as explicit checkpoints.

4 / 5

Progressive Disclosure

No bundle files exist (references/, scripts/, assets/ are empty) and none are referenced, so the skill is self-contained; it is well-organized into clear sections (Data sources, Procedure, What to review, What NOT to review, Severity, Result shape), scoring just below 5 because the body exceeds 50 lines and the 5 anchor specifically expects well-signaled one-level-deep references.

4 / 5

Total

16

/

20

Passed

Description

58%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.

The description is concrete and specific about what the skill does and the defect categories it covers, but it lacks an explicit 'when to use' trigger clause and omits common synonyms like 'PR' or 'code review'. Adding a Use-when clause and a few natural trigger terms would raise completeness and trigger-term quality.

Suggestions

Add an explicit 'Use when...' clause, e.g. 'Use when the user asks to review a pull request, check a PR/diff for bugs, or code-review changed lines in a single file.'

Include natural synonyms users actually say — 'PR', 'code review', 'diff', 'review my changes' — alongside 'pull request' and 'review'.

Consider listing a couple of distinct actions (e.g. 'flag logic errors, missing error handling, and security issues') to push specificity toward a 5.

DimensionReasoningScore

Specificity

The description names a concrete action ('Review the changed lines of a single file in a pull request') and enumerates several specific review dimensions ('bugs, correctness, error handling, security, and maintainability') plus a concrete output ('return structured findings'); it falls just short of a 5 because it is essentially a single verb applied to multiple aspects rather than multiple distinct actions.

4 / 5

Completeness

The 'what' is clearly stated (review changed lines for the listed defect categories and return structured findings), but there is no 'Use when...' clause or equivalent explicit trigger guidance, so per the judging guidelines completeness is capped at 3 with 'when' only weakly implied.

3 / 5

Trigger Term Quality

It contains relevant natural terms ('pull request', 'review', 'bugs') but misses common variations and synonyms a user might actually say such as 'PR', 'code review', 'diff', or 'review my changes', so it lands at 'some relevant keywords but missing common variations'.

3 / 5

Distinctiveness Conflict Risk

The narrow scope ('a single file in a pull request', 'structured findings') gives it a mostly-distinct niche with only minor overlap risk against other general code-review skills, rather than a fully clear niche with minimal conflict risk.

4 / 5

Total

14

/

20

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
cloudflare/cloudflare-docs
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.