Gh Commit Push Pr

When To Use

• User asks to commit and push changes, create a PR, or ship/send work for review
• Triggers on phrases like "commit and push", "create a PR", "open a pull request", "ship it"
• Changes are staged or unstaged in the working tree and need to reach a remote branch with a PR

Boundaries

• Not for rebasing, merging, or resolving conflicts; those require user-directed decisions
• Do not force push or amend existing commits unless the user explicitly requests it
• Never commit files that look like secrets (.env, *.pem, *.key, credentials.json)
• Skip when git status shows a clean working tree with nothing to commit

Verification

• Branch is pushed to origin and git status shows no unpushed commits
• PR is created with a summary and test plan; gh pr view returns a valid URL
• No duplicate PR exists for the same branch (checked before creation)
• Sensitive files are excluded from the commit and flagged to the user if detected

Commit, Push, and Open a Pull Request

Context

Gather state before acting:

• Current branch: !git branch --show-current
• Current git status: !git status
• Staged and unstaged changes: !git diff HEAD

Workflow

Step 1: Pre-flight Checks

Before doing anything, verify:

• Changes exist: If git status shows nothing to commit (clean working tree), stop and tell the user. Do not create empty commits.
• Not in detached HEAD: If HEAD is detached, create a branch first.
• Not on main/master with intent to push directly: If on main or master, always create a new branch before committing.
• GitHub CLI auth is ready: Run gh auth status. If not authenticated, stop and ask user to authenticate first.
• Determine base branch: Prefer gh repo view --json defaultBranchRef --jq '.defaultBranchRef.name' over assumptions.

Step 2: Create Branch (if needed)

If on main/master or detached HEAD, create a feature branch:

• Convention: <type>/<short-description> where type is one of: feat, fix, chore, docs, refactor, test, ci
• Examples: feat/add-user-search, fix/null-pointer-on-login, docs/update-readme
• Use git checkout -b <branch-name> to create and switch

Step 3: Stage and Commit

Stage changes if not already staged, then commit:

• Commit message format: Start with a verb in imperative mood (Add, Fix, Update, Remove, Refactor)
• First line: Concise summary, max ~72 characters
• Body (if changes warrant it): Blank line after summary, then explain why not what
• Reference issues if applicable: Fixes #123 or Closes #456
• Do NOT commit files that look like secrets (.env, credentials.json, *.pem, *.key)

Step 4: Push

Push the branch to origin:

git push -u origin <branch-name>

If push fails:

• Authentication error: Tell the user to check their git credentials or gh auth status
• Rejected (non-fast-forward): The remote branch has diverged. Tell the user — do not force push
• Remote not found: Check with git remote -v and report
• Network error: Retry once after a brief pause. If it fails again, report the error

Step 5: Create Pull Request

Create a PR using gh pr create:

gh pr create --base "<base-branch>" --head "<branch-name>" --title "<imperative summary>" --body-file "<path>"

PR body structure:

• Summary: 1-3 bullet points describing what changed and why
• Test plan: How to verify the changes work (commands to run, things to check)

If the repo has a PR template, gh pr create will use it automatically. Do not override templates.

Before creating, check if PR already exists for this branch:

gh pr view --head "<branch-name>" --json url --jq '.url'

If that returns a URL, report it and do not create a duplicate PR.

When generating PR body text, NEVER inline complex markdown in --body if it may contain shell-sensitive characters (especially backticks). Use a body file:

tmp_pr_body="$(mktemp)"
cat > "$tmp_pr_body" <<'EOF'
## Summary
- <what changed and why>

## Test plan
- [ ] <how to verify>
EOF

gh pr create --base "<base-branch>" --head "<branch-name>" --title "<title>" --body-file "$tmp_pr_body"
rm -f "$tmp_pr_body"

If gh pr create fails, handle by error pattern:

• error connecting to api.github.com / network denied: retry once; if sandbox/network restrictions apply, rerun with escalated network permissions.
• A pull request already exists: run gh pr view --head "<branch-name>" --json url --jq '.url' and report existing URL.
• not logged into any GitHub hosts: stop and ask user to run gh auth login.
• No commits between: branch has no diff against base; report and stop.
• permission denied/command not found lines caused by PR body text: this usually means shell interpolation from unescaped markdown; rerun using --body-file.
• Validation/base errors: re-check base branch via gh repo view --json defaultBranchRef --jq '.defaultBranchRef.name' and retry with explicit --base.

Step 6: Report Back

After all steps complete, report:

• Branch name
• Commit message summary
• PR URL
• Any warnings (e.g., large diff, binary files, files that look sensitive)

Edge Cases

Tool Call Strategy

You MUST call multiple tools in a single response when the calls are independent. For example, git add and git status can be parallel. But git commit must follow git add, and git push must follow git commit. Chain dependent operations sequentially.

Command Wrapper

If the harness supports command files, use commands/commit-push-pr.md as the canonical entrypoint for this skill.

Sibling skills

The remaining gh-* skill. It owns the commit-to-PR step end to end; the issue-triage and PR-review skills that used to sit either side of it were retired 2026-07-31 as unused.

• local-review — review the diff before this skill commits it.
• verify-before-complete — confirm the work is actually done before opening a PR.