pr-readiness-check
Check branch changes for common PR readiness issues (missing tests, missing JSDoc, guideline violations). Use when the user asks to verify changes before opening a PR, check code quality, or audit a branch for missing items.
92
89%
Does it follow best practices?
Impact
Pending
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 a well-crafted skill description that clearly communicates its purpose, lists specific capabilities, and includes an explicit 'Use when' clause with natural trigger terms. It follows the third-person voice convention and is concise without being vague. The description would perform well in a multi-skill selection scenario.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Lists multiple specific concrete actions: checking for missing tests, missing JSDoc, and guideline violations. These are clear, actionable capabilities rather than vague language. | 3 / 3 |
Completeness | Clearly answers both 'what' (check branch changes for missing tests, missing JSDoc, guideline violations) and 'when' (explicit 'Use when' clause covering verify before PR, check code quality, audit branch for missing items). | 3 / 3 |
Trigger Term Quality | Includes strong natural trigger terms users would say: 'PR readiness', 'verify changes', 'opening a PR', 'check code quality', 'audit a branch', 'missing tests', 'missing JSDoc'. These cover common variations of how users would phrase such requests. | 3 / 3 |
Distinctiveness Conflict Risk | Has a clear niche focused on pre-PR branch auditing for specific issues (tests, JSDoc, guidelines). The combination of PR readiness + branch-level checking + specific issue types makes it distinct from general code review or linting skills. | 3 / 3 |
Total | 12 / 12 Passed |
Implementation
79%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-crafted, concise skill that provides clear, actionable guidance for PR readiness checking. Its strengths are token efficiency and concrete, project-specific patterns that Claude wouldn't know independently. The main weakness is that the coding guideline violations are hardcoded inline rather than dynamically sourced from the referenced guideline files, which could lead to drift.
Suggestions
Instead of hardcoding guideline violations inline, instruct Claude to read and parse `.github/guidelines/CODING_GUIDELINES.md` and `.cursor/rules/` at runtime to stay in sync with the actual project guidelines.
Add a brief step to handle edge cases: what to do if the diff is empty (no changes) or if the base branch isn't `main`.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | Every section earns its place. No unnecessary explanations of what PRs are, what diffs are, or how git works. The heuristics and violation patterns are project-specific knowledge Claude wouldn't have, making them high-value tokens. | 3 / 3 |
Actionability | Provides executable git commands, specific file naming conventions (Foo.ts → Foo.test.ts), concrete violation patterns (StyleSheet.create(), `any` type, specific import patterns), and exact output format with examples. Claude can follow this directly. | 3 / 3 |
Workflow Clarity | Steps are clearly sequenced (collect diff → check tests → check JSDoc → check guidelines → output), but there's no validation or feedback loop. For instance, there's no step to verify the diff base branch is correct or handle edge cases like empty diffs. However, since this is a read-only/non-destructive operation, the lack of validation checkpoints is less critical. | 2 / 3 |
Progressive Disclosure | References external files (.github/guidelines/CODING_GUIDELINES.md, .cursor/rules/) which is good, but the guideline violations list is hardcoded inline rather than pointing to those files as the source of truth. For a skill under 50 lines this is acceptable, but the inline duplication of coding guidelines could drift out of sync with the actual guideline files. | 2 / 3 |
Total | 10 / 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.
- Repository
- MetaMask/metamask-mobile
- Commit
bee9b14
- 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.