Mmcp.market

gh-create-pr skill

by CherryHQ·CherryHQ/cherry-studio·52k stars·AGPL-3.0

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.

A100/100content scan

Is the gh-create-pr skill safe?

Clean: nothing in its files matched our rules. We read 2 files in the folder on 2026-09-28.

No findings.

Install the gh-create-pr skill

A skill is a folder. Copy it into your agent's skills folder and the agent loads it when the task matches its description. 

git clone --depth 1 https://github.com/CherryHQ/cherry-studio.git /tmp/cherry-studio
mkdir -p ~/.claude/skills
cp -r /tmp/cherry-studio/.agents/skills/gh-create-pr ~/.claude/skills/gh-create-pr
available in every project

In the Claude apps, zip the folder and upload it from the Skills settings. The folder on GitHub

The instructions your agent would load

SKILL.md as published, without the frontmatter. Read it on GitHub

GitHub PR Creation

Workflow

  1. Read .github/pullrequesttemplate.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.
git push -u <remote> <head-branch>
  1. Determine the base branch:
  • Inspect the head branch before applying any default. If the head is release/v, stop: never open a pull request from a release branch, especially not to main. Put an isolated fix on a topic branch and target the release branch, or let Post Release create the metadata sync branch.
  • Before defaulting an arbitrary topic branch to main, inspect its merge base and upstream. A product-code fix that started from release/v must stop and be recreated from main as a hotfix; only a release-only repair or explicit backport recovery topic may target that exact release branch.
  • A backport/v/pr- head must target the matching release/v base and its body must contain <!-- release-backport-source-pr: --> on its own line for the exact source hotfix PR. A release-sync/v head must target main, use the exact title chore(release): sync v metadata, retain the release-metadata-boundary: v body marker, and be squash-merged.
  • 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 development line, including hotfix PRs. Do not target an old maintenance branch unless the user explicitly requests it.
  • Only classify a PR as a release hotfix when the user explicitly says it must be included in the active draft release. Use the title hotfix: or hotfix(): with a lowercase alphanumeric kebab-case scope, exactly one space after the colon, and a non-empty description. The title grammar synchronizes the hotfix label automatically. Merging opens a separate backport PR only when exactly one draft semantic-version release has a matching active release/v branch; otherwise automation stops without guessing a target.
  • If the hotfix is user-facing, provide one release-note line in each language so automation can update the active draft and stable release history. Put this exact structure inside the template's existing release-note fence; do not include bullet prefixes:
<!--LANG:en-->
     [Component] English description.
     <!--LANG:zh-CN-->
     [组件] 中文说明。
     <!--LANG:END-->
  • If the hotfix has no user-facing release note, keep NONE in the template's release-note fence. The code is still backported, but release metadata is unchanged. A provided bilingual block must satisfy the exact structure above.
  • 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.

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

  1. Create a temp file and write the PR body using a single Bash heredoc
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.

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).

  1. Preview the temp file content via Bash cat "$prbodyfile" (the Read
  1. After confirmation, create the PR:
gh pr create --base <base> --head <head> --title "<title>" --body-file "$pr_body_file"

For a release hotfix, use an exact classifier-compatible title so the workflow synchronizes the label and separately validates any provided bilingual note:

gh pr create --base main --head <head> --title "hotfix: <description>" --body-file "$pr_body_file"

After creation, verify that the classifier added hotfix; if it did not, fix the title instead of adding the label manually. Also fix any malformed optional release-note block reported by the workflow.

  1. Clean up the temp file: rm -f "$prbodyfile"
  2. 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 use a hotfix title or label for an ordinary bug fix. It opts the PR into an automatic backport PR after merge when one matching draft release is active.
  • A release hotfix may use NONE when it has no user-facing release note. Never provide a partial, single-language, or otherwise malformed bilingual note; the backport workflow fails closed on malformed content.
  • Never default a release/v head to main; a release branch is not a pull request source branch.
  • 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:

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"

More skills from CherryHQ/cherry-studio

  • Acherry-assistant-guide从当前安装包查询 Cherry Studio 产品信息并排查运行问题。当用户询问功能、路由、快捷键、Provider、语言、Agent、频道、定时任务、Code CLI、当前版本，或报告运行错误、连接失败、配置异常并需要诊断时触发。
  • Acherry-browserInteract with the user's visible Agent browser in Cherry Studio. Use for page navigation, authenticated websites, screenshots, forms, clicks, and browser debugging. Check live browser tools first; browser control requires the Browser setting and an available Agent pane.
  • Acherry-electron-devDevelop, fix, and profile Cherry Studio in a tracked Electron instance. Use for everyday implementation, UI and interaction work, bug fixing, runtime debugging, DevTools inspection, lag or jank investigation, CPU and memory monitoring, leak checks, and startup-performance analysis; reuse a verified workspace instance across instructions and launch or replace one only when required.
  • Acherry-pr-testTest Cherry Studio PRs by resolving and checking out a PR, statically inspecting its changes, running interactive UI tests against a safely tracked Electron instance through CDP, producing a structured report, cleaning up only the owned test instance, and restoring the original branch.
  • Acherry-regression-testRun Cherry Studio critical-path system regression tasks through the repository-owned Playwright E2E workflow. Use for full regression, release acceptance, development-branch system validation, or a named cherry-regression-test task on GitHub-hosted macOS and Windows runners.
  • Acherry-skill-marketplace当用户明确要求搜索、安装、查看、卸载或创建 Skill，或内置 Skill / 工具出现能力缺口、无法完成当前任务时触发。通过 `mcp__skills__search_skills` 搜索并用 `mcp__skills__install_skill` 安装；已安装 Skill 的查看和删除通过产品清单导航到 Skills UI；没有合适结果时调用内置 `skill-creator` 创建并验证自定义 Skill，再继续原任务。普通任务仍先尝试内置能力。
  • Acherry-studio-feedbackUse when Cherry Studio 用户希望报告、提交或整理 BUG、UI/UX 问题或功能建议，但未明确要求创建 GitHub Issue。
  • Acherry-tool-guideCherry Studio first-party tool and bundled-shell routing for general agents. For straightforward local work in shell-capable sessions, run JS/TS with `bun <file>` and one-off JS tools with `bun x`; run Python with `uv run [--with <pkg>] python` and one-off Python CLIs with `uvx`; search with `rg`. Load this guide before changing project dependencies, deciding whether a tool should be ephemeral or reusable, reading or converting local Office/PDF files, coordinating or delegating across Agent Sessions, or using Cherry-owned web/browser, knowledge, persistent memory, schedules/notifications, IM channels, image generation, artifact reporting, managed CLI, skill, or MCP-server-registration capabilities—even if the user names no tool. Consult it before shell/file workarounds; live tool schemas are authoritative.
  • Aclaude-automation-recommenderAnalyze a codebase and recommend Claude Code automations (hooks, subagents, skills, plugins, MCP servers). Use when user asks for automation recommendations, wants to optimize their Claude Code setup, mentions improving Claude Code workflows, asks how to first set up Claude Code for a project, or wants to know what Claude Code features they should use.
  • Acode-mate-antigravityRuns Antigravity CLI headlessly for repository analysis and coding tasks. Use when the user asks to delegate work to Antigravity CLI or compare its result with another coding agent.
  • Acode-mate-claude-codeRuns Claude Code non-interactively for code analysis and implementation tasks. Use when the user asks to delegate repository work to Claude Code or compare its result with another coding agent.
  • Acode-mate-codexRuns Codex CLI non-interactively for code analysis and implementation tasks. Use when the user asks to delegate repository work to Codex or obtain a second coding-agent result.

All agent skills → · MCP servers