commit-flow

Plans and enforces granular git commits using Conventional Commits message format.

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

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? It prevents messy, oversized commits by ensuring logically independent changes are committed separately at the right granularity, and that every implementation plan includes an explicit commit plan. ## Core Features & Use Cases - Commit Planning: Requires a commit plan section in every implementation plan (writing-plans Task Commit steps or plan-mode documents) before coding begins. - Granularity Judgment: Provides criteria for splitting versus combining commits based on logical independence, revertability, and discussion boundaries. - Conventional Commits Formatting: Enforces the Conventional Commits 1.0.0 message format with a detailed reference covering types, scopes, breaking changes, and anti-patterns. - Use Case: When finishing a refactoring task with three independent fixes, use this Skill to split them into separate commits like fix(parser): NPE を修正 and refactor(domain): 命名整理 instead of one vague bulk commit. ## Quick Start Ask the AI to create a commit plan for your current changes and split them into logically independent Conventional Commits.

Frequently Asked Questions about commit-flow

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

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

Split commits by logical independence: separate different concerns, changes you might revert independently, or fixes for different issues. Keep together changes that break when partially reverted or belong to one discussion thread.

What is the Conventional Commits format for git messages?

Conventional Commits uses the format type(scope): description, with types like feat, fix, refactor, test, docs, and chore. Breaking changes add an exclamation mark or a BREAKING CHANGE footer, and descriptions stay under 50 characters without trailing periods.

Should I run tests and git commit in the same shell command?

No, chaining verification and commit with pipes or semicolons can let commits proceed even when tests fail. Run the verification command separately, confirm exit code 0, then commit in a distinct command.

When should commits be combined instead of split?

Combine commits when they represent the same logical change split only by line count, when one part breaks without the other, or when they belong to a single discussion thread. Never merge commits just to reduce commit count.

Does this commit workflow apply to rebase and squash operations?

Yes, when reorganizing history with rebase, squash, or cherry-pick, the resulting commit messages must still follow Conventional Commits format. Merge commits and auto-generated revert commits are exempt from the rules.