conventional-commit

Stars2

Forks0

UpdatedMay 1, 2026 at 08:27

Write a commit message following the Conventional Commits specification with scope and body

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Source

asafelobotomy

asafelobotomy/copilot-instructions-template

View GitHub Repository View Creator Repositories

Download

Related occupationsSOC

Based on SOC occupation classification

Software DevelopersComputer and Mathematical Occupations·SOC 15-1252

SKILL.md

readonly

name	conventional-commit
description	Write a commit message following the Conventional Commits specification with scope and body
compatibility	>=1.4

Conventional Commit

Skill metadata: version "1.2"; license MIT; tags [git, commit, conventional-commits, changelog, versioning]; compatibility ">=1.4"; recommended tools [codebase, runCommands].

Write a well-structured commit message following the Conventional Commits specification.

When to use

The user asks to "write a commit message" or "commit these changes"
Changes are staged and ready to commit
The user wants consistent, parseable commit history

When NOT to use

Project has its own commit format in §10 of Copilot instructions
Project uses a different convention (check §4 and §10 first)

Steps

Read the staged changes — Run git diff --cached --stat to see which files changed, then git diff --cached for the full diff.

Determine the type — Choose the most appropriate type:

Type	When to use
`feat`	A new feature or capability
`fix`	A bug fix
`docs`	Documentation-only changes
`style`	Formatting, whitespace, semicolons — no logic change
`refactor`	Code change that neither fixes a bug nor adds a feature
`perf`	Performance improvement
`test`	Adding or correcting tests
`build`	Build system or external dependency changes
`ci`	CI configuration changes
`chore`	Maintenance tasks that don't modify src or test files
`revert`	Reverts a previous commit — subject should reference the reverted hash or subject

