conventional-git

Enforces Conventional Commits v1.0.0 standards for git branch names, worktrees, and commit messages.

Updated May 23, 2026
One-click install
npx skills add https://github.com/Oatse/CWE-Automation --skill conventional-git-oatse
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: conventional-git
Source: https://github.com/Oatse/CWE-Automation/tree/main/.agents/skills/conventional-git
Command: npx skills add https://github.com/Oatse/CWE-Automation --skill conventional-git-oatse

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Inconsistent branch names and commit messages break changelog automation, SemVer versioning, and issue tracking. This Skill enforces Conventional Commits v1.0.0 so git history stays parseable by tooling and readable by teams. ## Core Features & Use Cases - Branch and Worktree Naming: Standardizes branch names as <type>/[issue-]<description> and mirrors them into .claude/worktrees/ directories for traceable local checkouts. - Commit Message Standards: Applies the full type table (feat, fix, build, chore, etc.), imperative mood, 72-character subjects, and !/BREAKING CHANGE: footers for SemVer-major releases. - Issue Auto-Closing: Formats Closes #42 footers correctly for GitHub and GitLab, including multi-issue and cross-repo references. - Use Case: When squash-merging a PR titled "Add user dashboard feature", the Skill flags that the title becomes the commit message and rewrites it as feat: add user dashboard so changelog generation does not silently break. ## Quick Start Ask the assistant to write a commit message or branch name for your current change, for example: "Write the commit message for the JWT refresh feature I just added."

Frequently Asked Questions about conventional-git

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I write a conventional commit message?

Use the format `<type>[optional scope]: <description>` with an imperative, lowercase subject under 72 characters. Pick the type from the standard table (feat, fix, docs, refactor, build, chore, etc.) and put body details after a blank line.

How should I name git branches with conventional commits?

Use `<type>/[issue-]<description>` in lowercase with hyphens only, such as `feat/42-user-authentication`. Keep the description under 50 characters and never include the word "worktree" in a branch name.

How do I mark a breaking change in a commit message?

Add `!` after the type or scope (e.g., `refactor!:`) or include a `BREAKING CHANGE:` footer. Describing the break only in the body is invisible to changelog tools and will not trigger a MAJOR SemVer bump.

Does the closing keyword work for multiple GitHub issues?

Yes, but each issue needs its own keyword: write `Closes #101, closes #102` or two separate footer lines. A single `Closes #101 and #102` only closes the first issue.

Should dependency updates use chore or build commit type?

Use `build` for dependency and build-system changes, not `chore`. The `chore` type is reserved for miscellaneous changes that do not touch src, test, or build configuration.

What happens to the commit message when squash merging a PR?

The PR title becomes the single squashed commit message. If the title does not follow Conventional Commits format, changelog generation breaks silently, so always fix the PR title before squashing.