git-commit

Git Commit

Goal

Create one local Conventional Commit from whole paths the user selects and confirms, or generate a message for the currently staged changes without touching the index.

Inputs

• mode (optional): commit (default) runs the select, stage, confirm, and commit protocol. message-only generates a message for the staged changes and never stages, unstages, or commits.

Message Rules

Generate every message by following references/commit-message.md. It owns types, scopes, description and body limits, and the footer line. Once generated, the message is authoritative for the commit.

Message-Only Mode

1. Read the staged changes with git --no-pager diff --staged. Use the host's staged-changes tool instead when the user asks to avoid the terminal or no terminal is available.
2. When nothing is staged, output No changes to commit. and stop.
3. Generate the message from the complete staged diff.
4. Output the message in a fenced code block and tell the user to copy it as-is or edit it before committing.

Commit Protocol

1. Inventory candidate paths. Before changing the index, run git status --porcelain=v1 -z --untracked-files=all and git rev-parse --verify HEAD in the target repository.
   • Record tracked, untracked, deleted, renamed, copied, and initially staged paths. Treat only an R or C status record that supplies both old and new paths as one logical selection. Present a separate deletion and untracked addition as independent candidates without inferring a rename.
   • If HEAD cannot be verified, stop, because this workflow cannot restore a rejected staging change safely.
   • If any path has both staged and unstaged changes, stop and ask the user to resolve its hunk-level intent outside this workflow. Do not restage a partially staged path.
   • If there are no candidate changes, output No changes to commit. and stop.
2. Confirm whole-path intent. Present the candidate paths and their states without file contents, then ask the user to select the whole paths intended for this commit.
   • Every initially staged path must be selected. If the user excludes one, stop before changing the index; never unstage prior user work.
   • A status-reported rename or copy is selected only as its complete old-and-new path pair.
   • If the selection is empty, ambiguous, unsafe to represent as shell arguments, or absent, stop without staging or committing.
3. Stage only the selection with git --literal-pathspecs add -- <safely quoted selected paths>. Never use an unscoped git add -A or git add -u path.
   • Quote each path for the active shell and keep -- before path arguments. If a path cannot be represented safely, stop.
   • Record only the selected paths that were not initially staged as this invocation's staging delta.
   • If staging fails, report a concise error and stop without retrying.
4. Inspect and confirm the staged set. Use the host's staged-changes tool, such as get_changed_files with sourceControlState set to staged and repositoryPath set to the full project path.
   • Verify that the exact staged path set contains every selected path, contains every initially staged path, and contains no unselected path. If it differs, restore this invocation's staging delta and stop.
   • Present the exact staged paths without file contents or suspected sensitive values. Ask the user to confirm that these paths and their staged content are intended for the local commit.
   • If the user rejects, does not respond, or gives an ambiguous answer, restore this invocation's staging delta and stop without committing.
   • If no staged changes remain, output No changes to commit. and stop without creating an empty commit.
5. Generate the message from the staged changes and commit once, without showing the message first.
   • Pipe the exact message, including body and footer line, through STDIN, for example echo "<full message>" | git commit -F -. Preserve newlines exactly and end with the footer line followed by a newline.
   • Run no other Git command at this step (no push, pull, fetch, diff, show, status, log, branch, switch, merge, rebase, or tag).
6. After the commit succeeds, print Commit created successfully with the following message:, a blank line, and the full message in a fenced markdown code block.
7. If the commit fails, for example because a hook rejects it, report a concise error with a suggested fix and stop without retrying.