CtrlK
BlogDocsLog inGet started
Tessl Logo

finishing-a-development-branch

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

64

Quality

76%

Does it follow best practices?

Impact

No eval scenarios have been run

SecuritybySnyk

Passed

No known issues

Optimize this skill with Tessl

npx tessl skill review --optimize ./skills/finishing-a-development-branch/SKILL.md
SKILL.md
Quality
Evals
Security

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 has strong completeness with an explicit 'Use when' clause and clear trigger conditions, and it occupies a distinct niche in the development workflow. However, it could be more specific about what concrete actions the skill performs beyond 'presenting structured options,' and could benefit from additional natural trigger term variations that developers might use.

Suggestions

Add more specific concrete actions the skill performs, e.g., 'Presents structured options for merging branches, creating pull requests, squashing commits, or cleaning up feature branches'

Include additional natural trigger term variations like 'pull request', 'push changes', 'ready to merge', 'submit code', 'done with feature' to improve keyword coverage

DimensionReasoningScore

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

Explicitly 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 present and specific.

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 task', or 'ready to merge'.

2 / 3

Distinctiveness Conflict Risk

This has a clear niche: post-implementation decision-making about code integration. The specific trigger conditions (implementation complete, tests passing, deciding integration method) make it unlikely to conflict with general coding, testing, or git skills.

3 / 3

Total

10

/

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 — the multi-step process is well-sequenced with proper validation gates, confirmation steps, and clear branching logic for different environments. The main weakness is some redundancy between the workflow steps, Common Mistakes, and Red Flags sections, which inflates the token cost without adding proportional value. The content would benefit from consolidating the cautionary guidance into fewer, non-overlapping sections.

Suggestions

Consolidate 'Common Mistakes' and 'Red Flags' into a single concise section to eliminate the significant overlap between them (e.g., worktree cleanup warnings, test verification, and discard confirmation appear in both).

DimensionReasoningScore

Conciseness

The skill is mostly efficient and avoids explaining basic git concepts, but the 'Common Mistakes' and 'Red Flags' sections have significant overlap (e.g., worktree cleanup warnings appear in both), and some content in Step 5/6 is repeated across the narrative and the quick reference table. The 'Red Flags' Never/Always lists largely restate what's already covered in the workflow steps.

2 / 3

Actionability

Every step includes concrete, executable bash commands and exact menu text to present. The environment detection logic, merge workflow, PR creation with gh CLI, and cleanup commands are all copy-paste ready with specific conditionals and variable assignments.

3 / 3

Workflow Clarity

The 6-step process is clearly sequenced with explicit validation checkpoints: tests must pass before proceeding (Step 1), tests run again after merge (Step 5 Option 1), typed confirmation required before discard (Option 4), and worktree removal only after merge success. The decision table for environment detection and the quick reference table make branching logic unambiguous.

3 / 3

Progressive Disclosure

The content is well-structured with clear headers and a quick reference table, but it's a fairly long monolithic document (~180 lines of substantive content) with no external references. The Common Mistakes and Red Flags sections could potentially be split out or consolidated to reduce the main file's length, though the lack of bundle files means there's no supporting structure to offload to.

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.

Validation11 / 11 Passed

Validation for skill structure

No warnings or errors.

Repository
obra/superpowers
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.