# Git Commit

> This skill should be used BEFORE running any git commit command. Triggers when about to run `git commit`. Ensures commit messages follow Conventional Commits specification and prompts for the Jira ticket number.

- Skill: `fredrikaverpil/git-commit-2` (Agent Skill)
- Install (CLI): `npx skillmds@latest add fredrikaverpil/git-commit-2`
- Raw SKILL.md: https://api.skillmd.com/api/skills/fredrikaverpil/git-commit-2/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: fredrikaverpil (https://skillmd.com/u/fredrikaverpil)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/fredrikaverpil/git-commit-2

---


# Git Commit Messages

Write commit messages following the Conventional Commits specification.

## Format

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

[optional body]

[optional footer(s)]
```

## Types

| Type       | Purpose                                                 |
| ---------- | ------------------------------------------------------- |
| `feat`     | New feature                                             |
| `fix`      | Bug fix                                                 |
| `docs`     | Documentation only                                      |
| `style`    | Code style (formatting, no logic change)                |
| `refactor` | Code change that neither fixes a bug nor adds a feature |
| `perf`     | Performance improvement                                 |
| `test`     | Adding or correcting tests                              |
| `build`    | Build system or external dependencies                   |
| `ci`       | CI configuration                                        |
| `chore`    | Maintenance tasks                                       |
| `revert`   | Reverts 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
6. Always ask me for the Jira ticket number before committing. If there is one,
   include it as the last line in the commit body (e.g., `XY-123`). If there
   isn't one, ask whether to create one.

## 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>/<jira-ticket>` with the ticket
lowercased, using the same types as commit messages (e.g., `feat/xy-123`,
`fix/xy-456`). If there is no Jira ticket, fall back to
`<type>/<kebab-description>` (e.g., `feat/add-user-auth`).

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.