conventional-commit

النجوم٧

التفرعات٢

آخر تحديث٨ أبريل ٢٠٢٦ في ١٢:٣٠

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

التثبيت

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

المصدر

asafelobotomy

asafelobotomy/iCloud-Drive-Downloader

فتح مستودع 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.1"; 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

The user has their own commit message format documented in §10 of their project's Copilot instructions
The project uses a different commit convention (check §4 and §10 of the project's Copilot instructions 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

Determine the scope — Identify the primary area affected (e.g., auth, api, ci, docs). Use the directory name or module name. Omit scope if the change spans many areas.
Write the subject line — Format: <type>(<scope>): <imperative summary>
- Use imperative mood ("add", not "added" or "adds")
- Lowercase first letter after the colon
- No period at the end
- Maximum 72 characters
Write the body (if the change is non-trivial):
- Blank line after the subject
- Explain what changed and why (not how — the diff shows how)
- Wrap at 72 characters
- Reference issue numbers if applicable: Fixes #123, Closes #456
Add breaking change footer (if applicable):
- Add ! after the type/scope: feat(api)!: remove v1 endpoints
- Add footer: BREAKING CHANGE: <description of what breaks and migration path>
Present the message — Show the complete commit message for user review:
```
<type>(<scope>): <subject>

<body>

<footer>
```
Wait for approval — Present the message and wait. Do not run git commit until the user approves or modifies the message.
Execute — Once the user approves, run:
```
git commit -m "<subject>" -m "<body>"
```
For multi-line messages with footers, use a heredoc or a temporary file to avoid shell escaping issues:
```
git commit -F - <<'EOF'
<type>(<scope>): <subject>

<body>

<footer>
EOF
```
Confirm the commit was created: git log --oneline -1

Co-author attribution

VS Code 1.110+ supports git.addAICoAuthor (enabled by default), which automatically appends a Co-authored-by: GitHub Copilot trailer to commits made with AI assistance. If this setting is enabled, the trailer is added automatically — you do not need to include it manually in the commit message.

To check or change the setting: search for git.addAICoAuthor 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

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

نفس المستودع

agentic-workflows

asafelobotomy/iCloud-Drive-Downloader

Set up and manage GitHub Actions workflows that use Copilot coding agents for automated PR handling and issue resolution

2026-04-087

commit-preflight

asafelobotomy/iCloud-Drive-Downloader

Inspect active GitHub Actions workflows before commit or push, run matching local checks for staged or unpushed files, ask which missing tools to install via askQuestions, and fix in-scope issues so the Commit agent can proceed.

2026-04-087

create-adr

asafelobotomy/iCloud-Drive-Downloader

Create an Architectural Decision Record (ADR) to document a significant design or technology choice

2026-04-087

extension-review

asafelobotomy/iCloud-Drive-Downloader

Audit VS Code extensions against the current project stack and recommend keep/add/remove actions

2026-04-087

fix-ci-failure

asafelobotomy/iCloud-Drive-Downloader

Diagnose and fix a failing CI pipeline or GitHub Actions workflow

2026-04-087

issue-triage

asafelobotomy/iCloud-Drive-Downloader

Triage a GitHub issue by classifying severity, labelling waste category, proposing next action, and drafting a structured response

2026-04-087

Conventional Commit

Skill metadata: version "1.1"; 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

The user has their own commit message format documented in §10 of their project's Copilot instructions

The project uses a different commit convention (check §4 and §10 of the project's Copilot instructions 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

Determine the scope — Identify the primary area affected (e.g., auth, api, ci, docs). Use the directory name or module name. Omit scope if the change spans many areas.

Write the subject line — Format: <type>(<scope>): <imperative summary>

Use imperative mood ("add", not "added" or "adds")
Lowercase first letter after the colon
No period at the end
Maximum 72 characters

Write the body (if the change is non-trivial):

Blank line after the subject
Explain what changed and why (not how — the diff shows how)
Wrap at 72 characters
Reference issue numbers if applicable: Fixes #123, Closes #456

Add breaking change footer (if applicable):

Add ! after the type/scope: feat(api)!: remove v1 endpoints
Add footer: BREAKING CHANGE: <description of what breaks and migration path>

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

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

<body>

<footer>

Wait for approval — Present the message and wait. Do not run git commit until the user approves or modifies the message.

Execute — Once the user approves, run:

git commit -m "<subject>" -m "<body>"

For multi-line messages with footers, use a heredoc or a temporary file to avoid shell escaping issues:

git commit -F - <<'EOF'
<type>(<scope>): <subject>

<body>

<footer>
EOF

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

Co-author attribution

To check or change the setting: search for git.addAICoAuthor 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