Use this skill after the user explicitly invokes it to turn a mixed or large change into a coherent commit series, or to reorganize local commits. It is a planning and controlled-execution workflow, not a generic Git tutorial or a single commit-message writer.

Choose one mode before reading the diff:

Planning always comes first. Execution authorization must identify this plan and either exact commit IDs or the complete resolved series; it never includes undecided items. A request to organize, review, or propose commits authorizes analysis only. Pushes, force-pushes, and changes outside the named scope need separate confirmation. If a baseline drift causes a revised plan, obtain authorization again for the revised plan and exact IDs. If no matching handoff exists, stay in plan mode even when the user asks to execute immediately.

In plan mode, keep Git refs, the index, and tracked files unchanged. If the worktree or task scope changes after a plan, establish a new baseline before executing it.

Keep these leading words visible while working:

The series is correct only when every observed hunk has exactly one disposition, every commit has one primary intent, dependencies are acyclic, protected changes stay protected, and each public commit has an explicit validation state. The smallest useful unit is a complete logical change, not a file, directory, or line-count quota.

Done when: the rule sources, base SHA, baseline state, and a disjoint disposition for every visible hunk are recorded; blocking ambiguity is surfaced.

Read boundary-rules.md when assigning ownership. Inspect the complete diff, enabling rename detection when useful. Include untracked files, renames, binary files, generated artifacts, and lockfiles. Read untracked content explicitly (the default tracked-file diff omits it), and represent an untracked file as a whole-file hunk when finer ownership is impossible.

For each hunk, record its stable ID, path, old/new line anchor, short context or patch fingerprint, concise summary, intent, behavior impact, direct tests, dependencies, validation, rollback effect, and classifications such as formatting, generated, lockfile, debug, or WIP. Merge coupled hunks when separating them would create an unreviewable or unbuildable state.

Done when: every observed hunk appears exactly once across candidate groups, protected, excluded, undecided, or residual buckets.

Cluster by intent, coupling, review boundary, and rollback boundary. Keep behavior and its directly coupled tests together. Give independent mechanical refactors, formatting, documentation, dependency maintenance, and unrelated cleanup their own intent when they can stand alone. Keep a cross-file change together when it expresses one logical change. Follow real migration dependencies (for example, expand/compatibility layer → callers → contract or cleanup), and follow the repository's rules for lockfiles and generated output.

Do not let a message type such as feat, fix, or refactor decide the boundary. Prefer a green series: each public point should build and pass the smallest relevant checks. A necessarily red intermediate state belongs in local fixup work, or is called out as an explicit repository-approved exception.

Create one directed edge for each required predecessor, detect cycles, and topologically sort the result into C1…Cn. Read the boundary reference again for migration, generated-file, lockfile, or inseparable-hunk cases.

Done when: the candidate groups cover the ledger without overlap, each group has one sentence-level intent, the DAG has no cycle, and the sorted series is minimal but complete.

Discover validation commands from the repository rather than copying a generic command list. In plan mode, run only known read-only checks. Materialize a candidate with a disposable filesystem copy before a build or test that could create tracked or untracked artifacts; keep the source repository unchanged. A may change repository metadata, so use it only with explicit permission. If the executable or test entry point is unavailable, mark the gate not-run and name the missing prerequisite; reserve failed for a command that actually ran and failed. Select a focused check for each candidate, add broader checks where policy requires them, and include git diff --check when applicable. Mark every check pending, passed, failed, or not-run; an unrun check is never a pass.

Check that each candidate can be reviewed and reverted on its own, that debug/WIP material is accounted for, and that the proposed message follows the repository's actual convention. Use a Conventional Commits shape only as a fallback when no local convention exists.

Done when: every candidate has a command, purpose, expected result, current validation state, and a recorded explanation for anything not run.

Read plan-schema.md for the authoritative fields and output-template.md for the presentation contract. Output the schema version, base and baseline, protected, excluded, undecided, and residual changes, the dependency order, and each commit's operation, subject/body, intent, exact hunk ownership, dependencies, validation gates, risk, rollback, and status. List open decisions instead of silently choosing across an unresolved boundary.

In plan mode, stop after this handoff. The handoff is complete when another agent can stage exactly one planned commit at a time without inferring where a hunk belongs.

After explicit authorization, read execution-safety.md. Recheck the baseline, confirm the authorization covers the exact resolved IDs, then use path- or hunk-scoped staging, inspect the cached diff, run that commit's green gate, and create exactly one commit before moving to the next. If the actual diff no longer matches the plan, pause and re-plan. For history-edit mode, also read history-surgery.md.

Done when: every authorized plan item has one recorded commit result and no protected change was staged or rewritten.

Compare the actual series with the handoff using commit log inspection, base..HEAD diff review, and range-diff when history was rewritten. Recheck status, protected changes, residual paths, and every validation result. Report hashes and deviations; distinguish passed, failed, not-run, and blocked.

Done when: the final report accounts for every planned item, every residual change, and every mutation made.