From commit-changes
Intelligently reviews git diffs and creates well-structured commits with descriptive messages. Automatically splits changes into multiple logical commits when modifications span unrelated concerns. Use when asked to "commit changes", "commit my work", "split commits", "create commits from diffs", "auto-commit", or "review and commit".
npx claudepluginhub shouenlee/ghcp-dev-plugin --plugin commit-changesThis skill uses the workspace's default tool permissions.
Review working tree changes, group them by logical concern, and create one or more well-crafted commits with descriptive messages.
Organizes git workspace changes into clean, atomic commits following conventional formats. Activates after features, refactors, or explicit commit requests.
Reviews git changes, stages intended work with patch mode, splits into logical commits, and writes Conventional Commits messages with verification.
Groups uncommitted git changes (staged/unstaged/untracked) into atomic commits by logical purpose and generates conventional commit messages with bodies. Use for splitting multiple changes or 'smart commit' requests.
Share bugs, ideas, or general feedback.
Review working tree changes, group them by logical concern, and create one or more well-crafted commits with descriptive messages.
Run git rev-parse --abbrev-ref HEAD to check the current branch.
If the current branch is master or main, you MUST NOT create any commits on it. Stop and follow these steps before doing anything else:
<type>/<short-description> (e.g., feat/add-auth-module, fix/login-redirect).git checkout -b <branch-name> to create and switch to the new branch.<branch>. Created branch <new-branch> to protect the main branch."Only after switching off the protected branch may you proceed to commit.
git status to see all changed, staged, and untracked files.git diff to see unstaged changes and git diff --cached to see staged changes.git log --oneline -10 to understand the project's existing commit message style and conventions.Review all diffs and group changes into logical units based on:
Guidelines for splitting:
Guidelines for keeping together:
Before making any commits, present the plan to the user:
I've analyzed your changes and propose the following commit(s):
Commit 1: <type>(<scope>): <summary>
- path/to/file1.ts
- path/to/file2.ts
Commit 2: <type>(<scope>): <summary>
- path/to/file3.ts
Shall I proceed?
Wait for user confirmation before executing. If the user wants to adjust the grouping or messages, incorporate their feedback.
For each commit in the plan, in dependency order:
git add <file1> <file2> ....
git add -p interactively or explain to the user that the file has mixed concerns and ask how they'd like to handle it.git log --oneline -1.After all commits are created, show a summary:
Created N commit(s):
abc1234 <type>(<scope>): <summary>
def5678 <type>(<scope>): <summary>
Follow the Conventional Commits specification:
<type>(<scope>): <short summary>
<body>
Types:
| Type | Use For |
|---|---|
feat | New feature or capability |
fix | Bug fix |
docs | Documentation only |
style | Formatting, whitespace (no logic change) |
refactor | Code restructuring without behavior change |
perf | Performance improvement |
test | Adding or updating tests |
chore | Build, deps, tooling, config |
ci | CI/CD pipeline changes |
Rules:
| Issue | Solution |
|---|---|
| No changes detected | Ensure you have modified files; check git status |
| Mixed concerns in one file | Ask the user whether to commit the whole file in one commit or manually split |
| Merge conflicts after partial staging | Reset staging with git reset HEAD and re-stage carefully |
| User disagrees with grouping | Adjust the plan based on their feedback before committing |