Skill

cc-git-commit

Atomic commit workflow — groups changed files into logical commits and produces Conventional Commit messages prefixed with branch name and author initials. Use when performing any git staging, committing, or when the user asks to save, commit, or push work.

Popularity

Parent stars

Invocation

How this skill is triggered — by the user, by Claude, or both

Slash command

/ccube-software-craft:cc-git-commit

User invocable

Model invocable

Inline context

Default effort

Context Preview

The summary Claude sees in its skill listing — used to decide when to auto-load this skill

Group all changed files into atomic commits — one logical concern per

SKILL.md

213 lines · ~1.7k tokens

Stats

LanguageShell

Parent stars3

MaintenanceExcellent

Last CommitMay 7, 2026

Actions

View Source View Plugin View on GitHub View README

Stats

Actions

Atomic Commit Workflow

Group all changed files into atomic commits — one logical concern per commit — and produce a Conventional Commit message for each group, prefixed with [BRANCH_NAME][AUTHOR_INITIALS].

Step 1 — Gather Context

Run one terminal command to get the branch name and author name:

git branch --show-current && git config user.name

Then use getChangedFiles to retrieve all diffs:

Call it with sourceControlState: ["staged"] to check for staged changes.
If staged results are empty, call it with sourceControlState: ["unstaged"] to get all unstaged changes.
If both are non-empty, call it with sourceControlState: ["staged", "unstaged"] to get the full picture.

Do NOT run any further terminal commands until Step 3.

Step 2 — Group Changes into Atomic Commits

An atomic commit contains exactly one logical concern. A single file may appear in more than one group if it contains unrelated changes.

Grouping Rules

Identify each distinct logical concern across all changed files (e.g. a bug fix, a new feature, a dependency bump, a docs update).
Assign every changed file (or hunk, if a file contains mixed concerns) to exactly one group.
Name each group with a draft Conventional Commit subject so its purpose is clear before any staging begins.

Group Priority Order (commit in this sequence)

fix — Bug fixes first, so they are reviewable in isolation.
feat — New features.
refactor / perf — Code improvements with no behaviour change.
test — Test additions or updates.
docs / style / chore / ci / build — Supporting changes last.

Present the Plan and Wait for Approval

Before staging anything, display the proposed grouping:

Proposed atomic commits (N total):

  1. fix(auth): correct null check in token validator
     Files: src/auth/token.ts

  2. feat(ui): add loading spinner to submit button
     Files: src/components/Button.tsx, src/components/Button.css

  3. chore: bump eslint to v9
     Files: package.json, package-lock.json

Proceed with this grouping? (yes / edit)

You MUST wait for user confirmation before staging anything. If the user edits the grouping, update the plan and present it again before proceeding.

When invoked by a subagent on behalf of a non-technical user (e.g. from the Product Manager agent): surface the proposed grouping in plain language before proceeding — replace git jargon with plain descriptions of what each commit saves. For example: "I'll save your changes in 2 batches: (1) the new Home page, (2) the project setup files."

Step 3 — Compose the Commit Message

Construct the message using this format:

[<BRANCH_NAME>][AUTHOR_INITIALS] <type>(<scope>): <subject>

<body — optional>

No footer. Subject line only in most cases; include a body only when the subject alone cannot convey the reason for the change (e.g. a non-obvious trade-off, a workaround for an external bug, or an intentional constraint).

Prefix Rules

BRANCH_NAME — the current branch name, uppercased, with / replaced by - and special characters stripped. Example: feature/user-auth → FEATURE-USER-AUTH.
AUTHOR_INITIALS — derived from git config user.name by taking the first letter of each word, uppercased. Example: John Wei Jian → JWJ. If user.name is unset or empty, fall back to ? and warn the user.

Conventional Commit Types

Type	When to use
`feat`	A new feature or capability
`fix`	A bug fix
`refactor`	Code change that neither fixes a bug nor adds a feature
`chore`	Build process, dependency updates, tooling
`docs`	Documentation only
`test`	Adding or updating tests
`style`	Formatting changes (no logic change)
`perf`	Performance improvements
`ci`	CI/CD configuration changes
`revert`	Reverts a previous commit
`build`	Build system or external dependency changes

Subject Line Rules

Imperative mood: "add X", "fix Y", "update Z" (not "added" or "fixes")
72 characters or fewer (including the prefix)
No trailing period
Lowercase after the colon

Body Rules (opt-in)

Include a body only when the subject alone is insufficient to convey the reason for the change. When included:

Wrap at 72 characters
Explain what and why, not how
Separate from the subject with a blank line

Step 4 — Stage and Commit Each Group

Process each group from the approved plan in order. For each group:

4a — Stage the group's files

Stage only the files belonging to this group. You MUST place each file on its own line using \ continuation for readability:

git add \
  <file1> \
  <file2>

For mixed-concern files where only specific hunks belong to this group, use git add -p to stage interactively — but note this requires a separate approval. Prefer splitting files by concern when possible to avoid patch-mode staging.

4b — Commit with the composed message

Run staging and committing as a single compound command per group. You MUST place each file on its own line and each && command on its own line:

git add \
  <file1> \
  <file2> \
&& git commit \
  -m "<subject line>" \
  -m "<body>" \
&& git log --oneline -1

Use one -m per paragraph. Omit the second -m when there is no body.
The && git log --oneline -1 confirms the commit without an extra approval.
Repeat for each remaining group.

4c — Confirm progress after each commit

After each commit, display:

Commit N/total done: <subject line>
Remaining: <list of pending group subjects>

Success Criteria

All changed files are accounted for across one or more atomic commits
Each commit contains exactly one logical concern
Every commit message starts with [<BRANCH_NAME>][AUTHOR_INITIALS]
Type and scope are present and accurate for each commit
Subject is imperative, lowercase, 72 characters or fewer
Body included only when the subject alone is insufficient; no footer
Every git commit exits with code 0
git log --oneline -<N> shows N clean, well-scoped commits

cc-git-commit

Popularity

Invocation

Context Preview

SKILL.md

cc-git-commit

Popularity

Invocation

Context Preview

SKILL.md

Atomic Commit Workflow

Step 1 — Gather Context

Step 2 — Group Changes into Atomic Commits

Grouping Rules

Group Priority Order (commit in this sequence)

Present the Plan and Wait for Approval

Step 3 — Compose the Commit Message

Prefix Rules

Conventional Commit Types

Subject Line Rules

Body Rules (opt-in)

Step 4 — Stage and Commit Each Group

4a — Stage the group's files

4b — Commit with the composed message

4c — Confirm progress after each commit

Success Criteria

Similar Skills

Atomic Commit Workflow

Step 1 — Gather Context

Step 2 — Group Changes into Atomic Commits

Grouping Rules

Group Priority Order (commit in this sequence)

Present the Plan and Wait for Approval

Step 3 — Compose the Commit Message

Prefix Rules

Conventional Commit Types

Subject Line Rules

Body Rules (opt-in)

Step 4 — Stage and Commit Each Group

4a — Stage the group's files

4b — Commit with the composed message

4c — Confirm progress after each commit

Success Criteria

Similar Skills