conventional-branch
Skill48 starsChanged 18 days agoMITView on GitHub
Use when creating or validating a Git branch name so the branch follows a conventional type/description format, matches the work being done, and starts from the right base branch.
- Commits and pushes
4 other projects use a version of this.
Adopted by
Most recently taken up by
- github/awesome-copilottheir own version, first seen Oct 25, 2026
- open-sdr/openwifitheir own version, first seen Oct 8, 2026
- sherif-fanous/skillstheir own version, first seen Sep 8, 2026
- marc-ing/marc-skillstheir own version, first seen Aug 18, 2026
Other versions4 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 4
- github/awesome-copilot★ 41ksame name
- open-sdr/openwifi★ 4.9ksame name
- marc-ing/marc-skills★ 14same name
- sherif-fanous/skills★ 2same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository111 other files it gives its agents.
- AGENTS.mdAGENTS.md
- COPILOT-INSTRUCTIONS.mdCopilot instructions
- .github/copilot-instructions.mdCopilot instructions
- ai-visibilitySkill
- content-strategySkill
- seoSkill
- actions-debuggingSkill
- agentic-engineeringSkill
- autopilot-patternsSkill
- background-agentSkill
- context-primeSkill
- copilot-memorySkill
- cross-session-memorySkill
- ecosystem-intakeSkill
- fleet-parallelSkill
- github-code-searchSkill
- github-codespaces-efficiencySkill
- github-issue-triageSkill
- github-pr-workflowSkill
- ide-switchingSkill
- knowledge-curatorSkill
- mcp-builderSkill
- mcp-ecosystemSkill
- multi-model-strategySkill
- plan-mode-masterySkill
- scope-guardSkill
- session-managementSkill
- stack-detectorSkill
- sub-agent-sandboxingSkill
- task-intake-routerSkill
- team-plannerSkill
- token-cost-optimizerSkill
- api-and-interface-designSkill
- code-reviewSkill
- context-engineeringSkill
- cpp-debuggingSkill
- deprecation-and-migrationSkill
- diagnoseSkill
- fix-build-errorsSkill
- fix-github-issueSkill
- implementSkill
- improve-codebase-architectureSkill
- nestjs-prismaSkill
- nextjs-prismaSkill
- performance-optimizationSkill
- pr-multi-perspective-reviewSkill
- prototypeSkill
- react-vitestSkill
- receiving-code-reviewSkill
- refactor-cleanSkill
- reviewSkill
- skill-creatorSkill
- source-driven-developmentSkill
- spec-driven-developmentSkill
- systematic-debuggingSkill
- tdd-workflowSkill
- zoom-outSkill
- add-to-changelogSkill
- api-documentationSkill
- architecture-decisionsSkill
- The first 60 shown.
The file
We split this skill into the rules it gives an agent
9 rules. 0 are common, 8 are distinctive, and 1 is very specific to this project.
0
Common
Most of the 3 edited versions we read keep these.
8
Distinctive
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 16
Create branch names that are easy to scan, easy to sort, and easy to align with Conventional Commits.
- Distinctive: line 57
Use letters, digits, and hyphens in normal descriptions
- Distinctive: line 59
No spaces, underscores, or special characters
- Distinctive: line 60
No consecutive hyphens or dots
- Distinctive: line 62
No leading or trailing hyphen or dot in the description
- Very specific: line 88
If the user did not specify a type, default to feature unless the task is clearly a fix or release action.
- Distinctive: line 109
Use a quick validation pass before creating the branch:
- Distinctive: line 136
Prefer the remote default branch first, then fall back to local trunk branches:
- Distinctive: line 182
Keep the branch type aligned with the likely commit prefix when practical:
“Common” is measured: kept by at least 6 in 10 of the 3 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Conventional Branch
Create branch names that are easy to scan, easy to sort, and easy to align with Conventional Commits.
When to Use
- Starting a new task and no branch exists yet
- Renaming or validating a branch before pushing it
- Aligning branch naming with a team convention such as
feature/...orfix/... - Mapping a work item to a predictable branch slug before parallel work begins
When NOT to Use
| Instead of conventional-branch | Use |
| Writing or splitting commit messages | commit-workflow |
| Creating isolated parallel checkouts for multiple branches | using-git-worktrees |
| Switching to an already agreed branch name with no validation needed | create or checkout the branch directly |
Branch Shape
<type>/<description>Allowed types
| Type | Alias | Good fit |
feature | feat | New features or enhancements |
fix | bugfix | Non-urgent bug fixes |
hotfix | — | Urgent production fixes |
release | — | Release preparation branches |
docs | — | Documentation-only changes |
chore | — | Tooling, config, or housekeeping |
main, master, and develop remain reserved trunk branches. Do not treat
them as valid topic branch names in this workflow.
Naming Rules
- Lowercase only
- Use letters, digits, and hyphens in normal descriptions
- Allow dots only for release versions such as
release/v1.2.0 - No spaces, underscores, or special characters
- No consecutive hyphens or dots
- No
-.or.- - No leading or trailing hyphen or dot in the description
Valid examples
feature/add-login-page
feat/issue-123-add-login
fix/fix-header-overflow
hotfix/security-patch
release/v1.2.0
docs/update-docs-linksWorkflow
1. Decide the branch type
Choose the type from the actual work:
- new capability ->
feature - defect correction ->
fix - urgent production repair ->
hotfix - release prep ->
release - documentation-only change ->
docs - tooling or config cleanup ->
chore
If the user did not specify a type, default to feature unless the task is
clearly a fix or release action.
2. Normalize the description
Turn the work summary into a short kebab-case slug:
- keep 2-5 meaningful words
- include an issue number only when it helps disambiguate
- remove filler words
- replace spaces and underscores with hyphens
- collapse repeated separators
Examples:
Add OAuth Login->add-oauth-loginissue 123 fix header bug->issue-123-fix-header-bugRelease 1.2.0->v1.2.0
3. Validate the final name
Use a quick validation pass before creating the branch:
$branch = "feature/add-oauth-login"
if ($branch -cmatch '[A-Z]') { throw "Branch must be lowercase." }
if ($branch -match '[ _]') { throw "Branch cannot contain spaces or underscores." }
if ($branch -match '--|\.\.|-\.|\.-') { throw "Branch has an invalid separator sequence." }
if ($branch -notmatch '^(?:feature|feat|fix|bugfix|hotfix|release|docs|chore)\/[a-z0-9][a-z0-9.-]*[a-z0-9]$') {
throw "Branch does not match the conventional pattern."
}
$parts = $branch.Split('/', 2)
if ($parts.Count -eq 2) {
$type = $parts[0]
$description = $parts[1]
if ($type -ne 'release' -and $description -match '\.') {
throw "Dots are only allowed for release branches."
}
}For release branches, verify the description still looks like a version rather than a prose sentence.
4. Detect the base branch
Prefer the remote default branch first, then fall back to local trunk branches:
$base = git symbolic-ref --short refs/remotes/origin/HEAD 2>$null
if ($base) {
$base = $base -replace '^origin/', ''
} else {
foreach ($candidate in @('develop', 'main', 'master')) {
git show-ref --verify --quiet "refs/heads/$candidate"
if ($LASTEXITCODE -eq 0) {
$base = $candidate
break
}
}
}
if (-not $base) { throw "Could not determine the base branch." }5. Create and switch
$branch = "feature/add-oauth-login"
$hasRemoteBase = $false
git ls-remote --exit-code origin "refs/heads/$base" *> $null
if ($LASTEXITCODE -eq 0) {
$hasRemoteBase = $true
}
git checkout $base
if ($hasRemoteBase) {
git pull origin $base
}
git checkout -b $branchReport:
- the created branch name
- the detected base branch
- whether the branch started from a synced remote base or a local fallback
- the follow-up push command:
git push -u origin <branch>
Relationship to Conventional Commits
Keep the branch type aligned with the likely commit prefix when practical:
| Branch | Typical commit |
feature/add-login | feat: add login |
fix/fix-header | fix: correct header overflow |
docs/update-readme | docs: refresh setup guide |
chore/update-deps | chore: bump dependencies |
release/v1.2.0 | chore: release v1.2.0 |
Verification
- The branch name matches the allowed type/description format
- The slug is lowercase kebab-case (or release version form)
- Dots only appear in release branch descriptions
- The base branch was detected before checkout
- The final branch name describes the work without filler
See Also
commit-workflow- align later commit messages with the branch intentusing-git-worktrees- isolate multiple topic branches in parallel
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

