Use this skill when asked to create a pull request (PR). It ensures all PRs follow the repository's established templates and standards.
80
71%
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
57%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 has a clear 'Use when' trigger clause and identifies its core purpose (PR creation), which is a strength. However, it lacks specificity about what concrete actions it performs beyond the generic 'follows templates and standards,' and it uses second-person framing ('Use this skill when asked') rather than third-person voice describing capabilities. The trigger terms are adequate but could be broader.
Suggestions
Add specific concrete actions the skill performs, e.g., 'Creates pull requests by generating titles, descriptions from commit diffs, filling PR templates, and adding appropriate labels.'
Expand trigger terms to include variations like 'merge request', 'submit PR', 'open a PR', 'push changes for review'.
Rewrite in third-person voice describing capabilities, e.g., 'Creates pull requests following repository templates and standards. Use when...'
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | The description says 'create a pull request' and 'follows templates and standards' but doesn't list specific concrete actions like formatting commit messages, filling template sections, adding labels, or linking issues. The actions are vague. | 1 / 3 |
Completeness | It explicitly answers both 'what' (creates pull requests following repository templates and standards) and 'when' ('Use this skill when asked to create a pull request'). The 'Use when' clause is present and clear. | 3 / 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 changes', or 'code review'. | 2 / 3 |
Distinctiveness Conflict Risk | It's somewhat specific to PR creation, but 'follows repository's established templates and standards' is vague enough that it could overlap with other skills related to git workflows, code review, or repository management. | 2 / 3 |
Total | 8 / 12 Passed |
Implementation
85%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, well-structured skill that provides a clear, actionable workflow for creating pull requests with appropriate safety rails and validation checkpoints. Its main weakness is minor verbosity—some explanatory asides and the Principles section partially duplicate guidance already present in the workflow steps. Overall, it's a high-quality skill that would effectively guide Claude through PR creation.
Suggestions
Trim the Principles section since its key points (never push to main, follow templates, accuracy) are already enforced inline in the workflow steps, or consolidate them into a single-line reminder.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill is mostly efficient but includes some unnecessary verbosity—e.g., the Principles section restates what's already embedded in the workflow steps (safety rails about main branch), and some explanatory text like 'depending on the template's instructions' and 'but prefer keeping it unchecked for transparency' could be trimmed. However, it doesn't explain concepts Claude already knows. | 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 a practical workaround for shell escaping issues with multi-line markdown. Guidance is copy-paste ready. | 3 / 3 |
Workflow Clarity | The 8-step workflow is clearly sequenced with explicit validation checkpoints: checking current branch before proceeding, running git status to verify commits, running preflight checks before pushing, and a double-check safety rail before push. There are clear feedback loops—if preflight fails, fix before proceeding; if on main, create a new branch first. | 3 / 3 |
Progressive Disclosure | For a skill with no bundle files, the content is well-organized into a clear Workflow section and a concise Principles section. The skill is under 100 lines and self-contained with no need for external references. Sections are logically structured and easy to navigate. | 3 / 3 |
Total | 11 / 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.
77e65c0
Table of Contents
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.