conventional-git
Skill2 starsChanged 7 months agoMITView on GitHub
Conventional Commits v1.0.0 branch naming and commit message standards for GitHub and GitLab projects. Use when creating branches, writing commits, generating commit messages, reviewing branch conventions, or setting up changelog automation. Apply when your project needs consistent git history, SemVer-driven releases, parseable changelog generation, or automatic issue closing.
4 other projects use a version of this, 2 of them edited.
Adopted by
Most recently taken up by
- samber/cc-skillsedited, first seen Nov 1, 2026
- BINGWU2003/skillstheir own version, first seen Oct 13, 2026
- ebal/AI-Skillsedited, first seen Jul 15, 2026
- SilvrDuck/skillstheir own version, first seen May 28, 2026
Other versions4 projects use a version of this.
Word for word · 0
None found.
Edited · 2
- samber/cc-skills★ 24278% same
- ebal/AI-Skills★ 076% same
Wrote their own version · 2
- BINGWU2003/skills★ 3same name
- SilvrDuck/skills★ 1same 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 repository12 other files it gives its agents.
- CLAUDE.mdCLAUDE.md
- chrome-extensionSkill
- crxjsSkill
- deep-researchSkill
- humaniseur-frSkill
- linkedin-ghostwritingSkill
- press-release-writerSkill
- promql-cliSkill
- snyk-agent-scan-complianceSkill
- substack-ghostwritingSkill
- technical-article-writerSkill
- training-reportSkill
The file
We split this skill into the rules it gives an agent
6 rules. 3 are common, 0 are distinctive, and 3 are very specific to this project.
3
Common
Most of the 3 edited versions we read keep these.
0
Distinctive
This author's own choices. Worth a look.
3
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Common: line 21
Follow Conventional Commits v1.0.0 for both branch names and commit messages — consistent naming lets tools auto-generate changelogs, …
- Very specific: line 38
NEVER include worktree in a branch name — git worktrees are a local checkout mechanism, not a branch concept.
- Common: line 68
No capital letter, no trailing period — enforces uniform parsing by changelog tools
- Very specific: line 72
NEVER add a Claude signature, AI agent attribution, or Co-authored-by trailer for Claude or any other AI agent to commits
- Very specific: line 144
Use scope consistently within a branch — feat(auth): throughout, not feat(user): mid-way
- Common: line 145
Squash merge: when squash-merging a PR/MR, the branch commits are collapsed into one — the PR/MR title becomes the commit message.
“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 Commits & Branch Naming
Follow Conventional Commits v1.0.0 for both branch names and commit messages — consistent naming lets tools auto-generate changelogs, enforce SemVer bumps, and filter history by concern.
Branch Naming
Format: <type>/[issue-]<description> — lowercase, hyphens only, no special chars except /.
feat/user-authentication
feat/42-user-authentication
fix/login-race-condition
fix/87-login-race-condition
docs/api-reference-update
refactor/payment-modulePrefix with the issue number when one exists — GitHub and GitLab auto-link it and it makes git log immediately traceable to the tracker. Keep the description under 50 characters — most git UIs truncate branch names in lists around that length. Match the type to the work you're doing — this is the contract readers use to understand the branch purpose at a glance.
NEVER include worktree in a branch name — git worktrees are a local checkout mechanism, not a branch concept; the name would leak implementation details into the remote and confuse other contributors.
Commit Message Format
<type>[optional scope]: <description>
[optional body]
[optional footer(s)]Types:
| Type | SemVer | When |
feat | MINOR | New feature |
fix | PATCH | Bug fix |
docs | — | Docs only |
style | — | Formatting, no logic change |
refactor | — | Restructure, no feature/fix |
perf | — | Performance improvement |
test | — | Add/fix tests |
build | — | Build system, deps |
ci | — | CI config |
chore | — | Anything else (not src/test) |
revert | — | Reverts a previous commit |
Rules:
- Subject line ≤ 72 characters — git log and GitHub/GitLab UIs silently truncate longer subjects
- Imperative mood: "add" not "added" — reads as an instruction, not a history log
- No capital letter, no trailing period — enforces uniform parsing by changelog tools
- Body separated by blank line — parsers split header/body at the first blank line
- Breaking changes: use
!after type/scope, or addBREAKING CHANGE:footer (triggers MAJOR bump) — body-only descriptions are invisible to changelog tools revertcommits SHOULD includeThis reverts commit <hash>.in the body —git revertgenerates this automatically; don't strip it- NEVER add a Claude signature, AI agent attribution, or
Co-authored-bytrailer for Claude or any other AI agent to commits
Examples:
feat(auth): add JWT token refreshfix: prevent race condition on concurrent requests
Introduce request ID and reference to latest request.
Dismiss responses from stale requests.refactor!: drop support for Go 1.18
BREAKING CHANGE: Go 1.18 no longer supported; uses stdlib APIs from 1.21+Closing Issues via Commit Messages
Both GitHub and GitLab detect keywords in commit messages and automatically close the referenced issue when the commit lands on the default branch. Place the reference in the footer (preferred — keeps the subject line clean).
Keywords: close, closes, closed, fix, fixes, fixed, resolve, resolves, resolved — case-insensitive.
GitHub:
fix(auth): prevent token expiry race condition
Closes #42
Closes owner/repo#99- Triggers when merged into the default branch (usually
main) - Cross-repo:
Closes owner/repo#42 - Close multiple:
Closes #42, closes #43 - Works in PR descriptions too
GitLab:
feat: add dark mode support
Resolves #101
Closes group/project#42- Triggers when merged into the default branch (configurable per project)
- Cross-project:
Closes group/project#42 - Close multiple:
Closes #101, closes #102 - Works in MR descriptions too
Tip: Pair with the commit type — fix: closing a bug issue, feat: closing a feature request — keeps the changelog semantically coherent.
Common Mistakes
| Mistake | Fix |
feat: Added login page | feat: add login page — imperative, no capital |
fix: fix bug. | fix: fix bug — no trailing period |
| Subject over 72 chars | Shorten; move detail to body |
| Breaking change only in body | Add ! or BREAKING CHANGE: footer — tools won't detect body-only |
feat(adding-auth): ... | feat(auth): ... — scope is a noun, not a verb |
| Closes #42 in subject line | Move to footer — keeps subject clean and parseable |
Best Practices
- Align branch type and commit type —
feat/auth-*branch →feat(auth):commits - One concern per branch — mixing fixes into feature branches obscures the changelog
- Use scope consistently within a branch —
feat(auth):throughout, notfeat(user):mid-way - Squash merge: when squash-merging a PR/MR, the branch commits are collapsed into one — the PR/MR title becomes the commit message. If the title doesn't follow conventional commits format, changelog generation breaks silently. Always set the PR title before squashing.
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.

