Agent skill · software engineering · sundial-org
conventional-commits
Format commit messages using the Conventional Commits specification. Use when creating commits, writing commit messages, or when the user mentions commits, git commits, or commit messages. Ensures commits follow the standard format for automated tooling, changelog generation, and semantic versioning.
Why this skill is useful
Codifies commit message formatting standards that the AI could infer but now doesn't have to guess.
What it needs
About 3k tokens when loaded. Last updated 2026-03-07. 639 stars on the source repository.
What this skill does
Conventional Commits Format all commit messages according to the Conventional Commits specification. This enables automated changelog generation, semantic versioning, and better commit history. Format Structure Commit Types Required Types feat: - A new feature (correlates with MINOR in Semantic Versioning) fix: - A bug fix (correlates with PATCH in Semantic Versioning) Common Additional Types docs: - Documentation only changes style: - Code style changes (formatting, missing semicolons, etc.) refactor: - Code refactoring without bug fixes or new features perf: - Performance improvements test: - Adding or updating tests build: - Build system or external dependencies changes ci: - CI/CD configuration changes chore: - Other changes that don't modify src or test files revert: - Reverts a previous commit Scope An optional scope provides additional contextual information about the section of the codebase: Description Must immediately follow the colon and space after the type/scope Use imperative mood ("add feature" not "added feature" or "adds feature") Don't capitalize the first letter No period at the end Keep it concise (typically 50-72 characters) Body Optional longer description providing additional context Must begin one blank line after the description Can consist of multiple paragraphs Explain the "what" and "why" of the change, not the "how" Breaking Changes Breaking changes can be indicated in two ways: 1. Using ! in the type/scope 2. Using BREAKING CHANGE footer 3. Both methods Examples Simple feature Feature with scope Bug fix with body Breaking change Documentation update Multi-paragraph body with footers Guidelines 1. Always use a type - Every commit must start with a type followed by a colon and space 2. Use imperative mood - Write as if completing the sentence "If applied, this commit will..." 3. Be specific - The description should clearly communicate what changed 4. Keep it focused - One logical change per commit 5. …
How to use it
Reference it in AdaL, Claude Code, Cursor or any coding agent — nothing to install:
@skills sundial-org/conventional-commits