| name | gh-create-pr |
| description | Create or update GitHub pull requests using the repository-required workflow and template compliance. Use when asked to create/open/update a PR so the assistant reads `.github/pull_request_template.md`, fills every template section, preserves markdown structure exactly, and marks missing data as N/A or None instead of skipping sections. |
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
cat .github/pull_request_template.md
pr_body_file="/tmp/gh-pr-body-$(date +%s).md"
cat > "$pr_body_file" <<'EOF'
...filled template body...
EOF
cat "$pr_body_file"
gh pr create --base <base> --head <head> --title "<title>" --body-file "$pr_body_file"
rm -f "$pr_body_file"
