How do I install the Git Conventional Commits skill?

Run npx skillmds@latest add gktuoktay/git-conventional-commits 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 Conventional Commits 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 Conventional Commits?

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 Conventional Commits free to use?

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

Who published Git Conventional Commits?

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

Git Conventional Commits by gktuoktay

Name: Git Conventional Commits
Author: GktuOktay

File contents

Git Conventional Commits Guide

This skill provides guidelines for writing clean, structured, and standardized commit messages and branch names using the Conventional Commits specification.

Branch Naming Conventions

Always use descriptive and structured branch names. This helps in understanding the context of the work.

Format

<type>/<issue-ticket>-<short-description>

Types

feature/ or feat/: For new features
bugfix/ or fix/: For bug fixes
hotfix/: For critical production fixes
chore/: For maintenance, dependency updates, etc.
docs/: For documentation changes

Examples

feature/PROJ-123-add-user-login
fix/PROJ-456-resolve-null-pointer
chore/update-dependencies

Conventional Commits Specification

Commit messages should be structured as follows:

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

Commit Types

Type	Description
`feat`	A new feature
`fix`	A bug fix
`docs`	Documentation only changes
`style`	Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
`refactor`	A code change that neither fixes a bug nor adds a feature
`perf`	A code change that improves performance
`test`	Adding missing tests or correcting existing tests
`build`	Changes that affect the build system or external dependencies
`ci`	Changes to our CI configuration files and scripts
`chore`	Other changes that don't modify src or test files
`revert`	Reverts a previous commit

Scope (Optional)

The scope provides context to where the changes were made (e.g., auth, ui, database). Example: feat(auth): implement JWT token verification

Description

Use the imperative, present tense: "change" not "changed" nor "changes".
Don't capitalize the first letter.
No dot (.) at the end.

Body (Optional)

Just as in the description, use the imperative, present tense.
The body should include the motivation for the change and contrast this with previous behavior.

Breaking Changes

A commit that has a footer BREAKING CHANGE:, or appends a ! after the type/scope, introduces a breaking API change.

Example:

feat(api)!: remove deprecated v1 endpoints

BREAKING CHANGE: The v1 endpoints are no longer available. Use v2 instead.

Checklist for Good Commits

Have I used the correct type?
Is the description concise and clear?
Did I use the imperative mood in the subject line?
Have I included a body to explain the 'why' if necessary?
Are breaking changes clearly marked?

---name: git-conventional-commitsdescription: Git commit mesajları ve branch isimlendirme standartlarını belirler. Conventional Commits kurallarını uygular.---# Git Conventional Commits GuideThis skill provides guidelines for writing clean, structured, and standardized commit messages and branch names using the Conventional Commits specification.## Branch Naming ConventionsAlways use descriptive and structured branch names. This helps in understanding the context of the work.### Format`<type>/<issue-ticket>-<short-description>`### Types- `feature/` or `feat/`: For new features- `bugfix/` or `fix/`: For bug fixes- `hotfix/`: For critical production fixes- `chore/`: For maintenance, dependency updates, etc.- `docs/`: For documentation changes### Examples- `feature/PROJ-123-add-user-login`- `fix/PROJ-456-resolve-null-pointer`- `chore/update-dependencies`## Conventional Commits SpecificationCommit messages should be structured as follows:```<type>[optional scope]: <description>[optional body][optional footer(s)]```### Commit Types| Type | Description ||------------|-------------|| `feat` | A new feature || `fix` | A bug fix || `docs` | Documentation only changes || `style` | Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc) || `refactor` | A code change that neither fixes a bug nor adds a feature || `perf` | A code change that improves performance || `test` | Adding missing tests or correcting existing tests || `build` | Changes that affect the build system or external dependencies || `ci` | Changes to our CI configuration files and scripts || `chore` | Other changes that don't modify src or test files || `revert` | Reverts a previous commit |### Scope (Optional)The scope provides context to where the changes were made (e.g., `auth`, `ui`, `database`).Example: `feat(auth): implement JWT token verification`### Description- Use the imperative, present tense: "change" not "changed" nor "changes".- Don't capitalize the first letter.- No dot (.) at the end.### Body (Optional)- Just as in the description, use the imperative, present tense.- The body should include the motivation for the change and contrast this with previous behavior.### Breaking ChangesA commit that has a footer `BREAKING CHANGE:`, or appends a `!` after the type/scope, introduces a breaking API change.Example:```feat(api)!: remove deprecated v1 endpointsBREAKING CHANGE: The v1 endpoints are no longer available. Use v2 instead.```## Checklist for Good Commits- [ ] Have I used the correct type?- [ ] Is the description concise and clear?- [ ] Did I use the imperative mood in the subject line?- [ ] Have I included a body to explain the 'why' if necessary?- [ ] Are breaking changes clearly marked?

Frequently asked questions

Git Conventional Commits