" --body-file "$pr_body_file" ``` 8. Clean up the temp file: `rm -f "$pr_body_file"` 9. 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 ```bash # 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

--- name: cherryhq/gh-create-pr source: https://app.decimal.ai/s/cherryhq-gh-create-pr@1/SKILL.md source_sha256: 5c62c22a34fc --- # GitHub PR Creation ## Workflow 1. Read `.github/pull_request_template.md` before drafting the PR body. 2. Collect PR context from the current branch (base/head, scope, linked issues, testing status, breaking changes, release note content). 3. 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. ```bash git push -u

``` 4. 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. 5. Create a temp file and write the PR body using a single Bash heredoc (avoids `mktemp` + `Write` tool path-mismatch on Windows): ```bash 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`. 6. 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). 7. After confirmation, create the PR: ```bash gh pr create --base --head --title "" --body-file "$pr_body_file" ``` 8. Clean up the temp file: `rm -f "$pr_body_file"` 9. 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 ```bash # 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" ```