Create a Pull Request with Git and gh

VerifiedCaution

Automates feature branch creation, committing, pushing, and opening a draft PR against iopsystems/rezolus using gh.

Sby Skills Guide Bot
DevelopmentIntermediate
1010/18/2026
Claude Code
#git#pull-request#github-cli#conventional-commits#branching

Recommended for

Our review

Automates the full pull-request workflow for the iopsystems/rezolus repo: branch, commit, push, and open a draft PR.

Strengths

  • Chains every git and gh step (branch, commit, push, PR) starting from uncommitted changes
  • Enforces repo conventions: conventional commit messages, docs version-label sync, and alpha revision bumps in Cargo.toml
  • Checks prerequisites (non-empty diff, current branch) and runs clippy/test/fmt when they haven't run yet
  • Opens PRs as drafts with a structured summary and test-plan body

Limitations

  • Tightly coupled to iopsystems/rezolus, its scripts/sync-docs-version.sh helper and its alpha versioning scheme
  • Assumes a fork/origin remote layout with an authenticated gh CLI and an accessible upstream
  • Doesn't update existing PRs, resolve merge conflicts, or force push (by design)
  • No way to supply a fully custom PR body beyond the built-in template
When to use it

Use it when you have uncommitted changes in a rezolus checkout and want a draft PR opened upstream with minimal manual steps.

When not to use it

Avoid it on repositories other than rezolus, or when you need to amend an existing PR, rewrite history, or handle merge conflicts.

Security analysis

Caution
Quality score88/100

The skill instructs legitimate git and GitHub workflows for a specific repository, including branching, committing, pushing, and opening a PR. No destructive or exfiltrating commands are present, but it does execute local scripts and remote actions, which warrants caution rather than safe.

Findings
  • •Runs a repository-local script (./scripts/sync-docs-version.sh) without inspecting its contents, which could perform unintended actions.
  • •Pushes commits to a remote and creates a pull request, modifying remote state and potentially exposing local changes.
  • •Uses heredocs and shell commands (git, gh, cargo) that execute in the user's environment.

Examples

Named branch
/pr fix-socket-perms
Auto-named branch
Turn my uncommitted changes into a draft PR against iopsystems/rezolus and give me the URL
With linting
Run clippy, tests and fmt on my current rezolus changes, then commit, push and open a draft PR upstream

name: pr description: Create a feature branch, commit changes, push, and open a PR against iopsystems/rezolus

Create a PR from the current uncommitted changes. Handles branching, committing, pushing, and opening the PR against the upstream repo.

Arguments

The skill accepts an optional branch name argument:

  • If provided, use it as the branch name (e.g., /pr fix-socket-perms)
  • If not provided, generate a descriptive kebab-case branch name from the changes

Steps

  1. Verify prerequisites:

    • Working directory must have uncommitted changes (staged or unstaged)
    • Must not already be on a feature branch with unpushed commits for a different change
    git status
    git diff
    git diff --staged
    

    If there are no changes, stop and tell the user.

  2. Analyze the changes:

    • Read the diff to understand what changed
    • Check recent commit messages for style conventions:
      git log --oneline -10
      
  3. Create feature branch:

    • If currently on main, create a new branch:
      git checkout -b <branch-name>
      
    • If already on a feature branch, use the current branch
  4. Sync docs version label (idempotent — runs every PR):

    ./scripts/sync-docs-version.sh
    

    Updates site/docs/*.html's sidebar version label to the latest stable release tag. If it modifies any file, include the change in the same commit. If nothing changes, no-op.

  5. Stage and commit:

    • Stage the relevant changed files by name (avoid git add -A)
    • Write a commit message following the repo's conventional commit style (type(scope): description)
    • Common types: feat, fix, refactor, chore, docs, test
    • Include Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> trailer
    • Use a HEREDOC for the commit message
  6. Push to origin:

    git push -u origin <branch-name>
    
  7. Open PR against upstream:

    • The upstream repo is iopsystems/rezolus
    • The fork remote is origin (determine the owner from git remote -v)
    • Use gh pr create with --repo iopsystems/rezolus and --head <fork-owner>:<branch-name>
    gh pr create \
      --repo iopsystems/rezolus \
      --head <fork-owner>:<branch-name> \
      --draft \
      --title "<conventional commit style title>" \
      --body "$(cat <<'EOF'
    ## Summary
    <1-3 bullet points describing the changes>
    
    ## Test plan
    <bulleted checklist of testing done or needed>
    
    🤖 Generated with [Claude Code](https://claude.com/claude-code)
    EOF
    )"
    
  8. Report the PR URL to the user.

Version bumps

Non-release PRs must never bump the major, minor, or patch version. Instead, bump only the pre-release revision number in Cargo.toml:

  • Format: <major>.<minor>.<patch>-alpha.<revision>
  • Example: 5.8.3-alpha.0 → 5.8.3-alpha.1 → 5.8.3-alpha.2
  • Increment the revision (-alpha.N) by 1 from the current main branch version
  • Check the current main branch version before committing:
    git show main:Cargo.toml | grep '^version'
    

Notes

  • Keep PR titles under 70 characters
  • PR title should follow the same conventional commit format as the commit message
  • If cargo clippy, cargo test, or cargo fmt --check haven't been run yet during this session, run them before committing
  • Never force push or amend existing commits
  • The fork owner can be determined from the origin remote URL (e.g., git@github.com:brayniac/rezolus → brayniac)
  • PRs are created as drafts by default. Mark ready via GitHub UI or gh pr ready
Related skills