Opens a GitHub Pull Request with the standard PR template: Description, Staging Links, and JIRA ticket. Infers the ticket from the branch name and generates staging preview URLs from changed files after the PR is created. TRIGGER when: user asks to open, create, submit, make, update, or edit a PR or pull request, or wants to refresh staging links on an existing PR.
72
88%
Does it follow best practices?
Impact
—
No eval scenarios have been run
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 articulates specific capabilities (PR creation with template, JIRA inference, staging URL generation), provides comprehensive trigger terms covering multiple natural phrasings, and explicitly separates the 'what' from the 'when'. The description is concise yet thorough, and its specificity around the PR template structure and staging links makes it highly distinctive.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Lists multiple specific concrete actions: opens a GitHub PR with a standard template (Description, Staging Links, JIRA ticket), infers ticket from branch name, generates staging preview URLs from changed files, and can refresh staging links on existing PRs. | 3 / 3 |
Completeness | Clearly answers both 'what' (opens a GitHub PR with standard template, infers JIRA ticket, generates staging URLs) and 'when' (explicit TRIGGER clause listing specific verbs and scenarios including updating existing PRs). | 3 / 3 |
Trigger Term Quality | Excellent coverage of natural trigger terms: 'open', 'create', 'submit', 'make', 'update', 'edit' combined with both 'PR' and 'pull request', plus 'refresh staging links'. These are terms users would naturally use. | 3 / 3 |
Distinctiveness Conflict Risk | Highly distinctive with a clear niche: GitHub PR creation with a specific template format (Description, Staging Links, JIRA ticket), branch-name-based ticket inference, and staging URL generation. 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 well-structured, highly actionable skill with clear sequential steps, concrete commands, and good decision-point handling. Its main strengths are workflow clarity and actionability — every step has explicit commands and conditions. Minor weaknesses include slight verbosity in some explanations and the monolithic structure that could benefit from better progressive disclosure for a skill of this length.
Suggestions
Consider trimming introductory phrases and implicit explanations (e.g., 'Follow these steps in order to create a well-formed PR') to improve conciseness.
For progressive disclosure, consider extracting the template selection details (Step 4b) or the final body assembly patterns (Step 7) into a referenced companion file, keeping SKILL.md as a tighter overview.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill is mostly efficient and avoids explaining concepts Claude already knows, but some steps could be tightened. For example, Step 4b's full list of template options with paths is necessary context, but the overall document is somewhat verbose for what is essentially a sequential script — phrases like 'Follow these steps in order to create a well-formed PR' and some repeated explanations add minor bloat. | 2 / 3 |
Actionability | The skill provides concrete, executable bash commands throughout (git commands, gh CLI commands, gh API calls), specific URL patterns, exact file paths for templates, and clear examples of PR title format. The guidance is copy-paste ready and leaves little ambiguity about what to execute. | 3 / 3 |
Workflow Clarity | The 10-step workflow is clearly sequenced with explicit decision points (existing PR vs new PR, template vs no template, HAS_DOC_FILES flag), validation checks (checking for existing PR before creating), and conditional branching. The workaround for the GraphQL deprecation error in Step 8 shows awareness of failure modes. The user confirmation gates at Steps 4b and 8 serve as natural checkpoints. | 3 / 3 |
Progressive Disclosure | The skill references an external 'staging-preview' skill in Step 6 and template files in Step 4b, which is good delegation. However, the entire workflow is presented as one long monolithic document with no references to supplementary files for advanced details. For a skill of this length (~100 lines of substantive content), some sections like the template selection or staging link generation could benefit from being split out or having clearer navigation. | 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 | |
5985af5
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.