pr
Creates a pull request for the current branch.
50
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/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 is concise and identifies a clear action (creating a pull request) but lacks a 'Use when...' clause, which is critical for Claude to know when to select this skill. It also misses common trigger term variations like 'PR' and 'open a PR', and doesn't enumerate related capabilities that would help distinguish it from other Git-related skills.
Suggestions
Add a 'Use when...' clause with explicit triggers, e.g., 'Use when the user asks to open a PR, create a pull request, submit changes for review, or push a branch for merging.'
Include common trigger term variations such as 'PR', 'open a PR', 'merge request', and 'submit for review'.
List additional specific capabilities if applicable, such as setting PR title/description, adding reviewers, or applying labels.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Names a specific action ('creates a pull request') and a context ('current branch'), but only describes a single action without listing additional related capabilities like updating PRs, adding reviewers, or setting labels. | 2 / 3 |
Completeness | Describes what it does but has no 'Use when...' clause or equivalent explicit trigger guidance. Per the rubric, a missing 'Use when...' clause caps completeness at 2, and since the 'when' is entirely absent, this scores a 1. | 1 / 3 |
Trigger Term Quality | Includes 'pull request' and 'branch' which are natural terms users would say, but misses common variations like 'PR', 'open a PR', 'submit for review', or 'merge request'. | 2 / 3 |
Distinctiveness Conflict Risk | Fairly specific to pull request creation which narrows the domain, but could overlap with broader Git/GitHub workflow skills or code review skills without clearer trigger 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 well-structured, highly actionable skill with clear phased workflows, explicit validation checkpoints, and concrete CLI commands. Its main weakness is verbosity in the review subagent section, which describes generic code review concerns Claude already knows (OWASP, race conditions, off-by-one errors) rather than project-specific heuristics. The inline subagent prompts could benefit from being extracted to a separate reference file.
Suggestions
Trim the subagent prompt descriptions to focus on project-specific conventions (e.g., harden(), SES, @metamask/superstruct) rather than generic review concerns Claude already knows (OWASP, off-by-one, race conditions).
Consider extracting the subagent review details into a separate REVIEW_AGENTS.md file and referencing it from the main skill to improve progressive disclosure and reduce the skill's length.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill is fairly detailed and well-structured, but some sections are verbose — particularly the subagent prompts which describe what to look for in generic terms Claude already knows (OWASP top-10, off-by-one mistakes, race conditions). The file classification triage table is useful but could be more compact. Overall mostly efficient with some bloat. | 2 / 3 |
Actionability | The skill provides specific, executable commands throughout (git status, git merge-base, git log, git diff, gh pr create, gh pr edit --add-label). The workflow is concrete with exact CLI invocations, clear conditionals, and specific file path references (e.g., docs/contributing/updating-changelogs.md). PR body format is specified concretely. | 3 / 3 |
Workflow Clarity | The workflow is clearly sequenced across 5 phases with explicit validation checkpoints: Phase 1 has stop conditions, Phase 2 has mandatory triage before proceeding, Phase 3 has blocker classification with explicit decision points (fix/proceed/abort), and Phase 5 has a conditional branch for changelog handling. Feedback loops are present (fix blockers → re-review). | 3 / 3 |
Progressive Disclosure | The skill references an external file (docs/contributing/updating-changelogs.md) appropriately, but the subagent review section is very long and inline — the four subagent prompt descriptions could be split into a separate reference file. For a ~120-line skill, the monolithic structure makes it harder to navigate, though the phase-based headers help. | 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 | |
- Repository
- MetaMask/ocap-kernel
- Commit
052f4d4
- 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.