Gh Create Pr Agent Skill

GitHub PR Creation

Workflow

• Read .github/pull_request_template.md before drafting the PR body.
• Collect PR context from the current branch (base/head, scope, linked issues, testing status, breaking changes, release note content).
• Check if the current branch has been pushed to remote. If not, push it first:
• Default remote is origin, but ask the user if they want to use a different remote.

   git push -u <remote> <head-branch>

• Determine the base branch:
• For official repo(CherryHQ/cherry-studio) as origin: default base is main from origin, but allow the user to explicitly indicate a base branch.
• main is the active v2 development line. v1 maintenance fixes (head branch hotfix/*, critical user-facing bug fixes only) must target v1, not main — set the base to v1 for these.
• For fork repo as origin: check available remotes with git remote -v, default base may be upstream/main or another remote. Always assume that user wants to merge head to CherryHQ/cherry-studio/main, unless the user explicitly indicates a base branch.
• Ask the user to confirm the base branch if it's not the default.
• Create a temp file and write the PR body using a single Bash heredoc

(avoids mktemp + Write tool path-mismatch on Windows):

   pr_body_file="/tmp/gh-pr-body-$(date +%s).md"
   cat > "$pr_body_file" <<'EOF'
   ...filled template body...
   EOF

Fill content using the template structure exactly (keep section order,

headings, checkbox formatting). If not applicable, write N/A or None.

• Preview the temp file content via Bash cat "$pr_body_file" (the Read

tool can fail on /tmp/... paths on Windows). Show the file path and ask

for explicit confirmation before creating. Skip if the user explicitly

waives preview (automation workflows).

• After confirmation, create the PR:

   gh pr create --base <base> --head <head> --title "<title>" --body-file "$pr_body_file"

• Clean up the temp file: rm -f "$pr_body_file"
• Report the created PR URL and summarize title/base/head and any required follow-up.

Constraints

• Never skip template sections.
• Never rewrite the template format.
• Keep content concise and specific to the current change set.
• PR title and body must be written in English.
• Never create the PR before showing the full final body to the user, unless they explicitly waive the preview or confirmation.
• Never rely on command permission prompts as PR body preview.
• Release note & Documentation checkbox — both are driven by whether the change is user-facing. Use the table below:

| Change type | Release note | Docs [x] |

|---|---|---|

| New user-facing feature / setting / UI | Describe the change | ✅ |

| Bug fix visible to users | Describe the fix | ✅ if behavior changed |

| Behavior change / default value change | Describe + action required | ✅ |

| Security fix in a user-facing dependency | Describe the fix | ✅ if usage changed |

| CI / GitHub Actions changes | NONE | ❌ |

| Internal refactoring (user cannot tell) | NONE | ❌ |

| Dev / build tooling changes | NONE | ❌ |

| Dev-only dependency bump | NONE | ❌ |

| Test-only / code style changes | NONE | ❌ |

Command Pattern

# read template
cat .github/pull_request_template.md

# show this full Markdown body in chat first
pr_body_file="/tmp/gh-pr-body-$(date +%s).md"
cat > "$pr_body_file" <<'EOF'
...filled template body...
EOF
cat "$pr_body_file"

# run only after explicit user confirmation
gh pr create --base <base> --head <head> --title "<title>" --body-file "$pr_body_file"
rm -f "$pr_body_file"