Conventional Commit
Standardize git commit messages to the Conventional Commits spec and execute git commit from a structured agent workflow.
Overview
Conventional Commit is an agent skill most often used in Ship (also Build, Operate) that generates Conventional Commits messages and runs git commit from a fixed XML workflow.
Install
npx skills add https://github.com/github/awesome-copilot --skill conventional-commitWhat is this skill?
- Workflow: git status, diff, stage, then structured message
- XML-style template for type, scope, description, body, footer
- Supports feat, fix, docs, style, refactor, perf, test, build, ci, chore, revert
- Agent runs git commit -m in the integrated terminal after generation
- Aligned with Conventional Commits specification examples in SKILL.md
- 11 commit types in template: feat, fix, docs, style, refactor, perf, test, build, ci, chore, revert
Adoption & trust: 12.6k installs on skills.sh; 34.6k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You have staged changes but no consistent, changelog-ready commit message and want the agent to commit without ad-hoc phrasing.
Who is it for?
Solo builders who want standardized commit history across features, fixes, and chores without memorizing the full spec.
Skip if: Repos that forbid automated commits, teams using squash-only flows without per-commit messages, or changes you have not reviewed in git diff.
When should I use this skill?
User is ready to commit staged changes and wants a Conventional Commits-formatted message plus automatic git commit.
What do I get? / Deliverables
A conventional commit message is composed from your diff and applied via git commit -m in your integrated terminal.
- Conventional Commits-formatted message (type, scope, description, optional body/footer)
- Executed local git commit
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Canonical shelf is Ship review because commits gate what you merge and release, even though you commit throughout delivery. Commit messages are a quality and traceability checkpoint before launch and during ongoing fixes.
Where it fits
Turn a finished user-story slice into a scoped feat commit after staging only the relevant files.
Write a fix(scope) message with body explaining a regression found in pre-merge testing.
Commit a chore or patch release with a clear imperative summary after a production hotfix.
How it compares
Structured commit workflow—not semantic-release configuration or commitlint enforcement alone.
Common Questions / FAQ
Who is conventional-commit for?
Developers using GitHub Copilot or similar agents who want Conventional Commits formatting every time they land a change.
When should I use conventional-commit?
In Build while iterating features, in Ship before opening or updating a PR, and in Operate when committing hotfixes—after you have inspected git status and diff.
Is conventional-commit safe to install?
It executes git commands in your terminal; review the Security Audits panel on this page and ensure only intended files are staged before the automatic commit runs.
SKILL.md
READMESKILL.md - Conventional Commit
### Instructions ```xml <description>This file contains a prompt template for generating conventional commit messages. It provides instructions, examples, and formatting guidelines to help users write standardized, descriptive commit messages in accordance with the Conventional Commits specification.</description> ``` ### Workflow **Follow these steps:** 1. Run `git status` to review changed files. 2. Run `git diff` or `git diff --cached` to inspect changes. 3. Stage your changes with `git add <file>`. 4. Construct your commit message using the following XML structure. 5. After generating your commit message, Copilot will automatically run the following command in your integrated terminal (no confirmation needed): ```bash git commit -m "type(scope): description" ``` 6. Just execute this prompt and Copilot will handle the commit for you in the terminal. ### Commit Message Structure ```xml <commit-message> <type>feat|fix|docs|style|refactor|perf|test|build|ci|chore|revert</type> <scope>()</scope> <description>A short, imperative summary of the change</description> <body>(optional: more detailed explanation)</body> <footer>(optional: e.g. BREAKING CHANGE: details, or issue references)</footer> </commit-message> ``` ### Examples ```xml <examples> <example>feat(parser): add ability to parse arrays</example> <example>fix(ui): correct button alignment</example> <example>docs: update README with usage instructions</example> <example>refactor: improve performance of data processing</example> <example>chore: update dependencies</example> <example>feat!: send email on registration (BREAKING CHANGE: email service required)</example> </examples> ``` ### Validation ```xml <validation> <type>Must be one of the allowed types. See <reference>https://www.conventionalcommits.org/en/v1.0.0/#specification</reference></type> <scope>Optional, but recommended for clarity.</scope> <description>Required. Use the imperative mood (e.g., "add", not "added").</description> <body>Optional. Use for additional context.</body> <footer>Use for breaking changes or issue references.</footer> </validation> ``` ### Final Step ```xml <final-step> <cmd>git commit -m "type(scope): description"</cmd> <note>Replace with your constructed message. Include body and footer if needed.</note> </final-step> ```