shield_lock
JinDaGe
← Back to skills
extension
Category: Development & EngineeringAPI key requirement unconfirmed

git-commit-push-pr

Commit, push, and create a PR. Prompts for branch and PR target using quick multi-choice questions. Lightweight alternative to /workflow-ship without preflight checks.

personAuthor: jakexiaohubgithub
open_in_newRepositorydownloadDownload package

/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:

    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.

  2. Create it with gh pr create:

    • --base <target>
    • A title under 70 characters.
    • A body with 1-3 summary bullets and a test plan. The test plan lists 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.
    • Pass the body through a HEREDOC:
    gh pr create --base <target> --title "the pr title" --body "$(cat <<'EOF'
## Summary
<1-3 bullet points>

## Test plan
<what was actually run>

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

  3. 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.