pr-creator
npx machina-cli add skill google-gemini/gemini-cli/pr-creator --openclawPull Request Creator
This skill guides the creation of high-quality Pull Requests that adhere to the repository's standards.
Workflow
Follow these steps to create a Pull Request:
-
Branch Management: CRITICAL: Ensure you are NOT working on the
mainbranch.- Run
git branch --show-current. - If the current branch is
main, you MUST create and switch to a new descriptive branch:git checkout -b <new-branch-name>
- Run
-
Commit Changes: Verify that all intended changes are committed.
- Run
git statusto check for unstaged or uncommitted changes. - If there are uncommitted changes, stage and commit them with a descriptive
message before proceeding. NEVER commit directly to
main.git add . git commit -m "type(scope): description"
- Run
-
Locate Template: Search for a pull request template in the repository.
- Check
.github/pull_request_template.md - Check
.github/PULL_REQUEST_TEMPLATE.md - If multiple templates exist (e.g., in
.github/PULL_REQUEST_TEMPLATE/), ask the user which one to use or select the most appropriate one based on the context (e.g.,bug_fix.mdvsfeature.md).
- Check
-
Read Template: Read the content of the identified template file.
-
Draft Description: Create a PR description that strictly follows the template's structure.
- Headings: Keep all headings from the template.
- Checklists: Review each item. Mark with
[x]if completed. If an item is not applicable, leave it unchecked or mark as[ ](depending on the template's instructions) or remove it if the template allows flexibility (but prefer keeping it unchecked for transparency). - Content: Fill in the sections with clear, concise summaries of your changes.
- Related Issues: Link any issues fixed or related to this PR (e.g., "Fixes #123").
-
Preflight Check: Before creating the PR, run the workspace preflight script to ensure all build, lint, and test checks pass.
npm run preflightIf any checks fail, address the issues before proceeding to create the PR.
-
Push Branch: Push the current branch to the remote repository. CRITICAL SAFETY RAIL: Double-check your branch name before pushing. NEVER push if the current branch is
main.# Verify current branch is NOT main git branch --show-current # Push non-interactively git push -u origin HEAD -
Create PR: Use the
ghCLI to create the PR. To avoid shell escaping issues with multi-line Markdown, write the description to a temporary file first.# 1. Write the drafted description to a temporary file # 2. Create the PR using the --body-file flag gh pr create --title "type(scope): succinct description" --body-file <temp_file_path> # 3. Remove the temporary file rm <temp_file_path>- Title: Ensure the title follows the
Conventional Commits format if the
repository uses it (e.g.,
feat(ui): add new button,fix(core): resolve crash).
- Title: Ensure the title follows the
Conventional Commits format if the
repository uses it (e.g.,
Principles
- Safety First: NEVER push to
main. This is your highest priority. - Compliance: Never ignore the PR template. It exists for a reason.
- Completeness: Fill out all relevant sections.
- Accuracy: Don't check boxes for tasks you haven't done.
Source
git clone https://github.com/google-gemini/gemini-cli/blob/main/.gemini/skills/pr-creator/SKILL.mdView on GitHub Overview
This skill helps you create pull requests that conform to repository templates and standards. It covers branch management, template usage, preflight checks, and proper PR description and title conventions to ensure consistency and quality.
How This Skill Works
Following the workflow, it first ensures you are not on main, prompting a branch switch or creation if needed. It then verifies commits, locates and reads the PR template, drafts a description that follows the template structure, performs a preflight check, pushes the branch, and finally creates the PR using the gh CLI with a body file.
When to Use It
- When you are asked to open a pull request for new changes
- When collaborating on features or bug fixes that require adherence to a PR template
- When you must verify branch safety and avoid pushing to main
- When multiple PR templates exist and you need to select the most appropriate one
- When you need to link related issues in the PR description
Quick Start
- Step 1: Confirm you are NOT on main; if on main, create a descriptive branch (e.g., git checkout -b feature/awesome-improvement)
- Step 2: Stage and commit changes with a descriptive message (git add .; git commit -m "type(scope): description")
- Step 3: Locate and read the PR template, draft a description, run npm run preflight, push the branch, then create the PR with gh pr create --body-file <temp_file>
Best Practices
- Never commit directly to main; always create and switch to a descriptive feature branch
- Use descriptive branch names and verify the current branch before pushing
- Stage and commit all intended changes with a clear, conventional message
- Read and strictly follow the PR template; complete checklists and fill content precisely
- Link related issues and format the PR title in Conventional Commits style if required
Example Use Cases
- fix(auth): resolve token refresh crash and add retry logic
- feat(ui): implement dark mode toggle and user preference persistence
- docs(readme): clarify setup and contribution guidelines
- refactor(core): optimize state management for perf improvements
- chore(test): add test coverage for PR workflow and preflight