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