name	github-pr
description	Create or reuse a draft GitHub pull request for the current branch. Use when the user wants a GitHub draft PR opened or refreshed before review.

GitHub PR

Use the bundled script. Do not rebuild the gh calls manually.

Resolve the script from this skill directory.

SKILL_ROOT="<absolute-path-to-this-skill>"
SCRIPT="$SKILL_ROOT/scripts/create_or_reuse_draft_pr.sh"
"$SCRIPT" [--branch <name>] [--repo <owner/repo>] [--base <branch>] [--title <title>] [--body <body>]

This skill is for action, not display.

Workflow:

Inspect the current branch, commit history, and worktree state.
Inspect recent pull request titles in the target repository to learn the local title style, such as conventional commit prefixes, bracketed project tags, capitalization, or concise imperative phrasing.
Determine the PR diff against the base branch, then read the changed files and nearby code needed to understand the intent and behavior of the changes.
Write a concise PR title and description from that code-change analysis. The title should match the established style of recent pull requests when there is a clear pattern. The description should explain what changed and why it matters, not list commit subjects or restate file names mechanically.
If the user is asking to prepare the current work for review and the worktree has relevant uncommitted changes, stage and commit them before opening the PR.
If the branch has not been pushed yet, or local commits are ahead of the remote branch, push the branch before opening the PR.
Run scripts/create_or_reuse_draft_pr.sh only after the branch state is ready for GitHub PR creation, passing the analyzed title and description with --title and --body.

Rules:

Run scripts/create_or_reuse_draft_pr.sh after any needed commit and push steps.
Use the current branch unless the user names a different branch.
If a commit is needed and the user did not provide a message, write a concise commit message derived from the actual code changes.
If the worktree contains obviously unrelated or partial changes, stop and ask before committing them.
If no upstream exists yet, prefer git push -u <remote> <branch>. If an upstream already exists, prefer git push.
Always pass a PR title and body that you derived by analyzing the PR code changes. Treat the script-generated title and body only as a fallback for non-interactive script use.
Before choosing the PR title, look at recent PR titles with gh pr list --state all --limit 20 --json title or equivalent repository context, then follow the dominant local style when it is clear.
Do not build the PR body from a raw commit list, branch name, or a mechanical file list.
If GitHub reports that there are no commits between the base and head branches, explain that there is no PR diff left after commit/push checks instead of retrying blindly.
Report whether the draft PR was created or reused, including the PR number and URL when available.
Do not describe unsupported colon forms such as $github-pr:create.
Keep the reply short and operational.

GitHub PR

Use the bundled script. Do not rebuild the gh calls manually.

Resolve the script from this skill directory.

SKILL_ROOT="<absolute-path-to-this-skill>" SCRIPT="$SKILL_ROOT/scripts/create_or_reuse_draft_pr.sh" "$SCRIPT" [--branch <name>] [--repo <owner/repo>] [--base <branch>] [--title <title>] [--body <body>]

This skill is for action, not display.

Workflow:

Inspect the current branch, commit history, and worktree state.

Inspect recent pull request titles in the target repository to learn the local title style, such as conventional commit prefixes, bracketed project tags, capitalization, or concise imperative phrasing.

Determine the PR diff against the base branch, then read the changed files and nearby code needed to understand the intent and behavior of the changes.

Write a concise PR title and description from that code-change analysis. The title should match the established style of recent pull requests when there is a clear pattern. The description should explain what changed and why it matters, not list commit subjects or restate file names mechanically.

If the user is asking to prepare the current work for review and the worktree has relevant uncommitted changes, stage and commit them before opening the PR.

If the branch has not been pushed yet, or local commits are ahead of the remote branch, push the branch before opening the PR.

Run scripts/create_or_reuse_draft_pr.sh only after the branch state is ready for GitHub PR creation, passing the analyzed title and description with --title and --body.

Rules:

Run scripts/create_or_reuse_draft_pr.sh after any needed commit and push steps.

Use the current branch unless the user names a different branch.

If a commit is needed and the user did not provide a message, write a concise commit message derived from the actual code changes.

If the worktree contains obviously unrelated or partial changes, stop and ask before committing them.

If no upstream exists yet, prefer git push -u <remote> <branch>. If an upstream already exists, prefer git push.

Always pass a PR title and body that you derived by analyzing the PR code changes. Treat the script-generated title and body only as a fallback for non-interactive script use.

Before choosing the PR title, look at recent PR titles with gh pr list --state all --limit 20 --json title or equivalent repository context, then follow the dominant local style when it is clear.

Do not build the PR body from a raw commit list, branch name, or a mechanical file list.

If GitHub reports that there are no commits between the base and head branches, explain that there is no PR diff left after commit/push checks instead of retrying blindly.

Report whether the draft PR was created or reused, including the PR number and URL when available.

Do not describe unsupported colon forms such as $github-pr:create.

Keep the reply short and operational.

github-pr

GitHub PR

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

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

GitHub PR