atomic-commits
This skill contains shell command directives (!`command`) that may execute system commands. Review carefully before installing.
Atomic Commits
Pre-loaded context
- Status: !
git status - Diff: !
git diff HEAD - Log: !
git log --oneline -10
Goal
Group all unstaged/untracked changes into atomic commits — one commit per logical concern — then push.
Workflow
- Review full diff and status
- Identify logical groups among changed files. Common groupings:
- Feature or bug fix (src files implementing one thing)
- Tests for that feature
- Config changes (package.json, tsconfig, next.config, etc.)
- Formatting-only changes (prettier, eslint --fix with no logic change)
- Docs / README updates
- Asset changes (images, fonts, public files)
- For each group:
a. Stage only those files explicitly by name (never
git add .or-A) b. Write a commit message matching repo style from log c. Commit with HEREDOC format d. Rungit statusto confirm staging is clean before next group - After all commits:
git push - Run
git statusto verify clean working tree
Grouping Rules
- One commit = one reason to change
- Formatting-only changes (whitespace, quotes, indentation) go in their own commit, separate from logic changes
- Never mix unrelated concerns in one commit (e.g. bug fix + formatting + config)
- If a file has both logic and formatting changes, keep them together in the logic commit
- Tests and the code they test can be in the same commit
Commit Message Rules
- Match existing commit patterns from
git log - Extreme concision, imperative mood
- Focus on "why" not "what"
Rules
- NEVER use
git add .orgit add -A - NEVER amend unless requested
- NEVER skip hooks
- NEVER commit secrets
- NEVER push if there are unstaged changes left unintentionally — confirm with user first
Error Handling
- If pre-commit hook fails → fix reported issue, re-stage changed files, create a NEW commit (never
--amend) - If
git pushis rejected (non-fast-forward) → rungit pull --rebasethen retry push once - If unsure how to group a file → ask the user before committing
More from helderberto/skills
ship
Commit and push changes using atomic commits. Use when user asks to "ship", "commit and push", or requests committing and pushing changes. Don't use for creating pull requests or reviewing changes before committing.
46explain-code
Explains code with visual diagrams and analogies. Use when explaining how code works, teaching about a codebase, or when the user asks "how does this work?" Don't use for modifying code, fixing bugs, or generating new implementations.
45refactor-plan
Create structured refactoring plans. Use when user wants to plan a refactor, needs a refactoring strategy, or mentions breaking down large changes into small commits. Don't use for implementing code changes directly, small one-line fixes, or renaming a single variable.
45safe-repo
Check for sensitive data in repository. Use when user asks to "check for sensitive data", "/safe-repo", or wants to verify no company/credential data is in the repository. Don't use for general code review, adding .gitignore entries, or scanning non-git directories.
41lint
Run linting and formatting checks. Use when user asks to "run linter", "/lint", "check linting", "fix lint errors", or requests code linting/formatting. Don't use for running tests, type-checking only, or projects without a lint script in package.json.
40tdd
Guides test-driven development with red-green-refactor loop. Use when user wants to build features or fix bugs using TDD, mentions "red-green-refactor", wants test-first development, or requests TDD workflow. Don't use for writing tests after implementation, adding tests to existing untested code, or one-off test fixes.
40