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 is too minimal. It lacks a 'Use when...' clause, misses common trigger term variations like 'PR' or 'merge request', and doesn't enumerate related capabilities that would help Claude distinguish this skill from other Git/GitHub-related skills.
Suggestions
Add a 'Use when...' clause with explicit triggers, e.g., 'Use when the user asks to open a pull request, submit a PR, or push changes for review.'
Include common trigger term variations such as 'PR', 'merge request', 'open PR', and 'submit for review'.
Consider listing additional related actions if applicable, such as setting PR title/description, adding reviewers, or specifying target branch.
| 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 should cap 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 | Somewhat specific to pull request creation, but could overlap with broader Git/GitHub skills or code review skills. The scope is narrow enough to avoid major conflicts but lacks explicit 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 workflow and good validation checkpoints. Its main weakness is length — the inlined subagent review instructions and file classification taxonomy add significant bulk that could be more concise or split into reference files. The concrete CLI commands and conditional logic make it immediately executable.
Suggestions
Condense the subagent prompt descriptions — Claude already knows how to review for OWASP vulnerabilities, race conditions, and off-by-one errors; just specify project-specific conventions (harden(), ocap model, SES compatibility) and let Claude apply general knowledge.
Consider extracting the file classification triage rules and subagent details into a separate reference file (e.g., REVIEW_GUIDE.md) to keep the main skill focused on the workflow sequence.
| 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 errors, race conditions). The triage classification table is useful but could be more compact. The repeated 'MANDATORY — DO NOT SKIP' warnings add some unnecessary emphasis. | 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). Each phase has concrete steps with exact CLI invocations and clear conditional logic for different scenarios (stacked PRs, docs-only changes, blockers). | 3 / 3 |
Workflow Clarity | The workflow is clearly sequenced across 5 phases with explicit validation checkpoints (Phase 1 pre-flight checks that halt on errors, Phase 3 blocker classification with fix/proceed/abort options, Phase 5 conditional changelog updates). The feedback loop for blockers (fix → re-review) is explicitly stated. The stacked PR detection logic is well-sequenced with clear conditionals. | 3 / 3 |
Progressive Disclosure | The skill references an external file (docs/contributing/updating-changelogs.md) appropriately for changelog details, but the main SKILL.md is quite long (~120 lines of substantive content) with the subagent review instructions inlined rather than split into separate reference files. The subagent prompt descriptions could be extracted to keep the main skill leaner, though no bundle files exist to support this. | 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
a3eff0e
- 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.