micro-commit

Splits uncommitted changes into logical units and creates conventional commits of roughly 30-50 lines each.

Updated Jun 24, 2026
One-click install
npx skills add https://github.com/Hakkadaikon/hymme --skill micro-commit-hakkadaikon
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: micro-commit
Source: https://github.com/Hakkadaikon/hymme/tree/main/skills/micro-commit
Command: npx skills add https://github.com/Hakkadaikon/hymme --skill micro-commit-hakkadaikon

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Large, unfocused commits make git history unreadable, break git bisect, and turn code review into guesswork. This Skill automates the discipline of splitting staged and unstaged changes into small, semantically coherent commits with conventional commit messages. ## Core Features & Use Cases - Semantic change grouping: Analyzes git status and git diff output, then groups changes by meaning (a function plus its test, a bug fix across files) rather than by file. - Conventional commit messages: Derives type (feat, fix, docs, refactor, test, chore) and scope from the affected module, writing imperative-mood messages under 72 characters. - Safe staging and verification: Stages specific files or hunks (never git add -A), runs verification gates as separate commands before committing, and reports a summary of all created commits. - Use Case: After finishing a feature that touched eight files, ask the assistant to commit the work; it produces a sequence like feat(db): add B+ tree node split operation followed by its matching test commit, each independently compilable. ## Quick Start Ask the assistant to commit the current uncommitted changes as small conventional commits using the micro-commit workflow.

Frequently Asked Questions about micro-commit

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

FAQPage Schema
How do I split large changes into smaller git commits?

Group changes by semantic meaning rather than by file: a new function and its test form one commit, while unrelated edits in the same file are split using git add -p or per-file staging. Aim for roughly 30-50 changed lines per commit, but keep a coherent change together even if it exceeds that.

How do I write conventional commit messages?

Use the format type(scope): description, where type is feat, fix, docs, refactor, test, or chore, and scope comes from the affected module or directory. Keep the first line under 72 characters, use imperative mood, lowercase after the colon, and no trailing period.

Should a function and its tests be committed together or separately?

A new function and its corresponding test belong in one commit because they form a single coherent unit. Splitting them would leave intermediate commits that fail their own test suite, which defeats the purpose of bisectable history.

Why should I avoid git add -A when making micro-commits?

git add -A stages everything indiscriminately, which mixes unrelated changes into one commit and risks including secrets like .env files or credentials. Staging specific file paths or hunks keeps each commit focused and prevents accidental leakage.

Why do tests pass but the commit still happens when tests fail?

Chaining a test gate into the commit command breaks the guard: piping tests through tail makes the pipeline exit status come from tail, and a semicolon ignores failures entirely. Run the test gate first, confirm exit code 0, then commit as a separate command or guard it with an if statement.