git-commit-review-push

name	git-commit-review-push
description	Commit current changes with conventional commits format, ensure the /ai-review trigger is present on the final commit (preserving any Git trailer block), and push to remote repository. Use when committing and pushing changes so the pushed PR gets a full AI review.
allowed-tools	["Bash(git add:*)","Bash(git commit:*)","Bash(git log:*)","Bash(git push:*)"]
models	{"claude":"sonnet","copilot":"auto","codex":"gpt-5.4"}

Git Commit, Review-Trigger, and Push

Commit current changes using conventional commits format, embed the /ai-review full-review trigger in the last commit, and push to the remote repository.

Workflow Steps

1. Check if there are any changes to commit using git status --porcelain

2. If there are changes, analyze the diff and group it into logical units of work (chunks). Commit each chunk separately with a Conventional Commits message — <type>[optional scope]: <description> with type one of feat/fix/chore/docs/refactor/test/ci/perf/build; subject lowercase, imperative, no trailing period, ≤ 72 chars:

   • If a commit message was provided as an argument, use it (single-chunk commit)
   • Otherwise generate an appropriate conventional commit message per chunk from the staged diff

3. Review trigger (mandatory): the last chunk commit — or the only commit when there is a single chunk — MUST contain /ai-review. The review gate (pipeline-code-review-report.yml) greps the whole PR commit message for /ai-review and forces a full PR review when found, so its position and any trailing text are irrelevant. Keep the subject line clean and place the trigger in the body above any Git trailer block:

   feat(auth): add user authentication system
   
   /ai-review
   

   The gate also accepts a trigger in the subject (ci: /ai-review) or with trailing text (/ai-review — full sweep after the provider swap).

   Earlier chunk commits must NOT carry the trigger — only the final one.

4. If a commit was made in step 2, verify the trigger before pushing with the same whole-message matcher used by the review gate. If it is missing, amend it above a final Git trailer block so trailers retain their meaning:

   git log -1 --format='%B' | grep -qiE '/ai-review' || {
     git log -1 --format='%B'
     if git log -1 --format='%B' | git interpret-trailers --parse | grep -q .; then
       git log -1 --format='%B' | awk '
         BEGIN { RS=""; ORS="\n\n" }
         { para[NR]=$0 }
         END {
           for (i = 1; i < NR; i++) print para[i]
           print "/ai-review"
           printf "%s\n", para[NR]
         }' | git commit --amend -F -
     else
       git commit --amend -m "$(git log -1 --format='%B')" -m "/ai-review"
     fi
   }
   

   The paragraph-splitting awk snippet uses RS="" (paragraph-record mode) and therefore requires GNU awk (gawk). BSD/macOS /usr/bin/awk rejects RS="" as a gawk extension and degrades to character mode, which prints the whole message twice and can break the trailer block. On macOS run brew install gawk and either alias awk=gawk for the shell session or invoke the snippet with an explicit gawk ... instead of awk ....

   %B includes the subject and body, unlike %b, so subject triggers are recognized. The fallback echoes the full commit message, detects whether it has a final trailer block, and inserts the trigger before that block. For a message without trailers, the simpler amend form remains equivalent.

5. If there are no changes to commit, skip to step 6

6. If --issue <number> was passed — rename the local branch before pushing (see Branch Rename below)

7. Push to remote repository using git push (use git push --set-upstream origin <new-branch> if the branch was renamed)

8. If there's nothing to commit or push, report this to the user and continue gracefully (this is not an error)

Note: This command ONLY commits and pushes. It does not create or update PRs.

Branch Rename (when --issue <number> is passed)

This step enforces the branch naming convention (same type vocabulary as Conventional Commits):

<type>/<issue>-short-description

How to derive the new branch name:

1. <type> — take the type from the conventional commit just made (e.g. feat, fix, chore). If the branch already has a conforming name with the correct type, use that type.
2. <issue> — the number passed via --issue.
3. short-description — generate a concise, lowercase, hyphen-separated description (3–6 words) that summarises what was changed. Derive it from the commit message subject or the staged diff — do not reuse the current branch name verbatim.

Execution:

git branch -m <new-branch-name>     # rename local branch

Then push with upstream tracking:

git push --set-upstream origin <new-branch-name>

Constraints:

• Only rename if the current branch name does NOT already conform to <type>/<issue>-* for the given issue number.
• If the current branch already matches (e.g. feat/42-add-auth), skip the rename and push normally.
• Tell the user the old and new branch names when a rename happens.

Arguments

• Optional: pre-defined commit message (if not provided, will analyze changes and generate appropriate conventional commit message). The /ai-review trigger line is appended to the final commit regardless of whether the message was provided or generated.
• --issue <number> — renames the local branch to <type>/<number>-short-description before pushing, ensuring branch naming consistency

Usage Examples

/git-commit-review-push
/git-commit-review-push feat: add user authentication system
/git-commit-review-push --issue 42
/git-commit-review-push --issue 42 feat: add user authentication system