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.

설치로 이동

저장소: CherryHQ/cherry-studio
최근 소스 활동: 2026년 6월 27일 13:26
감지된 SKILL.md 언어: 영어
스타: 51,042
포크: 4,867

설치 방법

기본적으로 소스를 먼저 확인하는 Prompt가 선택됩니다. 직접 명령으로 전환하거나 로컬 사본을 다운로드할 수도 있습니다.

Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.

직접 명령은 검토 Prompt를 거치지 않습니다. 실행하기 전에 소스를 확인하세요.

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

명령은 한 줄로 유지됩니다. 복사하기 전에 가로로 스크롤해 전체 내용을 확인하세요.

로컬 사본을 원하시나요? SkillsMP에서 현재 제공할 수 있는 파일을 다운로드하세요.

소스 파일 검토

설치 여부를 결정하기 전에 SKILL.md와 SkillsMP에 표시된 보조 파일을 읽어 보세요.

파일 탐색기

2 개 파일

SKILL.md

소스 지침 · 읽기 전용 미리보기

검색으로 돌아가기 설치로 돌아가기

cherry-electron-dev

Develop, 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.

2026-08-25

gh-create-issue

Use when user wants to create a GitHub issue for the current repository. Must read and follow the repository's issue template format.

2026-08-22

cherry-tool-guide

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

2026-08-21

이 저장소의 모든 Skills 보기

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

# 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"

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.

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

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.

gh-create-pr

소스 정보

설치 방법

소스 파일 검토

이 저장소의 다른 Skills

GitHub PR Creation

Workflow

Constraints

Command Pattern

이 저장소의 다른 Skills

GitHub PR Creation

Workflow

Constraints

Command Pattern