charlesjones-dev/claude-code-plugins-dev/git-commit-push-pr

/git-commit-push-pr - Commit, Push, PR

Commit the current changes, push them, and open a pull request. Ask the user where to commit and where the PR should merge, and never assume either.

Ask every question with the AskUserQuestion tool when it's available, so the user can answer with one pick. Otherwise ask in plain text, number the options, and wait for the answer.

Arguments

The text typed after the command holds the arguments. In Claude Code it is inserted here: $ARGUMENTS. In other agents, read it from the user's message. It may be empty.

• --preflight: run the git-preflight skill with --fix before anything else (Step 1).
• --no-pr: commit and push, then stop without opening a PR.

The two can be combined. Ignore anything else in the arguments, including a commit message, and say in one line that you did: the message comes from the diff.

Step 1: Preflight (only with --preflight)

Run the git-preflight skill from this plugin with --fix as its arguments. It runs the project's typecheck, lint, format, security and test checks, applies the auto-fixes it can without asking, and re-runs what failed.

• Claude Code: call the Skill tool with skill ai-git:git-preflight and args --fix.
• Codex and Cursor: load the git-preflight skill from this plugin (Codex lists it as ai-git:git-preflight), and follow its instructions with --fix as its arguments.

If the skill can't be loaded, stop and tell the user to run /git-preflight --fix ($ai-git:git-preflight --fix in Codex), then run this command again without --preflight.

When preflight finishes:

• It applied fixes: stop. Tell the user what failed and what was fixed, ask them to review the fixes, and tell them to run this command again once they're satisfied.
• Problems remain that it couldn't fix: stop and report them.
• Every check passed with no fixes: continue. If the project has no checks configured, say so and continue.

Step 2: Analyze the changes

1. git branch --show-current
2. git status (never -uall, which can exhaust memory on large repos). If there is nothing to commit (no untracked files and no modifications), tell the user and stop.
3. git diff and git diff --staged to see the changes.
4. git log -5 --format='%s' to see the repo's commit message style.

Step 3: Pick the branch

Ask where to commit:

• On `main`, `master` or the repo's default branch: don't commit there. Offer:
• "Create new branch" (description: "Create a feature/fix branch for these changes")
• The user can type a branch name instead ("Other" in AskUserQuestion).
• On any other branch (staging, feature/, fix/, etc.), offer:
• "Current branch ({branch_name})" (description: "Commit directly to {branch_name}"), first and recommended
• "Create new branch" (description: "Create a new branch off {branch_name} for these changes")

If the user picks "Create new branch", name it after the change in the style of the repo's branches (feat/..., fix/...). If they typed a name, use it. Then git checkout -b <branch_name>.

Step 4: Stage and commit

1. Stage the changed files by name. Don't use git add . or git add -A.
2. Never stage files that look like secrets: .env, .env.*, credentials.*, *.key, *.pem, *.secret and similar. If any are present, skip them and warn the user.
3. Write a concise commit message that says what changed and why, follows the style from Step 2, and uses conventional commit prefixes (feat:, fix:, docs:) if the repo uses them.
4. Add no AI attribution to the commit: no Co-Authored-By trailer, no "Generated with" line, and nothing else that credits Claude, Codex, Cursor or another agent.
5. Pass the message through a HEREDOC:

``bash git commit -m "$(cat <<'EOF' your commit message here EOF )" ``

Step 5: Push

1. Check for an upstream: git rev-parse --abbrev-ref --symbolic-full-name @{u} 2>/dev/null
2. With no upstream, git push -u origin <branch>. Otherwise git push.
3. If the push is rejected, report why and stop. Never force push.

With --no-pr, show the branch and commit hash, and stop here.

Step 6: Pick the PR target

Opening a PR needs the GitHub CLI (gh), installed and authenticated. If it isn't, say so and stop: the commit is already pushed.

If the branch already has an open PR (gh pr view --json url,state shows OPEN), the push updated it. Give its URL and stop.

Gather context:

# The repo's default branch
gh repo view --json defaultBranchRef --jq .defaultBranchRef.name
 
# Whether staging exists on origin
git ls-remote --heads origin staging

Ask where the PR should merge, with options built from what exists:

• On `staging`: offer only the default branch.
• On any other branch:
• If staging exists on origin: "staging" (description: "Merge into staging for pre-production review"), first and recommended, then the default branch (description: "Merge directly into {default}").
• Otherwise: the default branch (description: "Merge into {default}"), recommended.

The user can always type another branch name.

Step 7: Open the PR

1. git fetch origin <target>, then git log origin/<target>..HEAD --oneline and git diff origin/<target>...HEAD to see everything the PR includes. Check that it matches the goal of the change, and nothing else.
2. Write the title and body:

• Title: under 70 characters, in the style of the repo's recent PR titles (gh pr list --state merged --limit 5 --json title), since PR titles often become commit messages. Say what the change does for the user, not how it works: "Cut websocket message size by about 70% with compression", not "Negotiate permessage-deflate on the websocket".
• Summary: open with the problem in a sentence or two of plain words, as the user described it. Then say briefly how the change fixes it. Don't lead with a list of every file, function or entry point the change touches. Add up to 3 bullets only for changes a reviewer could miss.
• Test plan: list only what was actually run: the preflight checks with --preflight, commands run in this session, or testing the user described. If nothing was run, write "Not tested" and one sentence on what needs checking.
• End the body with an attribution line for the agent running this skill: 🤖 Generated with [Claude Code](https://claude.com/claude-code) in Claude Code, 🤖 Generated with [Codex](https://openai.com/codex) in Codex, or 🤖 Generated with [Cursor](https://cursor.com) in Cursor.
• Check the title and body, including anything quoted, for secrets and private details.

1. Create it with gh pr create as a real PR, not a draft, so review bots run. Pass the body through a HEREDOC:

```bash gh pr create --base <target> --title "the pr title" --body "$(cat <<'EOF' ## Summary <the problem, then the fix, in a few sentences>

## Test plan <what was actually run>

<attribution line for the agent running this skill> EOF )" ```

If it fails because the GitHub GraphQL rate limit is used up, open the PR through the REST API, which has its own limit. Write the body to a file, then run gh api repos/{owner}/{repo}/pulls -f title="<title>" -f head=<branch> -f base=<target> -F body=@<file>.

1. Give the user the PR URL.

Rules

• Ask the branch and PR target questions every time. Never assume.
• Never commit or push directly to main, master or the default branch.
• Never force push.
• Never use git status -uall.
• Never commit files that look like secrets.
• No AI attribution in commit messages. The PR body ends with the line naming the agent that ran the skill.
• If there is nothing to commit, say so and stop.

Step 7's guidance on PR titles and descriptions is adapted from file-pr in tstack by Theo Browne (MIT). See THIRD-PARTY-NOTICES.md in this plugin.