kf-g-git-commit-atomic-rules

Commit rules

This skill defines the commit granularity rules that must be referenced when starting a coding task. Divide changes into atomic units, and commit in logical units for which the necessary verification has passed.

Basic Policy

Always divide changes into "atomic (smallest) units" and commit frequently.

Commit Granularity Criteria

1. One concern

   • Include only one fix or feature change per commit. Do not combine multiple unrelated changes.

2. Always in a buildable state

   • Even for small units, committing in a state where the app does not start or tests fail is prohibited.

3. Separating refactoring

   • Always make feature additions and bug fixes separate commits from refactoring, typo fixes, and formatting changes.

1. Review-friendly size
   • Aim for small units of a few lines to a few dozen lines, where it is obvious at a glance what was done just by looking at the diff.

Execution Instructions

• Commit as soon as a small logical change becomes reviewable.
• Never bundle multiple issues into a single massive commit. Commit messages like Fix multiple issues are strictly prohibited.
• It is prohibited to wait for the completion of the entire task and then create one large commit all at once.

Check at the Start of Work

1. git status --short --untracked-files=all Check existing changes with .
2. If there are existing staged / unstaged / untracked changes, do not mix them with your own work.
3. If existing changes overlap with the work target, confirm how to handle them first.
4. Divide the work into small committable units.
5. Decide the verification commands needed for each unit.

Commit Procedure During Work

1. Implement only one logical change.
2. Run the tests, type checks, lint, and diff checks necessary for that change.
3. If any verification fails, fix it and return to a green state.
4. Stage only the targets you changed. Do not mix in the user's existing changes.
5. git diff --cached --stat と git diff --cached --name-status Confirm the commit targets with .
6. kf-g-git-commit-japanese-commit-message Create the commit message according to . The body 概要 は What、Why should state why it was implemented/changed this way (the reason for the decision).
7. With only one concern staged, run git commit .

Separation Rules

• Do not put feature changes and refactoring in the same commit.
• Separate formatting, typos, renames, and import organization from feature changes.
• Test additions and implementation changes may be put in the same commit only when it improves reviewability.
• Generated file or index file updates may be put in the same commit if they are part of the same logical change as the corresponding source changes.
• Even if multiple files are changed, one logical change may be one commit.
• Even within a single file, if there are multiple unrelated fixes, separate the commits.

Sample

• When some kind of change is made to the codebase by a CLI tool → 1 commit

  • Commit message example:

    feat_: CLI > sv create コマンド実行
    
    - 概要: `sv create` コマンドを実行し生成物を追加
    - Why: 手動 scaffold よりテンプレート生成の方が初期構成のばらつきを抑えられるため
    

• When a feature change and a typo fix are found at the same time → 2 commits

  • First commit only the feature change
  • After that, commit only the typo fix as a separate commit

• When a generated file and the update to the original code belong to the same logical change → 1 commit

  • If the diff between the change source and the generation destination is a single correspondence, do not split it into separate commits

Relationship with the commit message skill

skill	Role
This skill (atomic-rules)	Commit granularity, verification timing, splitting into logical units
kf-g-git-commit-staged-only-rules	When the user requests a commit, limiting to staged targets (the scope of what to stage)
kf-g-git-commit-japanese-commit-message	Commit message format and Why description (canonical)

Normal commits intentionally use the above 2 skills together (staged-only + japanese-commit-message). Only when the user explicitly specifies /genshijin-commit , prioritize the external skill (for priority order, see kf-g-code-how-what-why-why-not-principles ).

Relationship with the staged-only commit skill

This skill handles the commit granularity when the agent proceeds with coding work. Only when the user explicitly requests a commit, prioritizekf-g-git-commit-staged-only-rules and commit only the changes that were already staged at the time of the request.

Prohibited items

• Fix multiple issues such as a large commit.
• A commit in a state that does not work, cannot compile, or has failing tests.
• Mixing in unrelated changes.
• Mixing refactor / format / typo fix with functional change / bug fix.
• Mixing the user's existing changes into your own commit.
• A commit message that writes only a restatement of the subject / summary / diff as the Why.

Completion report

On completion, briefly report the commits created, what was verified, and whether there are any uncommitted changes.