create-pr
Create a pull request for the current branch with proper labels and description
49
55%
Does it follow best practices?
Impact
—
No eval scenarios have been run
Passed
No known issues
Optimize this skill with Tessl
npx tessl skill review --optimize ./.claude/skills/create-pr/SKILL.mdQuality
Discovery
32%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 communicates the core action (creating a pull request) but lacks explicit trigger guidance ('Use when...'), common keyword variations (e.g., 'PR', 'GitHub'), and breadth of specific capabilities. It reads more like a single command description than a skill description designed for disambiguation among many skills.
Suggestions
Add an explicit 'Use when...' clause, e.g., 'Use when the user asks to open a PR, create a pull request, submit code for review, or push changes for merging.'
Include common trigger term variations such as 'PR', 'merge request', 'GitHub', 'open a PR', and 'code review' to improve matching.
Expand the capability list to cover related actions if applicable, such as setting reviewers, linking issues, or drafting PR descriptions from commit history.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Names the domain (pull requests) and some actions (create with labels and description), but doesn't list multiple concrete actions beyond creation — e.g., no mention of updating PRs, adding reviewers, linking issues, or other PR-related tasks. | 2 / 3 |
Completeness | Describes what it does (create a pull request with labels and description) but has no explicit 'Use when...' clause or equivalent trigger guidance, which per the rubric should cap completeness at 2 — and since the 'when' is entirely missing, this falls to 1. | 1 / 3 |
Trigger Term Quality | Includes 'pull request', 'branch', 'labels', and 'description' which are relevant keywords, but misses common variations like 'PR', 'merge request', 'open a PR', 'GitHub', or 'code review' that users would naturally say. | 2 / 3 |
Distinctiveness Conflict Risk | Fairly specific to pull request creation which narrows the domain, but could overlap with general Git workflow skills, GitHub automation skills, or broader CI/CD skills without clearer scoping. | 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 strong, actionable skill with a well-sequenced multi-step workflow and concrete executable commands. Its main weakness is some redundancy between the step 10 PR body instructions and the separate 'PR Description Guidelines' section, which inflates token usage without adding new information. The conditional logic handling (draft vs real, codex availability, branch state) is well done.
Suggestions
Remove or consolidate the 'PR Description Guidelines (from CONTRIBUTING.md)' section — its content is already covered in step 10's PR body instructions, and the duplication wastes tokens.
Consider referencing the PR template path in step 4 as the authoritative source rather than restating its sections inline, since the skill already instructs Claude to read it.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill is mostly efficient but includes some redundancy — the 'PR Description Guidelines' section largely repeats what's already covered in step 10's PR body instructions. The CONTRIBUTING.md excerpt could be omitted since the template sections already encode those guidelines. Otherwise, the content is reasonably tight. | 2 / 3 |
Actionability | The skill provides concrete, executable commands throughout: specific git commands, gh CLI invocations with exact flags, a complete bash example with --draft/--label/--body usage, and clear conditional logic (e.g., --real flag handling, codex check). Steps are copy-paste ready. | 3 / 3 |
Workflow Clarity | The 10-step workflow is clearly sequenced with explicit conditionals and branching logic (e.g., if on main with changes vs without, if codex is installed, if --real flag is present). Validation is embedded — checking branch state, checking for uncommitted changes, and the optional codex review step serves as a verification checkpoint before PR creation. | 3 / 3 |
Progressive Disclosure | The content is well-structured with clear sections (Instructions, Guidelines, Example, Usage, Output), but the PR Description Guidelines section is essentially inline duplication of step 10 content. For a skill of this length (~80 lines of substantive content), the inline approach is acceptable but the redundancy hurts organization. No bundle files are referenced despite mentioning .github/PULL_REQUEST_TEMPLATE.md and CONTRIBUTING.md. | 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
- DataDog/datadog-agent
- Commit
a41685a
- 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.