create-pr
Create a GitHub pull request with the project's PR template fully populated. Analyzes the branch diff, fills in "What changed", "Issue", "How to test", "A11y impact", "Definition of Done", and other sections. Use this skill whenever the user wants to create a PR, open a pull request, submit their branch for review, or says things like "make a PR", "open a PR", "submit this for review", or "I'm ready to create a pull request" — even if they don't use the exact phrase "pull request".
88
88%
Does it follow best practices?
Impact
84%
1.35xAverage score across 3 eval scenarios
Passed
No known issues
Quality
Discovery
100%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 an excellent skill description that clearly communicates what the skill does (creates GitHub PRs with fully populated templates), lists specific template sections it handles, and provides comprehensive trigger guidance with natural language variations. It uses third person voice consistently and is both specific and distinctive.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Lists multiple specific concrete actions: analyzes branch diff, fills in specific PR template sections ('What changed', 'Issue', 'How to test', 'A11y impact', 'Definition of Done'), and creates a GitHub pull request. | 3 / 3 |
Completeness | Clearly answers both 'what' (creates a GitHub PR with template fully populated, analyzes diff, fills specific sections) and 'when' (explicit 'Use this skill whenever...' clause with multiple trigger scenarios). | 3 / 3 |
Trigger Term Quality | Excellent coverage of natural trigger terms users would say: 'create a PR', 'open a pull request', 'submit their branch for review', 'make a PR', 'open a PR', 'submit this for review', 'I'm ready to create a pull request'. Covers both formal and casual phrasings. | 3 / 3 |
Distinctiveness Conflict Risk | Highly distinctive — specifically targets GitHub PR creation with a project's PR template. The mention of specific template sections like 'A11y impact' and 'Definition of Done' makes it very unlikely to conflict with generic git or code review skills. | 3 / 3 |
Total | 12 / 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 strong, actionable skill that provides a clear end-to-end workflow for creating PRs with a specific template. Its main strengths are concrete executable commands, explicit user confirmation before destructive actions, and thorough coverage of each template section. Minor weaknesses include some verbosity in explanatory passages and all content being inline rather than leveraging progressive disclosure for the detailed per-section guidance.
Suggestions
Trim explanatory sentences that describe intent rather than instruct (e.g., 'the kind of thing a reviewer reads to orient themselves before looking at code') to improve conciseness.
Consider extracting the detailed per-section filling guidance into a separate reference file (e.g., PR_TEMPLATE_GUIDE.md) and keeping SKILL.md as a concise workflow overview with links.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | Generally efficient but includes some unnecessary guidance Claude already knows (e.g., 'Read the full diff carefully. You need to understand every change' and explaining what a reviewer reads to orient themselves). Some sections like the A11y impact and Definition of Done explanations could be tighter. | 2 / 3 |
Actionability | Provides fully executable bash commands for gathering context, concrete formatting examples for each PR section, a complete HEREDOC pattern for `gh pr create`, and specific conventions like branch naming patterns and checkbox markdown. Copy-paste ready throughout. | 3 / 3 |
Workflow Clarity | Clear multi-step sequence: gather context → fill template sections → pre-creation checks (push branch, confirm with user) → create PR → display URL. Includes explicit validation checkpoints: checking if branch is pushed, confirming with user before creating, and handling missing ticket numbers by asking the user. | 3 / 3 |
Progressive Disclosure | Well-organized with clear section headers that mirror the PR template sections, making it easy to navigate. However, the content is moderately long and entirely inline — the per-section guidance (especially Definition of Done analysis rules) could be split into a reference file. No bundle files are provided, so there's no external structure to leverage. | 2 / 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
- HHS/OPRE-OPS
- Commit
e2a9461
- 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.