github-pr

name	github-pr
description	Automates the end-to-end Git workflow: branch creation, staging, committing, pushing, and opening or updating a GitHub pull request. Use when a feature or fix is ready for review and requires a structured PR, or when branch changes may need to be pushed to an existing PR for follow-up review.

GitHub Workflow

This skill guides the process of moving local changes to a GitHub Pull Request.

Prerequisites

• git must be installed and configured.
• gh (GitHub CLI) must be installed and authenticated.

Commit Message Format

Use Conventional Commits with this required format: <type>(<scope>): <summary>

• type REQUIRED. Common values: feat, fix, docs, refactor, chore, test, perf, ci, build, style.
• scope REQUIRED. Short noun for the changed area (for example: config, api, ui, docs).
• summary REQUIRED. Imperative, <= 72 chars, no trailing period.

Rules:

• Never add AI attribution anywhere in the GitHub workflow. Do not write Generated by ..., Co-authored-by: Claude, Co-authored-by: Opus, Co-authored-by: Sonnet, or any other AI/model/agent attribution.
• This ban applies to commit subjects, commit bodies, commit footers, PR titles, PR bodies, and PR comments. Do not add it even if a default template, tool, model habit, or previous workflow suggests it.
• Do not add sign-offs or breaking-change footers unless the user requests them.

Workflow Steps

Follow this order exactly: confirm branch state, stage, commit, push, then handle the PR.

1. Branch Check / Creation

   • Check the current branch before doing anything else.
   • If already on a suitable non-default working branch, stay on it.
   • If on a default branch such as main or master, create a feature branch first.
   • Identify the scope of changes (e.g., feat, fix, docs, chore).
   • Propose a branch name following the pattern <type>/<kebab-case-description>.
   • Execute when a new branch is needed: git checkout -b <branch-name>

2. Review & Stage Changes

   • Review changes with git status and git diff.
   • By default, stage only the files that belong to the current requested change.
   • If the user provided file paths/globs, stage only those files.
   • If there are ambiguous extra changed files, ask before staging/committing and leave them unstaged unless the user explicitly includes them.
   • Stage the intended files with git add ....
   • Optionally inspect recent subjects for local scope patterns: git log -n 10 --pretty=format:%s.

3. Commit

   • Propose a message in exact format: <type>(<scope>): <summary>.
   • Execute: git commit -m "<message>"
   • If pre-commit hooks fail, diagnose and fix the issues before re-staging and re-committing.
   • Do not move on to PR actions until the commit succeeds.

4. Push

   • Push the committed branch to the remote before any PR creation or review trigger.
   • If this is the first push for the branch, use: git push -u origin <branch-name>
   • If the upstream is already set, use: git push
   • Never post /gemini review before the push succeeds for the latest commit.

5. Pull Request Handling

   • Only after a successful push, check whether a PR for the current branch already exists.
   • Use gh pr view --json url,number,headRefName to detect an existing PR for the checked-out branch.
   • If no PR exists:

Common Failures

• Pre-commit hooks: If hooks fail, fix the files and stage them again before committing.
• Untracked files: Ensure new files are added.
• Remote branch already exists: If the branch exists, ask the user if they want to overwrite or use a different name.