Source profileQuality 87/100Review permissions

github/awesome-copilot/skills/conventional-branch/SKILL.md

conventional-branch

Create Git branches following the Conventional Branch specification (feature/, bugfix/, hotfix/, release/, chore/). Use when creating a new branch, naming a branch, or checking whether a branch name complies with the spec.

Source repository stars
37,126
Declared platforms
0
Static risk flags
1
Last source update
2026-07-28
Source checked
2026-07-28

Decision brief

What it does—and where it fits

Create Git branches that follow the Conventional Branch specification — a simple, consistent convention for naming Git branches.

Best for

  • Use when creating a new branch, naming a branch, or checking whether a branch name complies with the spec.

Not for

  • Tasks that require unconfirmed production actions or broad system permissions.
  • Environments where the pinned source and install steps cannot be inspected.

Compatibility matrix

Platform support, with evidence labels

PlatformStatusEvidenceWhat to check
CodexNot declaredNo explicit evidencePortability before use
Claude CodeNot declaredNo explicit evidencePortability before use
CursorNot declaredNo explicit evidencePortability before use
Gemini CLINot declaredNo explicit evidencePortability before use
Open the compatibility checker

Installation

Inspect first. Install second.

The source command is displayed only when detected. A safe inspection prompt is always available so your agent can explain every action before execution.

Source-detected install commandSource
npx skills add https://github.com/github/awesome-copilot --skill "skills/conventional-branch"
Safe inspection promptEditorial

Inspect the Agent Skill "conventional-branch" from https://github.com/github/awesome-copilot/blob/9933dcad5be5caeb288cebcd370eeeb2fc2f1685/skills/conventional-branch/SKILL.md at commit 9933dcad5be5caeb288cebcd370eeeb2fc2f1685. List every install step, command, network request, credential, file read/write, external action, and rollback step. Explain whether it fits my task. Do not install or execute anything until I approve.

Workflow

What the source asks the agent to do

  1. 01

    Workflow

    Step 1 — Determine Branch Type

    Branch type — default to feature when uncertainBrief description — what the branch is forLowercase everything
  2. 02

    Branch Name Format

    main, master, and develop are trunk branches — they do not use a prefix. Never create new branches with the same names as trunk branches; branch off them instead.

    main, master, and develop are trunk branches — they do not use a prefix. Never create new branches with the same names as trunk branches; branch off them instead.
  3. 03

    Branch Types

    Review the “Branch Types” section in the pinned source before continuing.

    Review and apply the “Branch Types” source section.
  4. 04

    Trunk Branches

    main, master, and develop are trunk branches — they do not use a prefix. Never create new branches with the same names as trunk branches; branch off them instead.

    main, master, and develop are trunk branches — they do not use a prefix. Never create new branches with the same names as trunk branches; branch off them instead.

Permission review

Static risk signals and limitations

Runs scripts

medium · line 98

The documentation asks the agent to run terminal commands or scripts.

git symbolic-ref --short refs/remotes/origin/HEAD 2>/dev/null | sed 's|^origin/||'

Runs scripts

medium · line 105

The documentation asks the agent to run terminal commands or scripts.

git show-ref --verify --quiet "refs/heads/$b" && echo "$b" && break

Evidence record

Why each signal appears

EvidenceSourceComputedTestedEditorial
SignalValueEvidence typeMeaning
Quality score87/100ComputedDocumentation, specificity, maintenance, and trust rules
Repository stars37,126SourceRepository attention, not individual Skill quality
Compatibility0 platformsSourceDeclared in the catalog source record
Usage guideautomated source guideEditorialGenerated or reviewed according to the visible evidence level

Pinned source

Provenance and original SKILL.md

Repository
github/awesome-copilot
Skill path
skills/conventional-branch/SKILL.md
Commit
9933dcad5be5caeb288cebcd370eeeb2fc2f1685
License
MIT
Collected
2026-07-28
Default branch
main
View the original SKILL.md

Conventional Branch

Create Git branches that follow the Conventional Branch specification — a simple, consistent convention for naming Git branches.

Branch Name Format

<type>/<description>

Branch Types

TypeAliasPurpose
feature/feat/New features or enhancements
bugfix/fix/Bug fixes
hotfix/Urgent production fixes
release/Release preparation (dots allowed in version: release/v1.2.0)
chore/Non-code tasks (deps, docs, config)

Trunk Branches

main, master, and develop are trunk branches — they do not use a prefix. Never create new branches with the same names as trunk branches; branch off them instead.

Naming Rules

  • Lowercase only — no uppercase letters anywhere
  • Alphanumerics, hyphens, and dotsa-z, 0-9, -, .
  • Dots allowed only in release/ version descriptions (e.g., release/v1.2.0)
  • No underscores, spaces, or special characters
  • No consecutive hyphens (--), dots (..), or hyphen-dot adjacency (-. or .-)
  • No leading or trailing hyphens or dots in the description

Valid Examples

main
master
develop
feature/add-login-page
feat/add-login-page
bugfix/fix-header-bug
fix/header-bug
hotfix/security-patch
release/v1.2.0
chore/update-dependencies
feature/issue-123-new-login

Invalid Examples

BranchProblem
Feature/Add-LoginUppercase letters
feature/new--loginConsecutive hyphens
feature/-new-loginLeading hyphen
feature/new-login-Trailing hyphen
release/v1.-2.0Hyphen adjacent to dot
fix/header bugSpace
fix/header_bugUnderscore
unknown/some-taskUnknown prefix type

Description Guidelines

  • Use kebab-case with 2-5 words
  • Be descriptive but concise (~50 chars total)
  • Good: add-oauth-login, fix-header-overflow, update-ci-config
  • Bad: fix-bug, new-feature

Workflow

Follow these steps:

Step 1 — Determine Branch Type

Ask the user (if not already clear):

  • Branch type — default to feature when uncertain
  • Brief description — what the branch is for

If the user mentions a ticket or issue number, include it in the description (e.g., feature/issue-123-add-oauth).

Step 2 — Validate the Name

Check the assembled name against the Naming Rules above. If any rule fails, fix it:

  • Lowercase everything
  • Replace underscores and spaces with hyphens
  • Collapse consecutive hyphens
  • Strip leading/trailing hyphens

Step 3 — Detect the Base Branch

Different repos use different trunk branches. Detect which one this repo uses:

# Prefer the remote's default branch
git symbolic-ref --short refs/remotes/origin/HEAD 2>/dev/null | sed 's|^origin/||'

If that returns nothing, check which trunk branch exists locally (priority order: develop, main, master):

for b in develop main master; do
  git show-ref --verify --quiet "refs/heads/$b" && echo "$b" && break
done

Step 4 — Create and Checkout

git checkout <base>
git pull origin <base>
git checkout -b <type>/<description>

Step 5 — Confirm

Tell the user:

  • The branch name that was created
  • That they are now on the new branch
  • Remind them: git push -u origin <branch-name> when ready

Relationship with Conventional Commits

Conventional Branch complements Conventional Commits:

Conventional BranchTypical Conventional Commit
feature/add-loginfeat: add login page
bugfix/fix-headerfix: header overflow on mobile
chore/update-depschore: bump lodash to 5.0
release/v1.2.0chore: release v1.2.0

Align the branch type with commit types where possible (e.g., feature/* branches with feat: commits).

Alternatives

Compare before choosing