| name | git-commit |
| description | Create well-formatted git commits with review and clear messages in the bigbud project. Use when the user asks to commit changes, write a commit message, review changes before committing, or asks about commit conventions. |
Git Commit
Use this skill when the user wants to commit changes in the bigbud project. This skill covers reviewing changes, choosing a commit strategy, staging files, and writing descriptive commit messages. It does not handle pushing.
Quick start
- Run
git status and review all uncommitted changes.
- Run
git diff for unstaged changes and git diff --staged for staged changes.
- Ask the user: "Should I commit these as one commit or split them into multiple logical commits?"
- Stage files with
git add according to the agreed strategy.
- Write a commit message using the format below.
- Run
git commit.
- After committing, ask before pushing — never push automatically.
Commit message format
[Past-tense verb]: [Brief description]
[Detailed explanation of what changed and why]
- First line: 50–300 characters, ideally under 72 for readability.
- Use past-tense verbs at the start of the subject (e.g.,
Added, Updated, Refactored, Fixed, Removed, Deleted).
- Reference issue/ticket numbers when applicable (e.g.,
Fixes #123).
Verb examples
- Added: New features, files, or functionality.
- Updated: Modifications to existing files or dependencies.
- Refactored: Code restructuring or cleanup for readability, performance, or maintainability.
- Fixed: Bug fixes or corrected behavior.
- Removed / Deleted: Removed code, files, or features that are no longer needed.
Rules
- Always review changes with
git status and git diff before staging.
- Never stage or commit secrets, credentials, or sensitive data.
- Split commits logically when the user agrees; avoid mixing unrelated changes.
- Never push to a remote automatically. If the user asks to push, ask for explicit confirmation first.
- Never force-push to
main, master, or any default branch without explicit confirmation.
