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.
feat and fix map 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
type and optional scope. 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 a
BREAKING 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/fix for user-facing behavior).
- Description is imperative, ≤ 72 chars, and has no trailing period.
- Breaking changes are marked with
! and/or BREAKING CHANGE:.
- Footers follow
Token: value format.
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
style or chore for formatting-only changes.
- Use
ci or build for pipeline and dependency changes.
- Use
test for changes limited to tests.
1---2name: commit3description: 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.4---56# Conventional Commits78## Overview910The commit skill summarizes the Conventional Commits 1.0.0 specification and11common best practices, supporting compliant commit messages. Reference:12[Conventional Commits 1.0.0](https://www.conventionalcommits.org/en/v1.0.0/).1314## Commit Format1516```text17<type>[optional scope][!]: <description>1819[optional body]2021[optional footer(s)]22```2324**Elements:**2526- **type** (required): Primary intent of the change. `feat` and `fix` map to27 semantic versioning. Additional allowed types include: `docs`, `style`,28 `refactor`, `perf`, `test`, `build`, `ci`, `chore`, `revert`.29- **scope** (optional): Short component or package name in parentheses, e.g.,30 `feat(parser): ...`.31- **!** (optional): Indicates a breaking change and can appear after type or32 scope.33- **description** (required): Short, imperative summary in lower case (no34 trailing period). Aim for ≤ 72 characters.35- **body** (optional): Explain what/why; wrap at ~72 characters.36- **footers** (optional): Git trailer format, e.g., `BREAKING CHANGE: ...`,37 `Refs: #123`, `Closes: #123`.3839## Workflow40411. Review changes and identify the primary intent (feature, fix, docs, etc.).422. Choose the `type` and optional `scope`. If changes span multiple intents,43 prefer separate commits; otherwise pick the highest-impact type.443. Determine whether the change is breaking. If yes, add `!` and/or a45 `BREAKING CHANGE:` footer.464. Write a concise description in imperative mood.475. Add body and footers as needed for context, rationale, or issue links.486. Validate against the checklist below.4950## Checklist5152- Header matches `<type>(<scope>): <description>` format.53- Type is correct for the change (`feat`/`fix` for user-facing behavior).54- Description is imperative, ≤ 72 chars, and has no trailing period.55- Breaking changes are marked with `!` and/or `BREAKING CHANGE:`.56- Footers follow `Token: value` format.5758## Examples5960- `feat(auth): add refresh token rotation`61- `fix(api): handle empty payloads`62- `docs: add migration guide`63- `refactor(ui): extract button variants`64- `perf(db): batch writes to reduce roundtrips`65- `chore(deps): bump eslint to 9.0.0`6667Breaking change:6869```text70feat(api)!: drop deprecated v1 endpoints7172BREAKING CHANGE: v1 endpoints were removed. Use /v2 instead.73```7475Revert:7677```text78revert: feat(auth): add refresh token rotation7980This reverts commit 1234abcd.81```8283## Tips8485- Use scopes for packages or subsystems (e.g., `api`, `ui`, `cli`).86- Avoid mixing unrelated changes in a single commit.87- Use `style` or `chore` for formatting-only changes.88- Use `ci` or `build` for pipeline and dependency changes.89- Use `test` for changes limited to tests.
trancong12102