Commit atomic

Skill jellydn/my-ai-tools/skills/commit-atomic

Group staged changes into atomic commits with commitizen conventionFrom its SKILL.md

Install

npx -y skills add jellydn/my-ai-tools --skill commit-atomic

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

What its file declares

Copied from the file, not written here

The file declares its own license as MIT. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.

SKILL.md

4.1 KB, as published. Nobody here has run it

Atomic Commit with Logical Grouping

Create atomic commits by logically grouping changes following the commitizen/conventional commits convention. Each commit should represent one logical change with a clear, informative message explaining the what and why.

Usage

/commit-atomic

Process

1. Inspect the current changes

git status
git diff --staged
git diff

Review all modified, added, and deleted files to understand the full scope of changes.

2. Group changes logically

Analyze the changes and group them into logical, independent units. Each group should:

Address a single concern or feature
Be independently understandable
Not break the build or tests on its own
Follow the dependency order (low-level to high-level)

Grouping strategies:

By feature or concern (e.g., authentication, UI, database)
By type (e.g., refactoring, bug fix, new feature)
By layer (e.g., model, service, controller)

3. Stage each group intentionally

Stage files explicitly with git add <path>. Avoid git add -A or git add --all:

# Stage specific files
git add <file1> <file2>

# Stage specific hunks interactively
git add -p <file>

# Verify what is staged before committing
git diff --staged

4. Commit each group with a commitizen message

Follow the commitizen conventional commits format:

<type>(<scope>): <subject>

[optional body]

[optional footer]

Types:

Type	When to use
`feat`	A new feature
`fix`	A bug fix
`docs`	Documentation only changes
`style`	Formatting, missing semicolons (no code logic change)
`refactor`	Code change that is neither a fix nor a feature
`perf`	A code change that improves performance
`test`	Adding or fixing tests
`chore`	Build process or auxiliary tool changes
`ci`	CI configuration changes
`build`	Changes that affect the build system or dependencies
`revert`	Reverts a previous commit

Writing good commit messages:

Subject line: Imperative mood, max 72 characters, no period at end
Body (optional): Explain the why, not just the what; wrap at 72 characters
Footer (optional): Reference issues (Closes #123), breaking changes (BREAKING CHANGE: ...)

Examples:

feat(auth): add JWT refresh token support

Refresh tokens allow users to stay logged in without re-authenticating.
This reduces friction for long-running sessions.

Closes #42

fix(api): handle null response from external service

The external API occasionally returns null for optional fields.
Previously this caused an unhandled TypeError at runtime.

refactor(utils): extract date formatting into shared helper

Consolidates duplicate date formatting logic spread across three
modules into a single reusable function.

5. Verify after each commit

git log --oneline -5
git status

Ensure the working tree is clean after all logical groups are committed.

Rules

❌ Prefer git add <path> over git add -A or git add --all
❌ Keep each commit focused on one logical change
✅ Stage files explicitly with git add <file> or git add -p
✅ Verify staged changes with git diff --staged before committing
✅ Write messages in imperative mood ("add feature" not "added feature")
✅ Explain the why in the commit body when the change is non-obvious
✅ Keep each commit independently buildable and testable