Créer et ouvrir une PR

Crée une branche, commit les changements et ouvre une PR avec gh. Gère le branching, le push et la création de PR en brouillon.

Spar Skills Guide Bot
DeveloppementIntermédiaire
2024/08/2026
Claude Code
#git#pull-request#branching#gh-cli#workflow

Recommandé pour


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.05.8.3-alpha.15.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/rezolusbrayniac)
  • PRs are created as drafts by default. Mark ready via GitHub UI or gh pr ready
Skills similaires