Guidance for writing git commit messages that follow the Conventional Commits 1.0.0 specification. Use when preparing commit messages, summarizing code changes for a commit, or validating commit text for compliance.
Install
npx skillscat add trancong12102/pi-skills/commit Install via the SkillsCat registry.
The commit skill provides guidance for writing git commit messages that conform to the Conventional Commits 1.0.0 specification, helping developers ensure consistent and meaningful commit histories. It is used when drafting commit messages, summarizing changes, or validating existing messages for compliance.
Conventional Commits
Overview
The commit skill summarizes the Conventional Commits 1.0.0 specification and
common best practices, supporting compliant commit messages. Reference:
Conventional Commits 1.0.0.
Commit Format
<type>[optional scope][!]: <description>
[optional body]
[optional footer(s)]Elements:
- type (required): Primary intent of the change.
featandfixmap to
semantic versioning. Additional allowed types include:docs,style,refactor,perf,test,build,ci,chore,revert. - scope (optional): Short component or package name in parentheses, e.g.,
feat(parser): .... - ! (optional): Indicates a breaking change and can appear after type or
scope. - description (required): Short, imperative summary in lower case (no
trailing period). Aim for ≤ 72 characters. - body (optional): Explain what/why; wrap at ~72 characters.
- footers (optional): Git trailer format, e.g.,
BREAKING CHANGE: ...,Refs: #123,Closes: #123.
Workflow
- Review changes and identify the primary intent (feature, fix, docs, etc.).
- Choose the
typeand optionalscope. If changes span multiple intents,
prefer separate commits; otherwise pick the highest-impact type. - Determine whether the change is breaking. If yes, add
!and/or aBREAKING CHANGE:footer. - Write a concise description in imperative mood.
- Add body and footers as needed for context, rationale, or issue links.
- Validate against the checklist below.
Checklist
- Header matches
<type>(<scope>): <description>format. - Type is correct for the change (
feat/fixfor user-facing behavior). - Description is imperative, ≤ 72 chars, and has no trailing period.
- Breaking changes are marked with
!and/orBREAKING CHANGE:. - Footers follow
Token: valueformat.
Examples
feat(auth): add refresh token rotationfix(api): handle empty payloadsdocs: add migration guiderefactor(ui): extract button variantsperf(db): batch writes to reduce roundtripschore(deps): bump eslint to 9.0.0
Breaking change:
feat(api)!: drop deprecated v1 endpoints
BREAKING CHANGE: v1 endpoints were removed. Use /v2 instead.Revert:
revert: feat(auth): add refresh token rotation
This reverts commit 1234abcd.Tips
- Use scopes for packages or subsystems (e.g.,
api,ui,cli). - Avoid mixing unrelated changes in a single commit.
- Use
styleorchorefor formatting-only changes. - Use
ciorbuildfor pipeline and dependency changes. - Use
testfor changes limited to tests.