Créer une pull request avec Git et gh

VérifiéPrudence

Automatise la création d’une branche, le commit, le push et l’ouverture d’une pull request en brouillon sur iopsystems/rezolus via gh.

Spar Skills Guide Bot
DeveloppementIntermédiaire
0018/10/2026
Claude Code
#git#pull-request#github-cli#conventional-commits#branching

Recommandé pour

Notre avis

Automatise le cycle complet de création d'une pull request pour le dépôt iopsystems/rezolus : branche, commit, push et ouverture d'un PR draft.

Points forts

  • Enchaîne toutes les étapes git et gh (branche, commit, push, PR) à partir de modifications non commitées
  • Applique les conventions du dépôt : messages de commit conventionnels, synchro du label de version dans la doc, incrément du numéro alpha dans Cargo.toml
  • Vérifie les prérequis (diff non vide, branche courante) et lance clippy/test/fmt si nécessaire
  • Crée les PR en mode draft avec un corps structuré (résumé + plan de test)

Limites

  • Fortement couplé au dépôt iopsystems/rezolus, à son script scripts/sync-docs-version.sh et à son schéma de version alpha
  • Suppose une configuration fork/origin avec gh authentifié et le remote upstream accessible
  • Ne gère ni la mise à jour d'un PR existant, ni les conflits de fusion, ni les force push (volontairement)
  • Pas de possibilité de fournir un corps de PR personnalisé au-delà du modèle
Quand l'utiliser

Quand vous avez des modifications non commitées dans un checkout de rezolus et souhaitez ouvrir rapidement une PR draft vers le dépôt upstream.

Quand l'éviter

À éviter sur un autre dépôt que rezolus, ou lorsque vous devez modifier un PR existant, réécrire l'historique ou résoudre des conflits.

Analyse de sécurité

Prudence
Score qualité88/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.

Points d'attention
  • •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.

Exemples

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
Skills similaires