|
|
@@ -0,0 +1,123 @@
|
|
|
+---
|
|
|
+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
|
