atomic-commits

Plans atomic git commit sequences from dirty working trees with submodule and gitignore handling.

1|Updated Mar 15, 2025
One-click install
npx skills add https://github.com/adikpb/dotfiles --skill atomic-commits-adikpb
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: atomic-commits
Source: https://github.com/adikpb/dotfiles/tree/main/.hermes/skills/software-development/atomic-commits
Command: npx skills add https://github.com/adikpb/dotfiles --skill atomic-commits-adikpb

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? Dirty working trees often mix unrelated changes, nested clones, and generated files, making it hard to produce clean, revertible commits. This Skill inspects the repository read-only and proposes a structured commit plan before anything is staged. ## Core Features & Use Cases - Read-only recon: Runs git status, submodule checks, gitignore audits, and diff inspection before proposing any commit. - Submodule vs ignore vs vendor decisions: Distinguishes existing gitlinks (mode 160000), local-only clones, and generated caches, then recommends the right action for each. - Atomic commit sequencing: Orders ignore rules first, then one commit per revertible unit matching the repo's conventional-commit style. - Use Case: A developer with a Stow-managed dotfiles repo full of untracked configs, a nested kitty source checkout, and modified packages asks for a commit plan and receives a table of scoped commits plus gitignore updates, without touching the working tree. ## Quick Start Ask the assistant to analyze the current dirty git working tree and propose an atomic commit plan with messages and file groupings.

Frequently Asked Questions about atomic-commits

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I split a dirty git working tree into atomic commits?▼

Run read-only recon first: git status, submodule status, gitignore audits, and diffs grouped by package. Then commit ignore rules first, followed by one commit per revertible unit matching the repo's conventional-commit style.

How to decide between git submodule, gitignore, or vendoring a nested repo?▼

Check if the path is already a gitlink (mode 160000 in git ls-files -s); if so, keep it and bump the recorded SHA. Ignore local-only clones used for typing or browsing, and never vendor large trees like node_modules.

Does this work with Stow-managed dotfiles repositories?▼

Yes, it handles repos where the root is the Stow package mapping onto $HOME. It warns that new root files land in $HOME on the next stow and tracks only .hermes/config.yaml via targeted gitignore rules.

When should files be left untracked instead of committed?▼

Leave empty stub files unreferenced by live config, IDE extras tied to ignored checkouts like pyrightconfig.json, and dependency manifests with no lockfile or runtime role. These add noise without standalone value.

Why run git status --ignored --porcelain before proposing commits?▼

It reveals files already covered by existing gitignore rules so you do not re-propose them. Reading every tracked gitignore file first prevents redundant or conflicting ignore suggestions.