Gemini

Chapter 10 of 24

PR Creator

Use this skill when asked to create a pull request (PR). It ensures all PRs follow the repository’s established templates and standards.

2 minutes · 372 words · 3 sections

Pull 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 main branch.
- 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>
```
Commit Changes: Verify that all intended changes are committed.
- Run git status to 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"
```
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.md vs feature.md).
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 preflight
```
If 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 gh CLI 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 (opens in a new tab) format if the repository uses it (e.g., feat(ui): add new button, fix(core): resolve crash).

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.

Install this repository

$ npx skills add google-gemini/gemini-cli

Skills install per repository, not per chapter — the CLI has no documented per-skill form, so we do not print one.

Colophon for this issue

Colophon

How this issue was made

Source

github.com/google-gemini/gemini-cli, branch main, last pushed 10 August 2026.

Licence

Apache-2.0 — the text of every chapter is reproduced unmodified, frontmatter included, under the upstream licence.

Discovery

24 chapters found by walking the repository tree for SKILL.md, not by matching a directory convention. 5 distinct layouts observed: .gemini/skills/*/SKILL.md, packages/core/src/skills/builtin/*/SKILL.md, packages/sdk/test-data/skills/*/SKILL.md, tools/caretaker-agent/cloudrun/triage-worker/.gemini/skills/*/SKILL.md, tools/gemini-cli-bot/.gemini/skills/*/SKILL.md.

Issue colours

Resolved from a curated brand profile — hue 288°, chroma 0.190. Two accent tones are generated per issue and each is proven against its own ground before it ships: a single accent that passes AA on both light and dark paper is arithmetically impossible.

Heading repairs

1 repair applied to this chapter so the document has one h1 and no skipped levels:

Shifted “3 headings” from h1 to h2 so the chapter title is the only h1.

Spec compliance

2 editorial notes across 2 of 24 chapters. They are printed in the margin of each chapter rather than as errors here.

Code Explorer — 1 note
Spec Generator — 1 note

Images

Images inside a chapter come from the upstream repository. Where the author gave no alternative text we mark the image decorative rather than inventing a description — a plausible caption we made up is worse than none for the reader who depends on it.

Signal

Install counts come from skills.sh. They measure downloads, not quality, and an unranked repository is not an unread one.

Agent surfaces

The whole issue is available as one markdown document at /google-gemini/gemini-cli.md, and each chapter at its own .md URL.

Publication

Set by Skills Docs from the source repository. Body text is Literata at the reader’s chosen size and measure; code is Geist Mono. Nothing on this page was written by us except this paragraph.

Pull Request Creator

This skill guides the creation of high-quality Pull Requests that adhere to the repository’s standards.

Follow these steps to create a Pull Request:

Branch Management: CRITICAL: Ensure you are NOT working on the main branch.

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>
```

Commit Changes: Verify that all intended changes are committed.

Run git status to 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"
```

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.md vs feature.md).

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 preflight

If 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 gh CLI 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 (opens in a new tab) format if the repository uses it (e.g., feat(ui): add new button, fix(core): resolve crash).

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.