creating-pull-request — how to create a pull request how to create a pull request, creating-pull-request setup guide, git pull request conventions, collaborative coding best practices, creating-pull-request vs git flow, install creating-pull-request, creating-pull-request alternative, what is creating-pull-request, creating-pull-request tutorial

Current state

• Repo: !gh repo view --json nameWithOwner -q '.nameWithOwner'
• Branch: !git branch --show-current
• Commits on branch: !git log --oneline main..HEAD 2>/dev/null || echo "(no commits vs main)"
• Remote: !git remote -v | head -2

Task

$ARGUMENTS

Reference

Read docs/CONTRIBUTING.md before proceeding for PR title conventions.

For PR body format, see template.md.

Source of truth for type lists, regex patterns, and label mappings: .claude/conventions/types.sh.

Steps

Execute these steps in order. Do NOT skip any HARD GATE.

Step 1: Determine owner/repo

bash
1gh repo view --json nameWithOwner -q '.nameWithOwner'

Split into {owner} and {repo}.

Step 2: Create the PR

Use gh pr create. Do NOT use the GitHub MCP tool — gh CLI avoids the \n pitfall.

bash
1gh pr create --base main --head "$(git branch --show-current)" \
2  --draft \
3  --title "[Type] Description" \
4  --body "$(cat <<'PREOF'
5<fill in from template.md>
6PREOF
7)"

Draft-first workflow: Always create PRs as draft. Copilot reviews drafts automatically; Gemini must be triggered separately (see lifecycle-pull-request Phase 2b). Once CI passes and both bot reviews are addressed, the lifecycle-pull-request skill marks the PR ready, triggering human reviewer notifications.

PR title rules:

• Must use bracket format: [Type] Description or [Type][Scope] Description
• Types: [Feat], [BugFix], [Fix], [Refactor], [Enhancement], [Doc], [Chore], [Bench], [CI], [Test], [Perf]
• Keep under ~80 chars
• Do NOT put issue references in the title (e.g. (#123)). Link issues in the PR body with Closes #123 instead.

PR body section rules:

• ## Summary — always required
• ## Test plan — always required
• ## Benchmark — required when PR involves performance changes
• ## Regression — recommended when PR is bugfix or refactor
• ## Additional context — optional
• Delete inapplicable optional sections entirely. Never leave empty headers.

Step 3: Add labels (MANDATORY)

At least one label is required. Select based on PR type:

Authorship label (required):

• all-ai-powered — always add this label (you are an AI creating this PR)

bash
1gh pr edit <PR_NUMBER> --add-label "<label1>" --add-label "<label2>"

Step 4: HARD GATE — Validate PR

bash
1.claude/skills/creating-pull-request/scripts/validate.sh <owner/repo> <PR_NUMBER>

If exit code != 0: STOP. Fix the reported issues:

• Wrong title → gh pr edit <N> --title "[Type] New title"
• Missing body section → gh pr edit <N> --body "$(cat <<'EOF' ... EOF)"
• Missing labels → gh pr edit <N> --add-label "<label>"

Re-run the gate until it passes.

Responding to reviewer feedback

When addressing reviewer comments (from Copilot, Gemini, or humans):

• Always reply inline on the specific comment thread. Never post a summary comment on the PR conversation.
• Use the review API to create inline comments on the exact lines being discussed.
• For each comment: acknowledge, state what was fixed, and reference the commit SHA.

Return format

Report exactly:

• PR_NUMBER: <number>
• PR_URL: <url>
• BRANCH: <branch-name>
• SUMMARY: <one-line summary>