nvidia/create-github-pr
Create GitHub pull requests using the gh CLI. Use when the user wants to create a new PR, submit code for review, or open a pull request. Trigger keywords - create PR, pull request, new PR, submit for review, code review.
npx skills add https://github.com/NVIDIA/OpenShell --skill create-github-pr
Create pull requests on GitHub using the gh CLI.
gh CLI must be authenticated (gh auth status)<issue-number>-<description>/<username>. Exempt issue-less changes may use <description>/<username>.If the branch changes gateway TOML parsing, [openshell.gateway] fields,
[openshell.drivers.<name>] fields, driver config defaults, or Helm rendering
of gateway.toml, verify that docs/reference/gateway-config.mdx is updated
in the same branch. If the change affects user-facing compute-driver setup,
also update docs/reference/sandbox-compute-drivers.mdx or the relevant
deployment docs.
Use the sync-agent-infra skill's maintenance map to identify related skill updates when the branch changes behavior, commands, or development workflows. Run its full consistency check when the branch adds, removes, or renames skills or crates; changes workflow relationships or skill coverage; modifies issue or PR templates; or changes agent cross-references. Resolve any drift before creating the PR.
Run the local pre-commit task before opening a PR:
mise run pre-commit
Before creating a PR, verify:
# Should NOT be "main"
git branch --show-current
<issue-number>-<description>/<initials> for issue-backed work or <description>/<initials> for an exempt issue-less change. # Example: 1234-add-pagination/jd
git branch --show-current
# Squash last N commits into one
git reset --soft HEAD~N
git commit -m "feat(component): description"
Ensure your branch is pushed to the remote:
git push -u origin HEAD
Basic PR creation (opens editor for description):
gh pr create
With title and body:
gh pr create --title "PR title" --body "PR description"
PR titles must follow the conventional commit format:
<type>(<scope>): <description>
Types:
feat - New featurefix - Bug fixdocs - Documentation onlyrefactor - Code change that neither fixes a bug nor adds a featuretest - Adding or updating testschore - Maintenance tasks (CI, build, dependencies)perf - Performance improvementScope is typically the component name (e.g., evaluator, cli, sdk, jobs).
Examples:
feat(evaluator): add support for custom rubricsfix(jobs): handle timeout errors gracefullydocs(sdk): update authentication examplesrefactor(models): simplify deployment logicchore(ci): update Python version in pipelineFeatures, user-visible behavior changes, public API changes, architecture changes, and multi-PR efforts must link an accepted issue. Use Closes #<issue-number> in the body to auto-close the issue when merged:
gh pr create \
--title "Fix validation error for empty requests" \
--body "Closes #123
## Summary
- Added validation for empty request bodies
- Returns 400 instead of 500"
Small documentation fixes, mechanical maintenance, and obvious localized bug fixes may omit a separate issue when the PR contains enough context to review the decision and implementation together. In that case, write No issue required: <brief reason> in the Related Issue section. Do not use this exception for security fixes; follow SECURITY.md.
For work-in-progress that's not ready for review:
gh pr create --draft --title "WIP: New feature"
gh pr create --title "Title" --label "area:cli" --label "topic:security"
Default target is main. To target a different branch:
gh pr create --base "release-1.0"
PR descriptions must follow the project's PR template structure:
## Summary
<!-- 1-3 sentences: what this PR does and why -->
## Related Issue
<!-- Fixes #NNN / Closes #NNN, or "No issue required: <reason>" for an exempt change -->
## Changes
<!-- Bullet list of key changes -->
## Testing
<!-- What testing was done? -->
- [ ] `mise run pre-commit` passes
- [ ] Unit tests added/updated
- [ ] E2E tests added/updated (if applicable)
## Checklist
- [ ] Follows Conventional Commits
- [ ] Commits are signed off (DCO)
Populate the testing checklist based on what was actually run. Check boxes for steps that were completed.
gh pr create \
--title "feat(cli): add pagination to sandbox list" \
--body "$(cat <<'EOF'
## Summary
Add `--limit` and `--offset` flags to `openshell sandbox list` for pagination.
## Related Issue
Closes #456
## Changes
- Added `offset` and `limit` query parameters to the sandbox list API call
- Default limit is 20, max is 100
- Response includes `total_count` field
## Testing
- [x] `mise run pre-commit` passes
- [x] Unit tests added/updated
- [ ] E2E tests added/updated (if applicable)
## Checklist
- [x] Follows Conventional Commits
- [x] Commits are signed off (DCO)
EOF
)"
| Option | Description |
| ------------------- | ------------------------------------------ |
| --title, -t | PR title (use conventional commit format) |
| --body, -b | PR description |
| --reviewer, -r | Request review from user |
| --draft | Create as draft (WIP) |
| --label, -l | Add label (can use multiple times) |
| --base, -B | Target branch (default: main) |
| --head, -H | Source branch (default: current) |
| --web | Open in browser after creation |
The command outputs the PR URL and number.
Display the URL using markdown link syntax so it's easily clickable:
Created PR [#123](https://github.com/OWNER/REPO/pull/123)
If the user asks to wait for a green CI before posting the RFR, use this snippet to monitor the workflow run:
# Watch the latest workflow run for the current branch
gh run watch
Or poll manually:
RUN_ID=$(gh run list --branch "$(git branch --show-current)" --limit 1 --json databaseId --jq '.[0].databaseId')
gh run watch "$RUN_ID"
Take nvidia/create-github-pr from the repository into ~/.claude/skills for personal
use, or into .claude/skills inside a project.
The agent identifies a skill by the name field in its header. Two skills with the
same name cannot sit side by side — one of them will be ignored.