// Commit, push, and open a PR with an adaptive, value-first description. Use when the user says "commit and PR", "push and open a PR", "ship this", "create a PR", "open a pull request", or wants to go from working changes to an open pull request in one step. Also handles "update the PR description" or "refresh the PR description".
Explore requirements and approaches through collaborative dialogue before writing a right-sized requirements document and planning implementation. Use for feature ideas, problem framing, when the user says 'let's brainstorm', or when they want to think through options before deciding what to build.
Document a solved problem as reusable institutional knowledge with parallel research. Use when the user says 'document this', 'compound', 'save learnings', or wants to capture a solution for future reference.
Research the codebase and create a structured implementation plan. Use when the user says 'plan this', 'create a plan', 'how should we implement', or wants to turn a feature description into a structured implementation plan.
Scaffold a new custom agent — reviewers, researchers, or workflow agents. Use when asked to create, scaffold, or add a new agent.
Enhance an existing plan with parallel research agents for depth, best practices, and implementation details. Use when the user says 'deepen the plan', 'research more', or when a plan has high-risk dimensions that need more investigation.
Review requirements or plan documents using parallel persona agents that surface role-specific issues. Use when a requirements document or plan document exists and the user wants to improve it, or when invoked by /cplan for quality gating.
| name | git-commit-push-pr |
| description | Commit, push, and open a PR with an adaptive, value-first description. Use when the user says "commit and PR", "push and open a PR", "ship this", "create a PR", "open a pull request", or wants to go from working changes to an open pull request in one step. Also handles "update the PR description" or "refresh the PR description". |
Go from working tree changes to an open pull request in a single workflow, or update an existing PR description. PR descriptions communicate value and intent proportional to the complexity of the change.
If the user is asking to update, refresh, or rewrite an existing PR description (with no mention of committing or pushing), this is a description-only update. Follow the Description Update workflow below. Otherwise, follow the Full workflow.
Ask: "Update the PR description for this branch?" using #askQuestions.
git branch --show-current
gh pr view --json url,title,state
If no open PR exists for the current branch, report that and stop.
Read the current description, gather the full branch diff (see Step 6 of Full workflow), write a new description following the writing principles, and ask the user to confirm before applying:
gh pr edit --body "$(cat <<'EOF'
Updated description here
EOF
)"
git status
git diff HEAD
git branch --show-current
git log --oneline -10
git rev-parse --abbrev-ref origin/HEAD
Resolve the default branch (strip origin/ prefix). Fall back to gh repo view --json defaultBranchRef --jq '.defaultBranchRef.name', then to main.
Handle edge cases:
#askQuestionsgh pr view --json url,title,state
git add -A)git push -u origin HEAD
Use this fallback chain (stop at first success):
gh pr view --json baseRefName,urlgit symbolic-ref --quiet --short refs/remotes/origin/HEADgh repo view --json defaultBranchRef --jq '.defaultBranchRef.name'git merge-base <base-remote>/<base-branch> HEAD
git log --oneline <merge-base>..HEAD
git diff <merge-base>...HEAD
Use the full branch diff (not just working-tree diff) as the basis for the description.
| Change profile | Description approach |
|---|---|
| Small + simple (typo, config, dep bump) | 1-2 sentences, no headers. Under ~300 chars. |
| Small + non-trivial (targeted bugfix) | Short "Problem / Fix" narrative, ~3-5 sentences. |
| Medium feature or refactor | Summary paragraph + section on what changed and why. |
| Large or architecturally significant | Full narrative: context, approach, decisions, migration notes. |
## headers anywhere, put the opening under a heading too#: GitHub interprets #1 as issue referencesgh pr create --title "the pr title" --body "$(cat <<'EOF'
PR description here
EOF
)"
Keep the PR title under 72 characters.
The push already updated the PR. Ask if the user wants the description updated. If yes, write a new description covering the full PR scope and apply with gh pr edit --body.
Output the PR URL.