124 lines
4.1 KiB
Markdown
124 lines
4.1 KiB
Markdown
---
|
|
name: commit-change
|
|
version: 1.0.0
|
|
description: |
|
|
Analyze all changes since the last commit (staged, unstaged, untracked files)
|
|
and create well-structured commits grouped by logical unit. Use this skill
|
|
whenever the user says "commit my changes", "smart commit", "auto commit",
|
|
"commit everything", "analyse et commit", or any variation of wanting to
|
|
commit their pending work intelligently. Also trigger when the user has
|
|
been working on multiple things and wants to create clean, atomic commits
|
|
from their messy working directory. Works in any git repository.
|
|
allowed-tools:
|
|
- Bash
|
|
- Read
|
|
- Grep
|
|
- Glob
|
|
- Agent
|
|
- AskUserQuestion
|
|
---
|
|
|
|
# Git Smart Commit
|
|
|
|
Create clean, atomic commits from a messy working directory. The goal is to
|
|
turn a pile of mixed changes into a well-organized git history that tells a
|
|
clear story — each commit focused on one logical change.
|
|
|
|
## Workflow
|
|
|
|
### Phase 1: Gather context
|
|
|
|
Run these commands to understand the full picture:
|
|
|
|
```bash
|
|
git status
|
|
git diff # unstaged changes
|
|
git diff --cached # staged changes
|
|
git diff HEAD --stat # summary of all changes vs last commit
|
|
git log --oneline -5 # recent commit style
|
|
```
|
|
|
|
Also check for untracked files that should be included. Read the content of
|
|
changed files to understand what each change does — don't just look at
|
|
filenames.
|
|
|
|
### Phase 2: Analyze and group changes
|
|
|
|
Read the actual diffs and file contents to understand the intent behind each
|
|
change. Group changes into logical commits based on:
|
|
|
|
- **Purpose**: what problem does this change solve or what feature does it add?
|
|
- **Scope**: files that work together toward the same goal belong together
|
|
- **Type**: separate concerns (a bug fix shouldn't be bundled with a new feature)
|
|
|
|
Common groupings:
|
|
- Feature code + its tests + its docs = one commit
|
|
- Config/dependency changes = separate commit
|
|
- Unrelated bug fixes = each gets its own commit
|
|
- Formatting/style changes = separate from logic changes
|
|
|
|
### Phase 3: Present the plan
|
|
|
|
Before committing anything, present a clear plan to the user:
|
|
|
|
```
|
|
Proposed commits (in order):
|
|
|
|
1. fix(auth): handle expired tokens in refresh flow
|
|
- src/auth/refresh.ts (modified)
|
|
- src/auth/refresh.test.ts (modified)
|
|
|
|
2. feat(api): add pagination to /users endpoint
|
|
- src/routes/users.ts (modified)
|
|
- src/routes/users.test.ts (new)
|
|
|
|
3. chore: update eslint config
|
|
- .eslintrc.json (modified)
|
|
```
|
|
|
|
Ask the user to confirm, modify the grouping, or adjust commit messages
|
|
before proceeding.
|
|
|
|
### Phase 4: Execute commits
|
|
|
|
For each approved commit group, in order:
|
|
|
|
1. Stage only the files for that commit: `git add <specific-files>`
|
|
- For partially changed files that belong to multiple commits, use
|
|
`git add -p` is not available (interactive), so if a single file
|
|
has changes belonging to different logical groups, mention it to
|
|
the user and ask how they want to handle it (commit together, or
|
|
split manually).
|
|
2. Create the commit with the agreed message
|
|
3. Verify with `git status` that the right files were committed
|
|
|
|
### Commit message format
|
|
|
|
Follow Conventional Commits and match the repo's existing style:
|
|
|
|
```
|
|
<type>(<scope>): <short description>
|
|
|
|
<optional body — what and why, not how>
|
|
|
|
Co-Authored-By: Claude <noreply@anthropic.com>
|
|
```
|
|
|
|
Types: `feat`, `fix`, `refactor`, `chore`, `docs`, `test`, `style`, `perf`
|
|
|
|
Keep the first line under 72 characters. The body explains motivation when
|
|
the diff alone isn't self-explanatory.
|
|
|
|
### Edge cases
|
|
|
|
- **No changes**: tell the user there's nothing to commit
|
|
- **Only staged changes**: respect what's already staged — ask if the user
|
|
wants to commit just those, or also include unstaged/untracked changes
|
|
- **Merge conflicts**: don't try to commit — tell the user to resolve first
|
|
- **Large number of changes**: still group logically, but warn the user if
|
|
the working directory looks like it has many unrelated changes mixed together
|
|
- **Single logical change**: don't force multiple commits — one commit is fine
|
|
if all changes serve the same purpose
|
|
- **Sensitive files** (.env, credentials, keys): warn the user and exclude
|
|
them from commits by default
|