name	commit
description	Review git changes, write a Conventional Commit message, and create a git commit without pushing. Use when the user wants to commit all current changes or a specific scoped subset of files.
argument-hint	Describe what should be committed or the scope to review.
user-invocable	true

Commit

Use this skill when the task is to inspect the current git changes, prepare a Conventional Commit message, and create a commit.

Do not push, amend, rebase, or rewrite history unless the user explicitly asks.
Do not include unrelated changes when the requested commit scope is narrower than the full working tree.
Only create a commit after reviewing the current git status and the relevant diff.
If the requested scope is ambiguous, clarify the intended files before staging or committing.

Review the current working tree with git status --short and inspect the relevant diff for the requested scope.
Decide whether the current changes belong in one coherent commit or should be split into multiple commits.
If only part of the working tree should be committed, stage only the intended files or hunks.
Write a Conventional Commit message that matches the actual change.
Create the commit.
Report the final commit hash and subject back to the user.

Use the format below.
Keep the subject line at 50 characters or fewer.
Use imperative mood.
Capitalize the subject.
Do not end the subject with a period.
Add a body only when it improves clarity.
When a body is needed, leave one blank line before it and wrap lines near 72 characters.
Explain both what changed and why, not just the file list.

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

<body>

Valid type examples: feat, fix, docs, refactor, test, chore, ci, build, perf.

If no conventional scope is helpful, omit the parentheses and use <type>: <subject>.

After committing, provide:

name	commit
description	Review git changes, write a Conventional Commit message, and create a git commit without pushing. Use when the user wants to commit all current changes or a specific scoped subset of files.
argument-hint	Describe what should be committed or the scope to review.
user-invocable	true

Use this skill when the task is to inspect the current git changes, prepare a Conventional Commit message, and create a commit.

Do not push, amend, rebase, or rewrite history unless the user explicitly asks.
Do not include unrelated changes when the requested commit scope is narrower than the full working tree.
Only create a commit after reviewing the current git status and the relevant diff.
If the requested scope is ambiguous, clarify the intended files before staging or committing.

Review the current working tree with git status --short and inspect the relevant diff for the requested scope.
Decide whether the current changes belong in one coherent commit or should be split into multiple commits.
If only part of the working tree should be committed, stage only the intended files or hunks.
Write a Conventional Commit message that matches the actual change.
Create the commit.
Report the final commit hash and subject back to the user.

Use the format below.
Keep the subject line at 50 characters or fewer.
Use imperative mood.
Capitalize the subject.
Do not end the subject with a period.
Add a body only when it improves clarity.
When a body is needed, leave one blank line before it and wrap lines near 72 characters.
Explain both what changed and why, not just the file list.

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

<body>

Valid type examples: feat, fix, docs, refactor, test, chore, ci, build, perf.

If no conventional scope is helpful, omit the parentheses and use <type>: <subject>.

After committing, provide:

commit