CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

review-pull-request

Use when reviewing a pull request, to check for logic bugs, style consistency, and security concerns and summarise the findings for the author.

Quality

81%

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

SKILL.md
Quality
Evals
Security

Quality

Content

78%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 an exemplar of token efficiency — a lean, well-ordered five-step checklist with no padding — and needs no external files. Its weakness is actionability: the guidance is directional rather than operational, omitting the concrete commands, severity taxonomy, and output format that would make it directly executable.

Suggestions

Add the concrete command(s) for obtaining the diff, e.g., 'gh pr diff <number>' or 'git diff main...HEAD', so step 1 is directly executable.

Define the severity levels used in step 5 (e.g., critical / warning / nit) so findings are grouped consistently.

Specify an output format or structure for the summary (e.g., findings grouped by severity with file:line references and concrete suggestions) to make the final step unambiguous.

DimensionReasoningScore

Conciseness

Five terse steps with zero padding: 'Read the diff and understand what the change is trying to do.' No concepts Claude already knows are explained, and every token earns its place — a direct match for the lean-and-efficient anchor. It is not below 5 because nothing could be cut without losing instruction.

5 / 5

Actionability

Steps are directive and include some concrete specifics ('secrets, auth, input handling', 'grouped by severity'), but key operational details are missing — no command for obtaining the diff (e.g., 'gh pr diff'), no severity definitions, no output format. This matches 'some concrete guidance but incomplete; missing key details', not 4, which requires mostly executable guidance.

3 / 5

Workflow Clarity

A clear, logically ordered 5-step sequence (read → bugs → style → security → summarize). As a read-only, non-destructive single-purpose skill the validation cap does not apply, and the simple-skill exception lifts it above the checkpoints-missing anchor 3; it stays below 5 because no entry-point or verification detail is given (e.g., how to fetch the diff or confirm full context).

4 / 5

Progressive Disclosure

No bundle files exist and the skill is under 50 lines with a single task; the content is well organized under a single heading with no inlined material that belongs elsewhere. Per the rubric's simple-skill guidance, this earns a 5 with just well-organized sections.

5 / 5

Total

17

/

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 solid description that explicitly covers both what the skill does and when to use it, with concrete, natural-sounding actions. Its main weaknesses are a single trigger phrase without common synonyms ('PR', 'code review', 'diff') and minor coverage gaps in the actions listed.

Suggestions

Add common trigger synonyms such as 'PR', 'code review', or 'diff' to the 'Use when...' clause so the skill triggers on the phrasing users most often use.

Extend the action list slightly to cover common review concerns (e.g., missed edge cases, test coverage) for more comprehensive capability coverage.

Make the 'when' clause more specific, e.g., 'Use when the user asks to review a pull request, check a diff, or look for bugs in proposed changes.'

DimensionReasoningScore

Specificity

The description names the domain ('reviewing a pull request') and lists several concrete actions — 'check for logic bugs, style consistency, and security concerns and summarise the findings' — matching the anchor for several specific actions with minor gaps in coverage. It is not 5 because coverage has small gaps (e.g., no mention of tests, performance, or edge cases).

4 / 5

Completeness

Both 'what' (check for logic bugs, style consistency, security concerns; summarise findings for the author) and 'when' ('Use when reviewing a pull request') are explicitly present. The 'when' is a single trigger clause and could be more specific with additional trigger phrases, so it falls short of the anchor-5 example.

4 / 5

Trigger Term Quality

It includes natural phrases users would say — 'reviewing a pull request', 'logic bugs', 'style consistency', 'security concerns' — but omits common variations such as 'PR', 'code review', or 'diff'. This matches good keyword coverage with a few natural terms missing, not the comprehensive synonym/extension coverage of a 5.

4 / 5

Distinctiveness Conflict Risk

Pull request review is a distinct niche with clear triggers, but it overlaps with closely related code-review and diff-analysis skills. Mostly distinct with minor overlap risk, matching the anchor-4 example rather than the minimal-conflict anchor 5.

4 / 5

Total

16

/

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.

Validation — 16 / 16 Passed

Validation for skill structure

No warnings or errors.

Repository

tesslio/product-plugins

Path

plugin-creator/evals/scenario-5/inputs/install-cache/tessl/pr-reviewer/skills/review-pull-request/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.