smithery.ai

git-commit-plan

Plan commits from the current working tree. Use when asked how to split changes into commits, what to stage together, how to handle untracked files, or to propose commit messages and an execution plan (stage/commit) based on `git status`/diffs.

First seen Apr 22, 2026

Installation

$ npx skills add https://smithery.ai

Similar popular skills

Related neighbors and high-traction skills in the same topics — useful to compare before installing.

Also in this package

Other skills from smithery.ai · top by installs.

npx skills add https://smithery.ai

Browse all from smithery.ai

More details

Agent compatibility

Declared targets from SKILL.md / docs. Unmarked agents are not listed — the skill may still install via the CLI.

Claude Code Not declared
Cursor Not declared
Codex Not declared
GitHub Copilot Not declared
Windsurf Not declared
Gemini CLI Not declared
Cline Not declared
OpenCode Not declared

Package contents

Files included with this skill beyond the listing page.

  • skill md SKILL.md 2,234 B
  • docs SUMMARY.md 267 B

History

  1. First seen on skills.sh
  2. First recorded snapshot · 1 installs

SKILL.md

Git Commit Plan

Goal

Turn the current repo state into a small set of clean, reviewable commits:

  • Group changes by intent (feature/fix/refactor/docs/chore) and scope.
  • Keep commits as independent as possible.
  • Propose Conventional Commit messages and the exact files per commit.
  • Ask for explicit confirmation before staging/committing (and pushing).

Workflow

1) Gather signals (read-only)

Run:

  • git status --porcelain=v2
  • git diff --stat
  • git diff
  • git diff --staged (if anything is already staged)

If there are untracked files, list them explicitly.

2) Decide commit boundaries

Use these heuristics:

  • One intent per commit: do not mix unrelated changes.
  • Keep mechanical changes separate: formatting-only or purely generated output should be isolated unless the repo convention says otherwise.
  • Keep dependency changes coherent: e.g., package.json with its lockfile; do not mix with functional changes unless unavoidable.
  • Prefer minimal blast radius: if a commit requires changes across many areas, consider splitting into preparatory refactor + behavior change (ask first).
  • Untracked files: decide whether each should be committed, gitignored, or deleted (ask if unclear).

3) Propose a concrete plan

Output a numbered list of commits. For each commit, include:

  • Commit message (Conventional Commits)
  • Files to include
  • Notes (why grouped this way, anything risky)

Also propose the exact commands to execute the plan, favoring:

  • git add -p when changes are mixed
  • git add <paths...> when the grouping is clean

4) Ask to execute

End with a clear question before making changes:

“Do you want me to execute this plan?”

  • Option A: stage only
  • Option B: stage + commit
  • Option C: stage + commit + push (only if you explicitly request push)

If anything about grouping, naming, or inclusion is ambiguous, ask short questions with options.