Run any Skill in Manus with one click

gh-create-pr

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.

Run Skill in Manus

Overview

Install command

npx skills add https://github.com/CherryHQ/cherry-studio --skill gh-create-pr

Copy and paste this command into Claude Code to install the skill

Source

CherryHQ/cherry-studio

Stars46,819

Forks4,442

UpdatedMay 30, 2026 at 16:32

File Explorer

2 files

SKILL.md

readonly

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:
- 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/A or None.
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"

More from this repository

same repository

cherry-assistant-guide

CherryHQ/cherry-studio

Cherry Studio 产品知识库、源码路径索引、故障排查和页面导航。当用户询问 Cherry Studio 的功能、配置、报错、使用方法时触发。也适用于用户提到 provider、模型、知识库、Agent、MCP、OpenClaw、PDF、快捷短语等关键词的场景。

2026-05-1146.8k

gh-pr-review

CherryHQ/cherry-studio

Automated Cherry Studio code review for local branches, PRs, commits, and files. Use for reviewing code, docs, or pull requests with project-specific checks for DataApi boundaries, service ownership, renderer data hooks, React Hooks, lifecycle services, i18n, UI conventions, and tests. Supports single-agent review with interactive fix selection, or multi-agent deep review with reviewer-verifier adversarial mechanism and risk-based auto-fix.

2026-05-1146.8k

skill-creator

CherryHQ/cherry-studio

Create new skills, modify and improve existing skills, and measure skill performance. Use when users want to create a skill from scratch, edit, or optimize an existing skill, run evals to test a skill, benchmark skill performance with variance analysis, or optimize a skill's description for better triggering accuracy.

2026-05-0946.8k

faq-collector

CherryHQ/cherry-studio

将成功解决的用户问题收录到 FAQ 知识库。问题解决后自动判断是否收录。也可以在用户说"收录到 FAQ"、"记录这个问题"、"add to FAQ"时手动触发。

2026-04-0246.8k

issue-reporter

CherryHQ/cherry-studio

帮助用户提交 Bug Report 或 Feature Request。支持 GitHub Issue（有账户）和本地存档（无账户）两种模式。当诊断发现是代码 Bug 时主动提议，或当用户说"帮我提 issue"、"这是个 bug"、"我想要这个功能"、"submit a bug"、"feature request"时触发。

2026-04-0246.8k

skills-manager

CherryHQ/cherry-studio

搜索、安装和创建 Claude Code Agent Skills。当用户想要搜索技能、安装工具、创建自定义 Skill，或者说"find a skill"、"搜索技能"、"帮我做个 skill"、"create a skill"时触发。也适用于用户说"有没有做 X 的工具"、"我想扩展 Agent 能力"的场景。

2026-04-0246.8k

Source

CherryHQ

CherryHQ/cherry-studio

View GitHub Repository View Creator Repositories

Install command

Download

Run Skill in Manus

Useful forSOC

Software DevelopersComputer and Mathematical Occupations15-1252L4

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:
- 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/A or None.
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"