mcpField
G
git-commit

git-commit

github.com/fredrikaverpilDevelopment25942 installsUpdated 3d ago
Repository

About git-commit

A skill for writing Git commit messages that follow Conventional Commits, including subject, body, breaking-change, and attribution rules. It is intended for contributors who want consistent messages and branch names.

Key features

  1. 01Conventional Commits format
  2. 02Commit type and scope guidance
  3. 03Subject and body rules
  4. 04Breaking-change notation
  5. 05Branch naming guidance
  6. 06Identity and signing safeguards

Use cases

  1. 01Writing a feature or bug-fix commit
  2. 02Documenting a breaking change
  3. 03Naming a branch for planned work

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/fredrikaverpil/dotfiles --skill git-commit

After installing, type/git-commitin Claude Code to confirm it loaded.

Details

From the project README

Git Commit Messages

Write commit messages following the Conventional Commits specification.

Format

<type>(<scope>): <description>

[optional body]

[optional footer(s)]

Types

TypePurpose
featNew feature
fixBug fix
docsDocumentation only
styleCode style (formatting, no logic change)
refactorCode change that neither fixes a bug nor adds a feature
perfPerformance improvement
testAdding or correcting tests
buildBuild system or external dependencies
ciCI configuration
choreMaintenance tasks
revertReverts a previous commit

Rules

  1. Use imperative mood in description ("add feature" not "added feature")
  2. Do not end description with a period
  3. Keep description under 72 characters
  4. Separate subject from body with a blank line
  5. Use the body to explain intent, nuances, gotchas, or background behind the change — not a paraphrase of the diff

Breaking Changes

Add ! after type/scope or include BREAKING CHANGE: in footer:

feat(api)!: remove deprecated endpoints

BREAKING CHANGE: The /v1/users endpoint has been removed.

Scope

Optional. Use to specify area of change (e.g., api, ui, auth, db).

Branch Naming

When creating a new branch, name it <type>/<kebab-description> using the same types as commit messages (e.g., feat/add-user-auth, fix/broken-symlinks).

Exception: when the environment has already assigned a branch (e.g., claude/... branches in Claude cloud sandbox sessions), keep it — never rename it or create a differently named branch to match this convention.

Identity, Signing and Attribution

Git identity and commit signing are configured by the environment (gitconfig on developer machines, a SessionStart hook in cloud sandboxes) — leave both to it:

  1. The message describes the change only: no Co-Authored-By, no "Generated with" lines, no session links or model names.
  2. Let git resolve the author from config — commit without --author or -c user.name=.../-c user.email=....
  3. Let git resolve signing from config — commit without -S, --gpg-sign or --no-gpg-sign, and leave signing-related config as it is.

Comments

Markdown supported