agentleFS
drvossdrvoss/everything-copilot-cli/skills/workflow/conventional-branch/SKILL.md

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

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
  1. Distinctive:

    Create branch names that are easy to scan, easy to sort, and easy to align with Conventional Commits.

    line 16
  2. Distinctive:

    Use letters, digits, and hyphens in normal descriptions

    line 57
  3. Distinctive:

    No spaces, underscores, or special characters

    line 59
  4. Distinctive:

    No consecutive hyphens or dots

    line 60
  5. Distinctive:

    No leading or trailing hyphen or dot in the description

    line 62
  6. Very specific:

    If the user did not specify a type, default to feature unless the task is clearly a fix or release action.

    line 88
  7. Distinctive:

    Use a quick validation pass before creating the branch:

    line 109
  8. Distinctive:

    Prefer the remote default branch first, then fall back to local trunk branches:

    line 136
  9. Distinctive:

    Keep the branch type aligned with the likely commit prefix when practical:

    line 182

“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.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

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/... or fix/...
  • Mapping a work item to a predictable branch slug before parallel work begins

When NOT to Use

Instead of conventional-branchUse
Writing or splitting commit messagescommit-workflow
Creating isolated parallel checkouts for multiple branchesusing-git-worktrees
Switching to an already agreed branch name with no validation neededcreate or checkout the branch directly

Branch Shape

<type>/<description>

Allowed types

TypeAliasGood fit
featurefeatNew features or enhancements
fixbugfixNon-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-links

Workflow

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:

  1. keep 2-5 meaningful words
  2. include an issue number only when it helps disambiguate
  3. remove filler words
  4. replace spaces and underscores with hyphens
  5. collapse repeated separators

Examples:

  • Add OAuth Login -> add-oauth-login
  • issue 123 fix header bug -> issue-123-fix-header-bug
  • Release 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 $branch

Report:

  1. the created branch name
  2. the detected base branch
  3. whether the branch started from a synced remote base or a local fallback
  4. 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:

BranchTypical commit
feature/add-loginfeat: add login
fix/fix-headerfix: correct header overflow
docs/update-readmedocs: refresh setup guide
chore/update-depschore: bump dependencies
release/v1.2.0chore: 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 intent
  • using-git-worktrees - isolate multiple topic branches in parallel

Download now (ZIP)

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
What did you use it for? e.g. Reviewing pull requests in a Rails app

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.