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.

الانتقال إلى التثبيت

المستودع: ComeOnOliver/skillshub
آخر نشاط في المصدر: ٢٣ مارس ٢٠٢٦ في ١٧:٤٣
لغة SKILL.md المكتشفة: الإنجليزية
النجوم: ٥٨
التفرعات: ٢٠

خيارات التثبيت

يُحدَّد Prompt الذي يراجع المصدر أولًا بشكل افتراضي. يمكنك التبديل إلى أمر مباشر أو تنزيل نسخة محلية.

التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.

يتجاوز الأمر المباشر Prompt المخصّص للمراجعة. افحص المصدر قبل تشغيله.

npx skills add https://github.com/ComeOnOliver/skillshub --skill gh-create-pr

يبقى الأمر في سطر واحد. مرّر أفقيًا لمراجعته كاملًا قبل النسخ.

تفضّل نسخة محلية؟ نزّل الملفات المتاحة حاليًا لدى SkillsMP.

مراجعة ملفات المصدر

اقرأ SKILL.md وأي ملفات مرافقة يعرضها SkillsMP قبل أن تقرر التثبيت.

SKILL.md

تعليمات المصدر · معاينة للقراءة فقط

العودة إلى البحث العودة إلى التثبيت

before-you-build

Review product and feature risk before an AI coding agent starts implementation.

2026-06-24

x-twitter-scraper

Use Xquik for X data and confirmation-gated X actions: tweet search, user lookup, follower export, media download, monitors, webhooks, MCP, and SDK workflows.

2026-06-24

canton-network-repos

Canton Network open-source ecosystem guide covering DAML SDK, Canton runtime, and Splice applications. Use when working with Canton Network, DAML smart contracts, or building decentralized applications.

2026-04-03

عرض الكل من هذا المستودع

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

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

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

معلومات المصدر

خيارات التثبيت

مراجعة ملفات المصدر

المزيد من هذا المستودع

المزيد من هذا المستودع

GitHub PR Creation

Workflow

Constraints

Command Pattern

GitHub PR Creation

Workflow

Constraints

Command Pattern