jbvc/create-pr
Create pull requests following Sentry conventions. Use when opening PRs, writing PR descriptions, or preparing changes for review. Follows Sentry's code review guidelines.
83
83%
Does it follow best practices?
Impact
Pending
No eval scenarios have been run
Passed
No known issues
Quality
Discovery
82%Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.
This is a solid description that clearly communicates its purpose and includes an explicit 'Use when' clause with natural trigger terms. Its main weakness is that the specific capabilities could be more detailed—it says it follows Sentry conventions but doesn't enumerate what those conventions entail (e.g., specific PR template fields, labeling, linking to Sentry issues). The Sentry-specific scoping helps with distinctiveness but some phrases are broad enough to risk overlap.
Suggestions
Add more specific concrete actions like 'formats PR titles with issue keys, fills in PR templates, adds appropriate labels' to improve specificity.
Narrow the 'preparing changes for review' phrase to reduce potential overlap with general code review or git workflow skills.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Names the domain (pull requests) and mentions some actions (opening PRs, writing PR descriptions, preparing changes for review), but doesn't list specific concrete actions like formatting templates, adding labels, linking issues, or structuring descriptions. | 2 / 3 |
Completeness | Clearly answers both what ('Create pull requests following Sentry conventions') and when ('Use when opening PRs, writing PR descriptions, or preparing changes for review') with an explicit 'Use when...' clause. | 3 / 3 |
Trigger Term Quality | Includes natural keywords users would say: 'pull requests', 'PRs', 'PR descriptions', 'code review', 'changes for review'. These are terms developers naturally use when they need help with pull requests. | 3 / 3 |
Distinctiveness Conflict Risk | The Sentry-specific convention focus helps distinguish it, but 'preparing changes for review' and 'code review guidelines' are broad enough to potentially overlap with general code review or git workflow skills. | 2 / 3 |
Total | 10 / 12 Passed |
Implementation
77%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 with clear workflow steps and executable commands. Its main weakness is moderate verbosity - the 'When to Use' section is redundant, three full PR examples could be trimmed to one or two, and some general guidelines restate things Claude already knows. The workflow is well-structured with proper validation checkpoints and the `gh api` workaround for editing PRs is a valuable, non-obvious detail.
Suggestions
Remove or significantly trim the 'When to Use This Skill' section since it largely restates the skill description and is information Claude can infer.
Reduce PR description examples from three to one or two - the pattern is clear from a single example, and the second/third add diminishing value.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | Generally efficient but has some redundancy - the 'When to Use This Skill' section repeats the description context, and some guidelines like 'One PR per feature/fix' and 'Explain the why' are things Claude already knows. The PR examples are valuable but three full examples is slightly verbose when the pattern is clear from one. | 2 / 3 |
Actionability | Provides fully executable bash commands throughout, concrete PR description templates with real examples, specific title format conventions, and copy-paste ready `gh pr create` and `gh api` commands. The issue reference table is immediately usable. | 3 / 3 |
Workflow Clarity | Clear 4-step sequential process with explicit prerequisites check, branch state verification, change analysis before writing, and final creation. Includes a validation step (checking uncommitted changes via git status) with a clear remediation path (invoke commit skill). The workflow is well-sequenced and logical. | 3 / 3 |
Progressive Disclosure | Content is well-structured with clear headers and sections, but the skill is fairly long (~150 lines) with three full PR examples and an editing section that could be split into a separate reference file. The external references at the bottom are good, but the inline content could benefit from better separation. | 2 / 3 |
Total | 10 / 12 Passed |
Validation
90%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 10 / 11 Passed
Validation for skill structure
| Criteria | Description | Result |
|---|---|---|
frontmatter_unknown_keys | Unknown frontmatter key(s) found; consider removing or moving to metadata | Warning |
Total | 10 / 11 Passed | |
Reviewed
Table of Contents