Determine the scope — Primary area affected (directory or module name). Omit if change spans many areas.
Write the subject line — <type>(<scope>): <imperative summary>. Imperative mood, lowercase after colon, no period, ≤72 chars.
Write the body (non-trivial changes): blank line after subject, explain what and why (not how), wrap at 72 chars, reference issues (Fixes #123).
Breaking change (if applicable): ! after type/scope + BREAKING CHANGE: <description and migration path> footer.
Present the message — Show the complete commit message for user review:
```
<type>(<scope>): <subject>

<body>

<footer>
```

Approval gate — Use askQuestions before committing. If called from the Commit agent, the agent's approval gate (commit workflow step 6) runs instead; skip this step in that context.

header: "Commit: <type>(<scope>): <subject>"
question: "Approve this commit message, or type an edited version below."
allowFreeformInput: true
options:
  - label: "Approve as-is"
    recommended: true
  - label: "Skip this commit"
    description: "Leave these files staged but do not commit them now"
  - label: "Abort"
    description: "Stop here without committing"

Approve as-is: proceed with the displayed message.
Freeform text: treat as the replacement message and proceed.
Skip this commit / Abort: stop; do not run git commit.

Execute — Once approved, prefer mcp_git_git_commit for multi-line messages (handles newlines safely). When using the terminal, write the message to a temp file and use git commit -F <tmpfile>, then remove the file. Do NOT use git commit -m "subject\n\nbody" — shell newline escaping is unreliable across platforms.
```
# Subject only
git commit -m "<type>(<scope>): <subject>"

# Subject + body/footer via temp file
tmp=$(mktemp); printf '%s\n\n%s\n\n%s' "<subject>" "<body>" "<footer>" > "$tmp"
git commit -F "$tmp"; rm -f "$tmp"
```
Confirm the commit was created: git log --oneline -1

Co-author attribution

VS Code 1.110+ git.addAICoAuthor (enabled by default) auto-appends Co-authored-by: GitHub Copilot. Check/change in VS Code Settings.

Verify

Type is one of the standard Conventional Commits types
Subject line is imperative mood, ≤ 72 characters, no trailing period
Body explains what and why (if present)
Breaking changes have both ! marker and BREAKING CHANGE: footer
The message accurately describes all staged changes
git log --oneline -1 confirms the commit was created

More from this repository

same repository

audit-procedures

asafelobotomy/copilot-instructions-template

Health check procedures D1–D14 for the Audit agent — structural validation, attention budget, version checks, workspace integrity, and static audit

2026-05-062

mcp-management

asafelobotomy/copilot-instructions-template

Configure and manage Model Context Protocol servers for external tool access

2026-05-062

accessibility-review

asafelobotomy/copilot-instructions-template

Review a UI for accessibility — WCAG 2.1 AA compliance, semantic HTML, ARIA usage, keyboard navigation, focus management, colour contrast, and screen reader compatibility

2026-05-012

api-design

asafelobotomy/copilot-instructions-template

Design or review a REST or GraphQL API — resource modeling, versioning strategy, error contract, OpenAPI/schema-first workflow, and security baseline

2026-05-012

changelog-entry

asafelobotomy/copilot-instructions-template

Generate a CHANGELOG.md entry from staged changes, a commit range, or a PR diff — following Keep a Changelog format with conventional commit classification

2026-05-012

env-config

asafelobotomy/copilot-instructions-template

Set up and audit environment variable management — create .env.example, add startup validation, separate secrets from config, and document every variable

2026-05-012

Conventional Commit

Skill metadata: version "1.2"; license MIT; tags [git, commit, conventional-commits, changelog, versioning]; compatibility ">=1.4"; recommended tools [codebase, runCommands].

Write a well-structured commit message following the Conventional Commits specification.

When to use

The user asks to "write a commit message" or "commit these changes"

Changes are staged and ready to commit

The user wants consistent, parseable commit history

When NOT to use

Project has its own commit format in §10 of Copilot instructions

Project uses a different convention (check §4 and §10 first)

Steps

Read the staged changes — Run git diff --cached --stat to see which files changed, then git diff --cached for the full diff.

Determine the type — Choose the most appropriate type:

Type	When to use
`feat`	A new feature or capability
`fix`	A bug fix
`docs`	Documentation-only changes
`style`	Formatting, whitespace, semicolons — no logic change
`refactor`	Code change that neither fixes a bug nor adds a feature
`perf`	Performance improvement
`test`	Adding or correcting tests
`build`	Build system or external dependency changes
`ci`	CI configuration changes
`chore`	Maintenance tasks that don't modify src or test files
`revert`	Reverts a previous commit — subject should reference the reverted hash or subject

Determine the scope — Primary area affected (directory or module name). Omit if change spans many areas.

Write the subject line — <type>(<scope>): <imperative summary>. Imperative mood, lowercase after colon, no period, ≤72 chars.

Write the body (non-trivial changes): blank line after subject, explain what and why (not how), wrap at 72 chars, reference issues (Fixes #123).

Breaking change (if applicable): ! after type/scope + BREAKING CHANGE: <description and migration path> footer.

Present the message — Show the complete commit message for user review:

<type>(<scope>): <subject>

<body>

<footer>

Approval gate — Use askQuestions before committing. If called from the Commit agent, the agent's approval gate (commit workflow step 6) runs instead; skip this step in that context.

header: "Commit: <type>(<scope>): <subject>"
question: "Approve this commit message, or type an edited version below."
allowFreeformInput: true
options:
  - label: "Approve as-is"
    recommended: true
  - label: "Skip this commit"
    description: "Leave these files staged but do not commit them now"
  - label: "Abort"
    description: "Stop here without committing"

Approve as-is: proceed with the displayed message.
Freeform text: treat as the replacement message and proceed.
Skip this commit / Abort: stop; do not run git commit.

Execute — Once approved, prefer mcp_git_git_commit for multi-line messages (handles newlines safely). When using the terminal, write the message to a temp file and use git commit -F <tmpfile>, then remove the file. Do NOT use git commit -m "subject\n\nbody" — shell newline escaping is unreliable across platforms.

# Subject only
git commit -m "<type>(<scope>): <subject>"

# Subject + body/footer via temp file
tmp=$(mktemp); printf '%s\n\n%s\n\n%s' "<subject>" "<body>" "<footer>" > "$tmp"
git commit -F "$tmp"; rm -f "$tmp"

Confirm the commit was created: git log --oneline -1

Co-author attribution

VS Code 1.110+ git.addAICoAuthor (enabled by default) auto-appends Co-authored-by: GitHub Copilot. Check/change in VS Code Settings.

Verify

Type is one of the standard Conventional Commits types

Subject line is imperative mood, ≤ 72 characters, no trailing period

Body explains what and why (if present)

Breaking changes have both ! marker and BREAKING CHANGE: footer

The message accurately describes all staged changes

git log --oneline -1 confirms the commit was created