Smart Logical Commits

VerifiedSafe

Analyzes changes and suggests grouping them into logical commits based on their nature (feature, refactoring, bug fix) and scope. Presents a concise plan table for confirmation and executes commits in batches. Helps avoid messy or oversized commits.

Sby Skills Guide Bot
DevelopmentIntermediate
706/2/2026
Claude Code
#git#commit#changes#logical-grouping

Recommended for

Our review

Analyzes current changes and proposes logical, well-structured commits.

Strengths

  • Prevents large or mixed-subject commits.
  • Presents a clear plan before execution, with room for adjustment.
  • Ensures each commit is independently meaningful.

Limitations

  • Does not handle merge conflicts or rebases.
  • Requires manual confirmation of each planned commit.
When to use it

When you have multiple unrelated changes in your working directory and want clean, topic-based commits.

When not to use it

For a single obvious commit, or if you are using a GUI versioning tool.

Security analysis

Safe
Quality score90/100

The skill only uses standard git commands for status, diffing, staging, and committing. It requires user confirmation before any changes are made. There are no destructive or obfuscated actions, no network calls, and no data exfiltration risks.

No concerns found

Examples

Analyze and split changes
Analyze my current git changes and help me commit them in logical chunks.
Commit groups by type
I have changes for a bug fix and a new feature. Can you group them into separate commits?
Review and execute plan
Show me a commit plan for my current changes and wait for my approval before executing.

description: Analyze changes and commit in logical chunks allowed-tools: Bash(git *)

Smart Commit

Step 1: Analyze All Changes

!git status !git diff !git diff --cached

Step 2: Plan Logical Commits

Group changes by these dimensions:

  • Feature work vs refactoring vs bug fixes
  • Area/scope (which part of the wiki? config, content, infra, skin, extensions?)
  • Content vs infrastructure
  • Deps/config vs behavior changes
  • Docs vs code

If everything belongs together -> single commit. If changes span multiple concerns -> plan multiple commits.

Step 3: Present the Plan (CONCISE)

Show a brief table - one row per commit group:

| # | Message | Files | |---|---------|-------| | 1 | fix(config): correct upload size limit in LocalSettings | 1 file | | 2 | feat(content): add Poi article draft | 2 files |

Do NOT:

  • List every file individually
  • Explain what each file does
  • Provide detailed breakdowns
  • Add commentary about the changes

Just: commit message + file count. User can ask for details if needed.

Wait for confirmation before proceeding.

Step 4: Execute

For each planned commit:

  1. Stage only the relevant files: git add <files>
  2. For mixed files, use patch staging: git add -p <file>
  3. Commit with the planned message
  4. Verify with git status

After all commits, show git log --oneline -n <count> to confirm.

Rules

  • Never commit unrelated changes together
  • If a commit can't be described in one line, it's too broad--split it
  • Each commit should be independently meaningful
  • Think: "Will this make sense when generating the changelog?"
Related skills