Create Commits

Workflow

1. Resolve the current branch and its base branch from available context, then inspect the worktree and the complete change set against the base, marking which commits are already published or shared.
2. Author commit boundaries for the reader, not from chronology: define each commit by one reviewable purpose and its dependencies, keep an implementation with its tests or fixtures, separate authorized but independent in-scope changes, exclude unauthorized or out-of-scope changes, and order commits in the order a reviewer should read them. When the current plan records a commit-level change map, use it as the split specification. Use one commit only when neither the plan nor the change itself contains a reviewable split line, and record that reason; cost of splitting alone does not qualify.
3. Rewrite only history the request authorizes: uncommitted worktree changes are always in scope, existing unpublished commits only when their rewrite is explicitly authorized, and published or shared commits never. Never force-push, and never use force-push to rewrite published or shared history. When the boundaries cannot be met inside that scope, hold the rewrite, state each blocker, and distinguish missing authorization for an unpublished rewrite from published history that cannot be rewritten, giving the safe non-rewrite path for each.
4. Make the authorized local history match the boundaries. When the worktree is uncommitted or the unpublished history is blended (fixes interleaved across boundaries), synthesize a fresh narrative instead of recovering chronology: soft-reset the unpublished branch to its merge base and rebuild commits by selective staging, splitting files that span boundaries by staging hunk patches cut from git diff output with git apply to the index — never with interactive tools (git add -p / -i are unavailable). Write each commit message to tell the reviewer what to look at in that commit.
5. Verify before reporting: require the final commit's tree to be bit-identical to the last verified tree (empty git diff <verified-ref>); require each intermediate commit to pass checks only when the repository lands pull requests preserving individual commits (rebase / merge commit) — under squash merge, endpoint identity suffices. Verify the resulting commit order and each commit's diff against the boundaries.
6. Report the verified commit boundaries in reading order with each commit's purpose and files, the single-commit reason when one commit was used, the tree-identity result, and any held rewrite with its blockers and safe path. Leave push and pull request creation as follow-up work for the requester unless the request authorizes them.