review-pr

Perform a review on a GitHub PR, leaving comments on the PR

Quality

67%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

Securityby

Low

Low-risk findings worth noting

Fix and improve this skill with Tessl

tessl review fix ./.claude/skills/review-pr/SKILL.md

Quality

Content

81%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 skill body is highly actionable with complete, executable gh commands and a clear two-part review workflow, and it is well-structured for a single-purpose skill. Its main weakness is the lack of explicit validation/feedback checkpoints for the batch inline-comment posting, which keeps workflow clarity at 4.

Dimension	Reasoning	Score
Conciseness	The body is mostly efficient, giving concrete commands and a tight step list with minimal padding; only a few phrases (e.g. re-explaining the line-number rationale twice, 'analyze the changes thoroughly' list) could be trimmed. It is above a 3 (mostly efficient with some slack) but not a 5 (lean, every token earns its place) due to minor repetition.	4 / 5
Actionability	It provides copy-paste-ready, fully specified commands (gh pr view with --json fields, gh pr diff, the exact gh api POST call with all flags, gh pr comment) plus concrete requirements (file path + line number, headRefOid for commit_sha). Specific examples cover the common cases, matching the 5 anchor.	5 / 5
Workflow Clarity	There is a clear numbered sequence with prerequisite checks (auth status, install gh) and two-part posting, but validation/checkpoint steps are implicit rather than explicit feedback loops. Per the guideline, destructive/batch operations (posting many inline comments to a PR) without explicit validation cap this at 3; however the prerequisite checks (auth/login retry) act as partial checkpoints, placing it at a 4 — above a 3 (steps listed, checkpoints missing) but short of a 5 (explicit validate->fix->retry loops).	4 / 5
Progressive Disclosure	Content is well organized into clear sections (Prerequisites, numbered steps, Part A/B, IMPORTANT) with no bundle files needed for a sub-50-line single-purpose skill. Structure is good with only minor organization gaps (the IMPORTANT section partly duplicates inline guidance). It is a 4 rather than 5 because navigation could be slightly tighter, but no nested references exist.	4 / 5
	Total	17 / 20 Passed

Description

53%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 clear and uses appropriate third-person voice, stating a concrete purpose (PR review with comments) but provides no 'Use when' trigger guidance and only one concrete action. It is reasonably distinct yet would benefit from explicit trigger phrases and broader coverage of review actions.

Suggestions

Add a 'Use when' clause, e.g. 'Use when the user asks to review a pull request or wants PR feedback posted to GitHub.'

Enumerate concrete actions to lift specificity, e.g. 'Analyze the diff, identify issues with file paths and line numbers, and post inline and summary comments to GitHub.'

Include natural synonyms/trigger terms like 'pull request', 'code review', and 'PR feedback' for broader trigger coverage.

Dimension	Reasoning	Score
Specificity	Names the domain (PR review) and one concrete action ('leaving comments'), but does not enumerate the several concrete review actions (diff analysis, inline comments, summary) actually performed. It sits above a 2 ('Names the domain but actions are minimal') because it specifies leaving comments rather than a generic verb, but below a 4 which requires several specific actions.	3 / 5
Completeness	It gives a clear 'what' (review a PR, leave comments) but has no 'when'/'Use when' clause, so per the guidelines completeness is capped at 3. It is not a 2 because the 'what' is clear and specific rather than vague.	3 / 5
Trigger Term Quality	'review', 'GitHub PR', and 'comments' are relevant terms a user might say, but common natural variations like 'pull request', 'code review', or 'review my PR' are only weakly covered. It is above a 2 (which has only generic keywords) but lacks the broader synonym coverage of a 4.	3 / 5
Distinctiveness Conflict Risk	'GitHub PR' and 'leaving comments on the PR' is a fairly distinct niche unlikely to trigger for unrelated skills, though 'review' alone is a common word with minor overlap risk. It is mostly distinct (a 4) rather than clearly niche-minimal-conflict (a 5) because the trigger phrasing is generic and could overlap with general code-review intents.	4 / 5
	Total	13 / 20 Passed

Validation

87%

Warnings & errors only

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

Criteria	Description	Result
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: DataDog/dd-trace-dotnet
Path: .claude/skills/review-pr/SKILL.md
Commit: 8acf051

Reviewed: 1 day ago

Table of Contents

Discovery Implementation Validation

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.