| 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.
-
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>
-
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.
-
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.
-
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.
-
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:
- Create the PR using
gh pr create.
- Provide a concise title (often the commit message) and a body summarizing the changes.
- Execute:
gh pr create --title "<title>" --body "<body>"
- Share the generated PR URL with the user.
- If a PR already exists:
- Do not open a duplicate PR.
- After the push succeeds, add a PR comment containing exactly
/gemini review to trigger the code quality review.
- Execute:
gh pr comment <number-or-url> --body "/gemini review"
- Share the existing PR URL with the user and mention that the review trigger comment was added after pushing the new commit.
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.
