chore: rename git-smart-commit skill to commit-change

Co-Authored-By: Claude <noreply@anthropic.com>
2026-04-13 15:12:25 +02:00 · 2026-04-13 15:12:25 +02:00 · c99141f0a8
commit c99141f0a8
parent ec3c18e5a1
1 changed files with 123 additions and 0 deletions
--- a/skills/commit-change/SKILL.md
+++ b/skills/commit-change/SKILL.md
@ -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