prepare-pr
Prepare a GitHub PR for merge by rebasing onto main, fixing review findings, running gates, committing fixes, and pushing to the PR head branch. Use after /reviewpr. Never merge or push to main.
85
81%
Does it follow best practices?
Impact
Pending
No eval scenarios have been run
Advisory
Suggest reviewing before use
Quality
Discovery
85%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 strong description that clearly defines a specific workflow step in a PR lifecycle. It excels at specificity and distinctiveness by listing concrete actions and establishing clear boundaries. The main weakness is trigger term coverage—it could include more natural user phrasings like 'pull request', 'address feedback', or 'prepare PR for merge'.
Suggestions
Add natural user-facing trigger terms like 'pull request', 'address review comments', 'fix PR feedback', or 'prepare PR for merge' to improve discoverability.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Lists multiple specific concrete actions: rebasing onto main, fixing review findings, running gates, committing fixes, and pushing to the PR head branch. These are clear, actionable steps. | 3 / 3 |
Completeness | Clearly answers 'what' (rebase, fix findings, run gates, commit, push) and 'when' ('Use after /reviewpr'). Also includes an explicit constraint ('Never merge or push to main'), which adds clarity about boundaries. | 3 / 3 |
Trigger Term Quality | Includes relevant terms like 'PR', 'merge', 'rebase', 'GitHub', and 'review findings', but misses common user variations like 'pull request', 'fix up PR', 'prepare for merge', or 'address review comments'. The '/reviewpr' reference is internal jargon rather than a natural user term. | 2 / 3 |
Distinctiveness Conflict Risk | Highly distinctive with a clear niche: preparing a PR for merge after review. The explicit workflow position ('Use after /reviewpr') and constraints ('Never merge or push to main') make it very unlikely to conflict with other skills. | 3 / 3 |
Total | 11 / 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, highly actionable skill with excellent workflow clarity and explicit safety guardrails. The 12-step process is well-sequenced with concrete commands, validation checkpoints, and clear error recovery paths. The main weaknesses are some redundancy in safety warnings across multiple sections and the monolithic structure that could benefit from splitting auxiliary guidance into referenced files.
Suggestions
Consolidate the repeated safety rules (no push to main, no git add -A, no git clean -fdx) into a single Safety section rather than repeating them across Safety, Known Footguns, and Guardrails.
Consider extracting the changelog and docs update guidance (steps 5-6) into a referenced file to reduce the main skill's length and improve progressive disclosure.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill is mostly efficient and avoids explaining concepts Claude already knows, but there is some redundancy—safety rules about not pushing to main and not using `git add -A` are repeated in Safety, Known Footguns, and Guardrails sections. The overall length is justified by the complexity of the workflow, but could be tightened by consolidating repeated warnings. | 2 / 3 |
Actionability | The skill provides fully executable shell commands at every step, with specific flags, variable assignments, and concrete examples. Commands are copy-paste ready with clear placeholders like `<PR>`, and fallback paths are provided (e.g., if `committer` is not found, use `git commit`). | 3 / 3 |
Workflow Clarity | The 12-step workflow is clearly sequenced with explicit validation checkpoints: conflict resolution limits (stop after 3), gate retry limits (max 3 cycles), mandatory verification that PR is not behind main after push, and a final gate-pass check before printing the completion message. Feedback loops for error recovery are well-defined throughout. | 3 / 3 |
Progressive Disclosure | The content is well-structured with clear sections and headers, but it's a long monolithic file with no references to supporting documents. The review findings dependency on `.local/review.md` is well-signaled, but content like the changelog update process or docs update guidance could potentially be split out. For a skill of this complexity, the single-file approach is borderline acceptable but not ideal. | 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
- deepgram/dglabs-deepclaw
- Commit
ec8d4f8
- 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.