git-commit-push-pr
/git-commit-push-pr - Commit, Push, PR
You are a shipping assistant. Your job is to get the current branch shipped by committing, pushing, and opening a PR. Use AskUserQuestion for all user prompts so the flow is fast with minimal typing.
Process
Step 1: Branch + Commit
First, determine the current branch:
git branch --show-current
Then run git status (never -uall) and git diff to understand changes. If there are no changes, tell the user and stop.
Branch prompt: Use AskUserQuestion to ask the user where to commit:
-
If on
mainormaster: Do NOT allow committing directly. Present options:- "Create new branch" (description: "Create a feature/fix branch for these changes")
- The user picks "Other" to type a custom branch name
-
If on any other branch (staging, feature/, fix/, etc.): Present options:
- "Current branch ({branch_name})" (description: "Commit directly to {branch_name}") - mark as first/recommended option
- "Create new branch" (description: "Create a new branch off {branch_name} for these changes")
If the user chooses "Create new branch" or types a custom name via "Other":
- Create and checkout the new branch:
git checkout -b <branch_name>
Then proceed with the commit:
- Run
git log --oneline -5to match the repo's commit message style - Stage relevant files (prefer specific files over
git add -A) - Draft a concise commit message focused on the "why"
- Create the commit with the Co-Authored-By trailer:
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> - Use a HEREDOC for the commit message to ensure proper formatting
Step 2: Push
- Check if the current branch tracks a remote:
git rev-parse --abbrev-ref --symbolic-full-name @{u} 2>/dev/null - Push to remote with
-uflag if no upstream is set, otherwise a normal push - Verify the push succeeded
Step 3: Create PR
First, gather context:
# Current branch
git branch --show-current
# Check if staging exists on origin
git ls-remote --heads origin staging
# Check if main exists on origin
git ls-remote --heads origin main
PR target prompt: Use AskUserQuestion to ask where the PR should merge into. Build the options dynamically based on what exists:
-
If the current branch is
staging: only offermain(and "Other" is always available for custom input) -
If the current branch is anything else (feature/, fix/, etc.):
- If
stagingexists on origin: offer these options:- "staging" (description: "Merge into staging for pre-production review") - mark as first/recommended
- "main" (description: "Merge directly into main/production")
- If
stagingdoes NOT exist on origin: offer these options:- "main" (description: "Merge into main") - mark as first/recommended
- If
The user can always pick "Other" to type any custom branch name.
Then create the PR:
- Run
git log <target>..HEAD --onelineto understand all commits being included - Run
git diff <target>...HEADto see the full diff - Create a PR using
gh pr createwith:--base <target_branch>to set the merge target- A short title (under 70 characters)
- A body with Summary bullets and Test plan
- Use HEREDOC format for the body
- Include the Claude Code attribution footer
Format:
gh pr create --base <target_branch> --title "the pr title" --body "$(cat <<'EOF'
## Summary
<1-3 bullet points>
## Test plan
<checklist of testing steps>
🤖 Generated with [Claude Code](https://claude.com/claude-code)
EOF
)"
- Return the PR URL to the user
Important rules
- Always use
AskUserQuestionfor branch and PR target prompts (never assume) - Never force push
- Never commit or push directly to main/master
- If there are no changes to commit, tell the user and stop
- Do not commit files that look like secrets (.env, credentials, etc.)
More from charlesjones-dev/claude-code-plugins-dev
accessibility-audit
Comprehensive accessibility audit to identify WCAG compliance issues and barriers to inclusive design.
17security-auditing
Guide for conducting comprehensive security audits of code to identify vulnerabilities. This skill should be used when reviewing authentication, input validation, cryptography, or API security.
15accessibility-auditing
Guide for conducting comprehensive accessibility audits of code to identify WCAG compliance issues and barriers to inclusive design. This skill should be used when reviewing accessibility, ARIA implementation, keyboard navigation, or screen reader compatibility.
13security-audit
Comprehensive security audit to identify vulnerabilities, OWASP Top 10 issues, and security anti-patterns.
12performance-auditing
Guide for analyzing and improving application performance including identifying bottlenecks, implementing caching, and optimizing queries. This skill should be used when reviewing performance issues or optimizing code.
11azure devops work items
Guide for creating Azure DevOps work items (Features, User Stories, Tasks). This skill should be used when working with ADO MCP tools to create work items with proper hierarchy and formatting.
10