dibenkobit/skills
Overview
This skill enforces an atomic-commits philosophy: always make small, focused commits where one commit = one logical change. It guides when to commit, how to stage files, and how to write clear messages so changes can be reverted and understood independently. The goal is safer history, easier code review, and simpler debugging.
How this skill works
The skill inspects your work units and recommends committing immediately after a completed, verifiable change. It checks that staged files are related, encourages specific git add usage instead of git add ., and promotes clear, intent-revealing commit messages. It also provides patterns for splitting large tasks into meaningful, revertible commits and flags anti-patterns to avoid.
When to use it
- After finishing any unit of work that is complete and verified (feature, bugfix, refactor, test, config).
- When updating dependencies or making configuration changes.
- When adding tests related to a change.
- While breaking a large feature into logical, deliverable pieces.
- Before pushing or opening a pull request to ensure commits are focused.
Best practices
- Commit frequently and immediately after a self-contained change.
- Stage only related files (git add <specific-files>), avoid git add . unless everything is related.
- Write messages that explain WHY, not just WHAT; follow project rules or conventional commits by default.
- Keep commits revertible and single-purpose so they can be cherry-picked or reverted safely.
- Split large work by feature or user-facing unit, not by technical layer.
Example use cases
- Implementing a password reset: commit registration, profile editing, and password reset as separate feature commits.
- Fixing a bug: stage and commit only files that fix and verify the bug with a descriptive fix(...) message.
- Refactoring: extract helper and commit refactor(...) plus tests in separate commits.
- Upgrading dependencies: commit dependency changes with chore(deps): upgrade ... message and include related lockfile only.
- Adding tests: commit tests for the specific feature or bug alongside or immediately after the related change.
FAQ
Don’t commit unfinished or non-compiling work. Use a WIP branch or stash for in-progress changes and commit only when the unit is complete and verifiable.
How do I split changes already bundled in one commit?
Use git add -p or git restore --staged to stage related hunks, create multiple commits, or use interactive rebase to split and rewrite history before pushing.
