End-to-end commit-to-PR workflow. Use when the user says "create pr", "commit and pr", "push and pr", or wants to go from uncommitted changes to an open PR.
End-to-end commit-to-PR workflow. Use when the user says "create pr", "commit and pr", "push and pr", or wants to go from uncommitted changes to an open PR.
When to Use This Skill
Use this skill when...
Use X instead when...
Going from uncommitted changes to an open PR in one step
Creating commits only with no push or PR (/git:commit)
Auto-detecting issues, committing, pushing, and opening a PR together
Pushing existing commits to a remote without opening a PR (/git:push)
Running the full commit-push-PR pipeline non-interactively
Opening a PR from already-pushed commits (/git:pr-create)
--range <start>..<end>: Push specific commit range instead of all commits
--labels <label1,label2>: Apply labels to the created PR (requires --pr)
--skip-issue-detection: Skip automatic issue detection (use when --issue is provided or for trivial changes)
Your task
IMPORTANT: Execute all steps continuously without pausing to ask for confirmation between steps. This is a complete workflow — commit, push, and PR creation flow as a single operation. Do not stop after committing to ask whether to push or create a PR; proceed through all applicable steps.
Step 1: Verify State and Prepare Branch
Check for changes: Confirm there are staged or unstaged changes to commit (unless --no-commit)
Prepare branch:
If --direct: any branch is valid, stay on current branch
If on main/master: create a local feature branch before committing. Auto-generate the name from the changes (e.g., fix/handle-timeout-edge-case, feat/add-oauth-support). Use git checkout -b <branch-name>.
If already on a feature branch: stay on it
Step 2: Auto-Detect Related Issues (unless --skip-issue-detection or --issue provided)
Purpose: Automatically identify open GitHub issues that the staged changes may fix or close.
Analyze staged changes:
Get list of changed files: git diff --cached --name-only
Extract modified directories, file names, and content patterns
Identify error messages, function names, or keywords in the diff
Match against open issues:
Review the open issues from context (or fetch with gh issue list --state open)
Score each issue based on:
High confidence: File path mentioned in issue body, error message match
Medium confidence: Directory/component match, keyword overlap
User mentioned a deployment step, documentation update, or announcement
For each post-merge action identified, create a GitHub issue — not a PR checklist item. PR descriptions are closed and buried once a PR merges; issues remain open until resolved.
Write the follow-up body to a tempfile with the Write tool and pass it via --body-file. Inline --body "..." mangles backticks and multi-line content via shell escaping; see the Body content rule in github-issue-writing.
# Write tool → /tmp/follow-up.md (markdown body, no shell escaping)
gh issue create \
--title "[Chore] DB: Run migration for new schema" \
--body-file /tmp/follow-up.md \
--label "chore"# Note the returned issue number for the PR body
Common follow-up types: database migrations, production deployments, manual config changes, external documentation updates, customer-facing announcements, dependent follow-on PRs.
5b. Create the PR, including follow-up issue links in the body.
Use mcp__github__create_pull_request with:
head: The remote branch name (e.g., feat/auth-oauth2)
base: main
title: Derived from commit message
body: Include summary, issue link if --issue provided, and a Follow-up Issues section listing any issues created in 5a. The MCP tool takes the body as a JSON string parameter — no shell escaping, so backticks and code fences pass through unchanged.
draft: true if --draft flag set
If falling back to gh pr create instead of the MCP tool, write the body to a tempfile and pass --body-file /tmp/pr-body.md (see the Body content rule in github-issue-writing).
PR body structure when follow-up issues exist:
## Summary
...
## Follow-up Issues
<!-- Post-merge actions tracked as issues so they survive PR closure -->
- #456: run database migration for new schema
- #457: update production feature-flag config
## Related Issues
Fixes #123
If --labels provided, add labels after PR creation:
After PR creation, watch CI checks to confirm the PR is ready for merge:
# Watch all checks (not just required — many repos have no required checks configured)
gh pr checks <pr-number> --watch --fail-fast
On success (exit 0):
Report: "All checks passed. PR #N is ready for merge."
Provide merge command: gh pr merge <pr-number> --squash --delete-branch
Pitfall — --delete-branch from the PR's own working tree: before running gh pr merge <N> --squash --auto --delete-branch, switch your working tree to main (or any branch other than the PR head). If your cwd or any worktree has the PR's branch checked out, the local-branch-delete step fails with cannot delete branch 'X' used by worktree at Y even though the server-side merge is queued correctly. The misleading error makes it look like the merge failed; confirm with gh pr view <N> --json state.
