branch-namer
Generate descriptive git branch names that follow the project's naming convention. Use this skill whenever the user asks to create a branch, name a branch, start working on a feature or fix, checkout a new branch, or when you're about to run `git checkout -b` or `git switch -c`. Also trigger when you see a vague branch name like `fix/auth` or `feature/billing` that lacks a description of what's actually changing — the branch name should always tell you *what* the change does, not just its category.
90
88%
Does it follow best practices?
Impact
93%
1.14xAverage score across 3 eval scenarios
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 an excellent skill description that clearly defines its purpose, provides comprehensive trigger terms covering both user intent phrases and specific git commands, and explicitly states when it should be activated. The inclusion of anti-patterns (vague branch names) as additional triggers is a particularly strong touch that helps Claude know when to proactively apply this skill.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | The description lists a concrete action ('Generate descriptive git branch names') and specifies the naming convention constraint. It also describes what a good vs bad branch name looks like (e.g., 'fix/auth' is vague, branch name should tell what the change does). | 3 / 3 |
Completeness | Clearly answers both 'what' (generate descriptive git branch names following project naming convention) and 'when' (explicit 'Use this skill whenever...' clause with multiple detailed trigger scenarios). | 3 / 3 |
Trigger Term Quality | Excellent coverage of natural trigger terms: 'create a branch', 'name a branch', 'start working on a feature or fix', 'checkout a new branch', 'git checkout -b', 'git switch -c', and even vague branch name patterns like 'fix/auth' or 'feature/billing'. | 3 / 3 |
Distinctiveness Conflict Risk | Very specific niche — git branch naming specifically. Unlikely to conflict with general git skills, commit message skills, or other development skills due to the precise focus on branch name generation and the explicit trigger conditions. | 3 / 3 |
Total | 12 / 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, actionable skill with excellent concrete examples and a clear workflow. Its main weakness is moderate verbosity — the motivational 'Problem' section and detailed CI/CD type table add tokens without proportional value for the core task of naming branches. The examples table is the standout element, providing exactly the kind of pattern-matching guidance Claude needs.
Suggestions
Remove or condense the 'The Problem' section — Claude doesn't need motivation for why descriptive names are better; jump straight to the format.
Consider moving the CI/CD type behavior table to a separate reference file and keeping only the type list inline, since release triggers are tangential to branch naming.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The CI/CD behavior table and type explanations add useful project-specific context Claude wouldn't know, but the opening 'The Problem' section explaining why descriptive names matter is unnecessary — Claude understands this. The auto-approve footnote and release trigger details are borderline verbose for a branch naming skill. | 2 / 3 |
Actionability | The examples table with bad vs. good branch names is highly concrete and actionable. The format template, slug-writing principles, and component definitions give Claude everything needed to generate correct branch names without ambiguity. | 3 / 3 |
Workflow Clarity | The 6-step workflow is clearly sequenced and includes a validation-like step (check total length) and a confirmation step (suggest before creating). For a non-destructive operation like naming a branch, this level of workflow clarity is fully appropriate. | 3 / 3 |
Progressive Disclosure | The content is well-structured with clear sections, but the CI/CD behavior table and detailed type usage guidance could be split into a reference file. For a skill of this length (~80 lines of substantive content), it's slightly monolithic but not egregiously so. | 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
- akash-network/console
- Commit
609b56d
- 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.