name	commit
description	Stage and commit changes with a conventional commit message
disable-model-invocation	true
argument-hint	[message] (optional — auto-generates if omitted)

Create a git commit for the current changes.

Run git status to see all changes (staged and unstaged)
Run git diff and git diff --staged to understand the changes
Run git log --oneline -5 to see recent commit style
If there are unstaged changes, ask which files to stage (prefer specific git add <file> over git add .)
If $ARGUMENTS is provided, use it as the commit message. Otherwise, draft a message following the repo's conventional commit style: type(scope): description
Create the commit
Show the result with git log --oneline -1

First line is the summary — it appears in logs, email subjects, and search results. Make it count.
Body explains what changed and why. Never just "fix bug" or "update code." Name the bug, the root cause, and the reasoning behind the fix.
If a commit touches multiple concerns (unavoidably), enumerate them in the description.

Before committing, assess whether the staged changes cover more than one concern. If they do, split them into separate commits — each one self-contained, buildable, and testable.
One concern per commit. Do not mix bug fixes with refactors, feature work with style cleanups, or behavioral changes with optimizations.
Aim for ~200 lines of diff per commit. If the total diff is larger, split into a reviewable sequence of logical commits.
Each commit should have a single, clear reason to exist. If you struggle to write a concise summary line, the commit likely does too much.
When splitting, stage files (or hunks) selectively with git add <file> — never batch everything into one commit for convenience.

name	commit
description	Stage and commit changes with a conventional commit message
disable-model-invocation	true
argument-hint	[message] (optional — auto-generates if omitted)

Create a git commit for the current changes.

Run git status to see all changes (staged and unstaged)
Run git diff and git diff --staged to understand the changes
Run git log --oneline -5 to see recent commit style
If there are unstaged changes, ask which files to stage (prefer specific git add <file> over git add .)
If $ARGUMENTS is provided, use it as the commit message. Otherwise, draft a message following the repo's conventional commit style: type(scope): description
Create the commit
Show the result with git log --oneline -1

First line is the summary — it appears in logs, email subjects, and search results. Make it count.
Body explains what changed and why. Never just "fix bug" or "update code." Name the bug, the root cause, and the reasoning behind the fix.
If a commit touches multiple concerns (unavoidably), enumerate them in the description.

Before committing, assess whether the staged changes cover more than one concern. If they do, split them into separate commits — each one self-contained, buildable, and testable.
One concern per commit. Do not mix bug fixes with refactors, feature work with style cleanups, or behavioral changes with optimizations.
Aim for ~200 lines of diff per commit. If the total diff is larger, split into a reviewable sequence of logical commits.
Each commit should have a single, clear reason to exist. If you struggle to write a concise summary line, the commit likely does too much.
When splitting, stage files (or hunks) selectively with git add <file> — never batch everything into one commit for convenience.

commit

Mehr aus diesem Repository