pr-creator
Use this skill when asked to create a pull request (PR). It ensures all PRs follow the repository's established templates and standards.
72
58%
Does it follow best practices?
Impact
94%
1.10xAverage score across 3 eval scenarios
Passed
No known issues
Optimize this skill with Tessl
npx tessl skill review --optimize ./.gemini/skills/pr-creator/SKILL.mdQuality
Discovery
40%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 identifies its core purpose (creating PRs following templates) but is too vague about specific capabilities and lacks sufficient trigger terms. It has a basic 'when' clause but the 'what' portion needs significantly more detail about concrete actions performed. The description also uses second person voice ('Use this skill when asked') rather than third person.
Suggestions
Add specific concrete actions like 'Generates PR titles, populates description from repository templates, links related issues, and adds appropriate labels and reviewers'.
Expand trigger terms to include variations like 'merge request', 'open a PR', 'submit changes for review', 'gh pr', or 'push and create PR'.
Rewrite in third person voice, e.g., 'Creates pull requests following the repository's established templates and standards. Use when the user asks to create a PR, open a pull request, or submit changes for review.'
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | The description says 'create a pull request' and 'follows templates and standards' but does not list any concrete actions beyond that. It lacks specifics like 'generates PR title, fills in description template, adds labels, links issues'. | 1 / 3 |
Completeness | It has a 'when' clause ('when asked to create a pull request') and a weak 'what' (ensures PRs follow templates and standards), but the 'what' is vague and the 'when' is narrow. The description uses second-person-adjacent 'Use this skill when asked' which partially addresses when, but the what is underspecified. | 2 / 3 |
Trigger Term Quality | Includes 'pull request' and 'PR' which are natural trigger terms users would say. However, it misses common variations like 'merge request', 'open a PR', 'submit PR', 'gh pr create', or related terms like 'code review'. | 2 / 3 |
Distinctiveness Conflict Risk | It's somewhat specific to PR creation and template compliance, which narrows the domain. However, it could overlap with general git workflow skills, code review skills, or repository management skills since it doesn't clearly delineate its boundaries. | 2 / 3 |
Total | 7 / 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 a well-sequenced workflow that includes important safety checks and validation steps. The concrete bash commands and clear step ordering are strengths. Minor improvements could be made by trimming some explanatory text that Claude doesn't need (e.g., checklist marking conventions) and the somewhat redundant Principles section.
Suggestions
Trim the Principles section since its points are already embedded as CRITICAL notes in the workflow steps, or reduce it to a single-line reminder.
Condense step 5's checklist guidance—Claude already knows how to fill in markdown templates and mark checkboxes.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The content is mostly efficient but includes some unnecessary elaboration, such as explaining what checklists are and how to mark them, and the Principles section restates things already covered in the workflow. Some tightening is possible. | 2 / 3 |
Actionability | Every step includes concrete, executable bash commands (git, gh CLI). The workflow provides specific file paths to check for templates, exact command syntax with flags like --body-file, and clear examples of conventional commit format. | 3 / 3 |
Workflow Clarity | The 8-step workflow is clearly sequenced with explicit validation checkpoints: branch verification before starting, git status check before committing, preflight script before pushing, and a critical safety rail double-check before push. There's a clear feedback loop at step 6 (fix issues if checks fail). | 3 / 3 |
Progressive Disclosure | The content is well-structured with clear sections (Workflow, Principles), but it's a moderately long single file with no references to external documentation. The detailed template-filling instructions in step 5 could potentially be split out, though the skill is not excessively long. | 2 / 3 |
Total | 10 / 12 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 — 11 / 11 Passed
Validation for skill structure
No warnings or errors.
- Repository
- google-gemini/gemini-cli
- Commit
9f76f34
- 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.