Smart commit
Skill naporin0624/electron-texture-bridge/.claude/skills/smart-commit
This skill should be used when the user asks to "smart commit", "logical commit", "group commits", "分割コミット", "論理コミット", or wants to automatically analyze staged/unstaged changes and create logically grouped commits.From its SKILL.md
npx -y skills add naporin0624/electron-texture-bridge --skill smart-commitAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 12 stars12 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
SKILL.md
3.3 KB, as published. Nobody here has run it
Smart Commit
Analyze all staged and unstaged changes, group them into logical commits, and create each commit with a descriptive Conventional Commits message.
Procedure
Step 1: Gather changes
Run these commands in parallel to collect the full picture:
git status
git diff
git diff --cached
git log --oneline -10
If there are no changes (no untracked files, no modifications, no staged changes), report "Nothing to commit" and stop.
Step 2: Analyze and group (use Sonnet subagent)
Spawn an Agent with model: "sonnet" to analyze the diff output and propose logical commit groups. The subagent should:
- Read every changed file's diff carefully
- Group related changes by logical unit of work (feature, fix, refactor, chore, docs, test, ci, etc.)
- Each group should be independently meaningful — one group = one concern
- Order groups so dependencies come first (e.g., library changes before consumers)
- For each group, produce:
- Files: list of file paths to include
- Message: Conventional Commits format (
type(scope): description) - Why: one-line rationale for the grouping
Grouping principles:
- Separate functional changes from formatting/style changes
- Separate production code from test code when they address different concerns
- Keep config/CI changes in their own group
- If a single file has changes belonging to multiple logical groups, note it but keep the file in the most relevant group (git stages whole files)
Step 3: Present plan to user
Display the proposed commit groups as a numbered list:
Commit plan:
1. fix(core): correct platform handle extraction
Files: packages/core/src/index.ts, packages/core/src/utils.ts
Why: Fixes buffer reading for NT handle on Windows
2. feat(renderer): add FPS throttling option
Files: packages/renderer/src/bridge.ts, packages/renderer/src/types.ts
Why: New user-facing feature for frame rate control
3. chore(ci): update build matrix for macOS 14
Files: .github/workflows/ci.yml
Why: CI infrastructure change, independent of code
Ask the user to confirm, reorder, merge, split, or skip groups.
If $ARGUMENTS contains --dry-run, show the plan and stop without committing.
Step 4: Execute commits
For each approved group, in order:
- Stage only the files in that group:
git add <file1> <file2> ... - Create the commit using a HEREDOC for the message:
git commit -m "$(cat <<'EOF'
type(scope): description
Co-Authored-By: Claude Sonnet <[email protected]>
EOF
)"
- Run
git statusafter the final commit to confirm clean state.
Rules
- NEVER use
git add -Aorgit add .— always add specific files - NEVER amend existing commits
- NEVER push to remote
- NEVER skip pre-commit hooks (no
--no-verify) - If a pre-commit hook fails, fix the issue and create a NEW commit
- Commit messages must follow Conventional Commits:
type(scope): description - Keep commit message first line under 72 characters
- Use Co-Authored-By trailer with "Claude Sonnet" since Sonnet does the analysis