mahabdalla GitHub PR Creation
Workflow
- Read
.github/pull_request_template.mdbefore 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> - Default remote is
- Determine the base branch:
- For official repo(CherryHQ/cherry-studio) as
origin: default base ismainfromorigin, but allow the user to explicitly indicate a base branch. - For fork repo as
origin: check available remotes withgit remote -v, default base may beupstream/mainor 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.
- For official repo(CherryHQ/cherry-studio) as
- Create a temp file and write the PR body:
- Use
pr_body_file="$(mktemp /tmp/gh-pr-body-XXXXXX).md" - Fill content using the template structure exactly (keep section order, headings, checkbox formatting).
- If not applicable, write
N/AorNone.
- Use
- Preview the temp file content. Show the file path (e.g.,
/tmp/gh-pr-body-XXXXXX.md) and ask for explicit confirmation before creating. Skip this step if the user explicitly indicates no preview/confirmation is needed (for example, 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="$(mktemp /tmp/gh-pr-body-XXXXXX).md"
cat > "$pr_body_file" <<'EOF'
...filled template body...
EOF
# 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"
Converted and distributed by TomeVault | Claim this content