69 lines
3.3 KiB
Markdown
69 lines
3.3 KiB
Markdown
---
|
|
name: git-commit
|
|
description: Create a git commit with a clear, value-communicating message. Use when the user says "commit", "commit this", "save my changes", "create a commit", or wants to commit staged or unstaged work. Produces well-structured commit messages that follow repo conventions when they exist, and defaults to conventional commit format otherwise.
|
|
---
|
|
|
|
# Git Commit
|
|
|
|
Create a single, well-crafted git commit from the current working tree changes.
|
|
|
|
## Workflow
|
|
|
|
### Step 1: Gather context
|
|
|
|
Run these commands to understand the current state. Use `command git` to bypass aliases and RTK proxies.
|
|
|
|
```bash
|
|
command git status
|
|
command git diff HEAD
|
|
command git branch --show-current
|
|
command git log --oneline -10
|
|
```
|
|
|
|
If there are no changes (nothing staged, nothing modified), report that and stop.
|
|
|
|
### Step 2: Determine commit message convention
|
|
|
|
Follow this priority order:
|
|
|
|
1. **Repo conventions already in context** -- If project instructions (AGENTS.md, CLAUDE.md, or similar) are already loaded and specify commit message conventions, follow those. Do not re-read these files; they are loaded at session start.
|
|
2. **Recent commit history** -- If no explicit convention is documented, examine the 10 most recent commits from Step 1. If a clear pattern emerges (e.g., conventional commits, ticket prefixes, emoji prefixes), match that pattern.
|
|
3. **Default: conventional commits** -- If neither source provides a pattern, use conventional commit format: `type(scope): description` where type is one of `feat`, `fix`, `docs`, `refactor`, `test`, `chore`, `perf`, `ci`, `style`, `build`.
|
|
|
|
### Step 3: Consider logical commits
|
|
|
|
Before staging everything together, scan the changed files for naturally distinct concerns. If modified files clearly group into separate logical changes (e.g., a refactor in one directory and a new feature in another, or test files for a different change than source files), create separate commits for each group.
|
|
|
|
Keep this lightweight:
|
|
- Group at the **file level only** -- do not use `git add -p` or try to split hunks within a file.
|
|
- If the separation is obvious (different features, unrelated fixes), split. If it's ambiguous, one commit is fine.
|
|
- Two or three logical commits is the sweet spot. Do not over-slice into many tiny commits.
|
|
|
|
### Step 4: Stage and commit
|
|
|
|
Stage the relevant files. Prefer staging specific files by name over `git add -A` or `git add .` to avoid accidentally including sensitive files (.env, credentials) or unrelated changes.
|
|
|
|
Write the commit message:
|
|
- **Subject line**: Concise, imperative mood, focused on *why* not *what*. Follow the convention determined in Step 2.
|
|
- **Body** (when needed): Add a body separated by a blank line for non-trivial changes. Explain motivation, trade-offs, or anything a future reader would need. Omit the body for obvious single-purpose changes.
|
|
|
|
Use a heredoc to preserve formatting:
|
|
|
|
```bash
|
|
command git commit -m "$(cat <<'EOF'
|
|
type(scope): subject line here
|
|
|
|
Optional body explaining why this change was made,
|
|
not just what changed.
|
|
EOF
|
|
)"
|
|
```
|
|
|
|
### Step 5: Confirm
|
|
|
|
Run `command git status` after the commit to verify success. Report the commit hash(es) and subject line(s).
|
|
|
|
## Important: Use `command git`
|
|
|
|
Always invoke git as `command git` in shell commands. This bypasses shell aliases and tools like RTK (Rust Token Killer) that proxy git commands.
|