review-pr
Perform a review on a GitHub PR, leaving comments on the PR
48
52%
Does it follow best practices?
Impact
—
No eval scenarios have been run
Advisory
Suggest reviewing before use
Optimize this skill with Tessl
npx tessl skill review --optimize ./.claude/skills/review-pr/SKILL.mdQuality
Discovery
32%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 brief and identifies the core task (reviewing a GitHub PR and leaving comments) but lacks depth in specifying concrete actions and entirely omits a 'Use when...' clause. It would benefit from listing specific review capabilities and including natural trigger terms and explicit usage guidance.
Suggestions
Add a 'Use when...' clause with trigger terms like 'review my PR', 'pull request review', 'code review', 'PR feedback', 'leave comments on PR'.
Expand the capability list with specific actions such as 'analyze code changes, suggest improvements, leave inline comments, approve or request changes on GitHub pull requests'.
Include common term variations like 'pull request', 'PR', 'code review', and 'diff review' to improve trigger term coverage.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Names the domain (GitHub PR) and a specific action (leaving comments), but doesn't elaborate on what kind of review — e.g., code quality checks, style feedback, approval/request changes, inline vs. general comments. | 2 / 3 |
Completeness | Describes what it does (review a GitHub PR, leave comments) but has no explicit 'Use when...' clause or trigger guidance, which per the rubric caps completeness at 2, and the 'what' is also fairly thin, placing this at 1. | 1 / 3 |
Trigger Term Quality | Includes 'GitHub PR' and 'review' which are natural terms, but misses common variations like 'pull request', 'code review', 'PR feedback', 'review changes', or 'PR comments'. | 2 / 3 |
Distinctiveness Conflict Risk | Specifying 'GitHub PR' and 'leaving comments' provides some distinctiveness, but it could overlap with general GitHub interaction skills or code review skills without clearer scoping. | 2 / 3 |
Total | 7 / 12 Passed |
Implementation
72%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This is a solid, actionable skill that provides specific executable commands for reviewing GitHub PRs and posting comments via the gh CLI. Its main strengths are the precise API call formats and clear step sequencing. Weaknesses include some unnecessary verbosity in prerequisites/coaching and the lack of validation checkpoints for a workflow that posts multiple public comments to GitHub.
Suggestions
Add a validation step after posting inline comments (e.g., check API response for errors, retry or notify user on failure) to handle cases like invalid line numbers or rate limiting.
Trim the prerequisite section — Claude can handle 'ensure gh is installed and authenticated' without detailed fallback instructions; move those to a brief note instead of multi-line sub-steps.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill is mostly efficient but includes some unnecessary verbosity, such as the detailed prerequisite instructions for installing and authenticating gh CLI (Claude knows how to handle CLI tools). The inline comment API format is appropriately detailed since it's specific domain knowledge. Some instructions like 'Be constructive and actionable' are unnecessary coaching for Claude. | 2 / 3 |
Actionability | The skill provides fully executable commands with exact gh CLI syntax, specific API endpoint formats, and concrete parameter names. The gh api call for inline comments is copy-paste ready with all required fields specified. The workflow is specific enough that Claude can execute it without guessing. | 3 / 3 |
Workflow Clarity | Steps are clearly sequenced with prerequisites and a numbered workflow. However, there are no validation checkpoints — no verification that the PR view command succeeded, no error handling if inline comments fail (e.g., wrong line numbers), and no feedback loop for retrying failed API calls. For an operation that posts public comments to GitHub (a semi-destructive batch operation), this is a notable gap. | 2 / 3 |
Progressive Disclosure | For a single-purpose skill under 80 lines with no need for external references, the content is well-organized with clear sections (prerequisites, steps, important notes). No bundle files are needed for this task, and the structure is easy to navigate. | 3 / 3 |
Total | 10 / 12 Passed |
Validation
81%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 9 / 11 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 | 9 / 11 Passed | |
- Repository
- DataDog/dd-trace-dotnet
- Commit
6249bb4
- 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.