§ reference · skill

commit

Reads the working tree, groups related changes into logical commits, and writes descriptive messages in the repo's style — never amends, never adds AI attribution.

arguments message

§ 01 · purpose

Purpose

Closes the implementation loop. Analyses staged + unstaged changes, splits them into atomic commits grouped by purpose (feature · fix · refactor · docs), and commits using the repo's style. Order is interchangeable with code-review.

§ 02 · when to use

When to use it

Work is finished and ready to land.
You want help splitting a noisy working tree into clean atomic commits.
Skip when the directory is not a git repo — commit stops and asks you to git init.

§ 03 · inputs

Inputs

Name	Required	Source
`$ARGUMENTS (commit hint)`	no	Free-text hint or message — empty falls back to inference from session history + `git diff`

§ 04 · outputs

Outputs

Artifact	Path	Format
One or more git commits	`current branch`	imperative-mood messages, repo-style

§ 05 · key steps

Key steps

Verify git availability Why: Stops early when the directory is not a git repo — no commit attempt, no surprising side effects.
Read session context + git diff Why: In-session runs leverage conversation history; cold runs rely on diff inspection. Both produce a why-not-just-what view that drives commit message quality.
Group files into atomic commits Why: One logical change per commit. Mixed concerns (feature + bug + unrelated refactor) get split so future bisects land on the actual cause.
Confirm the plan with the developer before staging Why: ask_user_question shows the planned files and messages first. Catches grouping mistakes cheaply; correcting after a commit means a reset.
Stage by-name and commit; never -A or . Why: Specific git add avoids accidental capture of .env, build artifacts, or unrelated WIP. Messages are written as if the user wrote them — no Claude attribution, no co-author lines.

§ 06 · related skills

upstream implement validate

downstream code-review changelog