Commit Changes: $ARGUMENTS

CRITICAL: Use mcp__acp__Bash for ALL git commands. NEVER use the Task subagent or the built-in Bash tool — they run in an isolated sandbox. Commits will NOT persist there.

Follow these steps in order. Do not skip steps.

Step 1: Assess Working Tree

Run git status and git diff --stat to understand the current state.

• •If nothing changed: Inform the user there is nothing to commit. Stop.
• •If changes exist but nothing is staged: Show the unstaged files and ask the user what to stage. Default: stage everything with git add -A.
• •If changes are already staged: Proceed to Step 2.

Safety Check

Before staging, scan the file list for sensitive files:

• •.env, *.pem, *.key, *.secret, credentials files
• •If any are found, warn the user and ask for explicit confirmation before staging them.

Step 2: Analyze the Diff

Run git diff --staged to read the full staged diff.

Understand:

• •Which files were added, modified, or deleted
• •What the changes do functionally
• •Whether this is a feature, bugfix, refactor, docs change, chore, etc.

Step 3: Compose Commit Message

Generate a commit message following Conventional Commits:

<type>[optional scope]: <description>

[optional body]

Types: feat, fix, refactor, docs, chore, test, style, perf, ci, build

Rules:

• •Subject line max 72 characters
• •Use imperative mood ("add feature" not "added feature")
• •Body only for complex changes — explain why, not what
• •If $ARGUMENTS is provided, use it as the commit message or as guidance

Show the proposed message to the user and wait for approval or edits.

Step 4: Commit

Execute git commit -m "<approved message>".

Show the commit result (git log -1 --oneline).

Rules

• •Never use --amend, --no-verify, or --allow-empty
• •Never commit on behalf of the user without showing the message first
• •Keep commits atomic — one logical change per commit