Use when implementation is complete, all tests pass, and you need to decide how to integrate the work - guides completion of development work by presenting structured options for merge, PR, or cleanup
88
83%
Does it follow best practices?
Impact
98%
1.92xAverage score across 3 eval scenarios
Passed
No known issues
Quality
Discovery
75%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 effectively communicates when to use the skill with a clear 'Use when' clause that specifies precise trigger conditions. Its main weakness is that the actual capabilities are somewhat vaguely described as 'presenting structured options' rather than listing specific concrete actions. The trigger terms could also be expanded to cover more natural user phrasings.
Suggestions
Be more specific about what the skill actually does - e.g., 'Presents structured options for merging to main, creating a pull request, or performing branch cleanup, with step-by-step guidance for each path'
Add more natural trigger term variations such as 'pull request', 'ready to merge', 'done coding', 'submit changes', 'finish feature branch'
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Names the domain (development workflow completion) and some actions (merge, PR, cleanup), but the actions are presented as options rather than concrete capabilities the skill performs. 'Guides completion of development work by presenting structured options' is somewhat vague about what it actually does. | 2 / 3 |
Completeness | Clearly answers both 'what' (guides completion of development work by presenting structured options for merge, PR, or cleanup) and 'when' (when implementation is complete, all tests pass, and you need to decide how to integrate the work). The 'Use when' clause is explicit and well-defined. | 3 / 3 |
Trigger Term Quality | Includes some relevant terms like 'merge', 'PR', 'tests pass', 'cleanup', and 'implementation is complete', which are natural developer terms. However, it misses common variations like 'pull request', 'push changes', 'submit code', 'done coding', 'finish feature', or 'ready to merge'. | 2 / 3 |
Distinctiveness Conflict Risk | This has a clear niche - it's specifically for the post-implementation decision point about how to integrate completed work. The trigger conditions (implementation complete + tests pass + integration decision needed) are quite specific and unlikely to conflict with coding, testing, or git skills. | 3 / 3 |
Total | 10 / 12 Passed |
Implementation
92%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This is a high-quality skill that provides a clear, actionable workflow for completing development branches. It excels at conciseness and actionability—every section is purposeful with executable commands and explicit decision points. The validation checkpoints (test verification, discard confirmation) and the structured 4-option presentation make this a robust, safe workflow. Minor improvement could come from splitting detailed option execution into a reference file for very long conversations.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill is lean and efficient throughout. It doesn't explain what git, PRs, or worktrees are—it assumes Claude knows. Every section serves a purpose, and the quick reference table is a compact summary rather than redundant content. | 3 / 3 |
Actionability | Every step includes executable bash commands, exact text to present to users, and specific behaviors (e.g., 'Stop. Don't proceed to Step 2'). The PR creation command with gh and the merge workflow are copy-paste ready. | 3 / 3 |
Workflow Clarity | The workflow is clearly sequenced (verify → determine base → present options → execute → cleanup) with explicit validation checkpoints: tests must pass before proceeding, tests are re-run after merge, and discard requires typed confirmation. Error recovery is addressed (test failures block progress, re-verify after merge). | 3 / 3 |
Progressive Disclosure | The content is well-structured with clear sections and a quick reference table, but it's all inline in one file. For its length (~150 lines), some content like the detailed option execution steps or common mistakes could be referenced externally. However, the integration section nicely signals relationships to other skills. | 2 / 3 |
Total | 11 / 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.
b7a8f76
Table of Contents
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.