conventional-commit

النجوم٢

التفرعات٠

آخر تحديث١ مايو ٢٠٢٦ في ٠٨:٢٧

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

التثبيت

التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.

المصدر

asafelobotomy

asafelobotomy/copilot-instructions-template

فتح مستودع GitHub عرض مستودعات المنشئ

تنزيل

المهن ذات الصلةSOC

استنادا إلى تصنيف SOC المهني

مطوّرو البرمجياتمهن الحاسوب والرياضيات·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

المزيد من هذا المستودع

نفس المستودع

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