How do I install the Git Commit skill?

Run npx skillmds@latest add fredrikaverpil/git-commit-2 in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Git Commit safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Git Commit?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Git Commit free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Git Commit?

fredrikaverpil (@fredrikaverpil) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Git Commit by fredrikaverpil — Agent Skill

Name: Git Commit
Author: fredrikaverpil

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.

File contents

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

Use imperative mood in description ("add feature" not "added feature")
Do not end description with a period
Keep description under 72 characters
Separate subject from body with a blank line
Use the body to explain intent, nuances, gotchas, or background behind the change — not a paraphrase of the diff
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:

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

---name: git-commit-2description: 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.---# Git Commit MessagesWrite 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 |## Rules1. Use imperative mood in description ("add feature" not "added feature")2. Do not end description with a period3. Keep description under 72 characters4. Separate subject from body with a blank line5. Use the body to explain intent, nuances, gotchas, or background behind the change — not a paraphrase of the diff6. 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 ChangesAdd **!** after type/scope or include **BREAKING CHANGE:** in footer:```feat(api)!: remove deprecated endpointsBREAKING CHANGE: The /v1/users endpoint has been removed.```## ScopeOptional. Use to specify area of change (e.g., `api`, `ui`, `auth`, `db`).## Branch NamingWhen creating a new branch, name it `<type>/<jira-ticket>` with the ticketlowercased, 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 — neverrename it or create a differently named branch to match this convention.## Identity, Signing and AttributionGit identity and commit signing are configured by the environment (gitconfigon developer machines, a SessionStart hook in cloud sandboxes) — leave both toit: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.

Frequently asked questions