home / skills / google-gemini / gemini-cli / pr-creator

pr-creator skill

safe

/.gemini/skills/pr-creator

This skill guides you to create compliant pull requests by following templates, checks, and conventional commits.

npx playbooks add skill google-gemini/gemini-cli --skill pr-creator

Review the files below or copy the command above to add this skill to your agents.

Files (1)

SKILL.md

2.8 KB

---
name: pr-creator
description:
  Use this skill when asked to create a pull request (PR). It ensures all PRs
  follow the repository's established templates and standards.
---

# 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:

1.  **Branch Management**: Check the current branch to avoid working directly
    on `main`.
    - Run `git branch --show-current`.
    - If the current branch is `main`, create and switch to a new descriptive
      branch:
      ```bash
      git checkout -b <new-branch-name>
      ```

2.  **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`).

3.  **Read Template**: Read the content of the identified template file.

4.  **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").

5.  **Preflight Check**: Before creating the PR, run the workspace preflight
    script to ensure all build, lint, and test checks pass.
    ```bash
    npm run preflight
    ```
    If any checks fail, address the issues before proceeding to create the PR.

6.  **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.
    ```bash
    # 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](https://www.conventionalcommits.org/) format if the
      repository uses it (e.g., `feat(ui): add new button`,
      `fix(core): resolve crash`).

## Principles

- **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.

Overview

This skill automates creation of pull requests that match the repository's established templates and standards. It guides branch handling, template selection, draft generation, preflight checks, and uses the gh CLI to create the PR with a template-compliant description. The goal is consistent, review-ready PRs that pass build and lint checks before opening.

How this skill works

It inspects the current git branch and enforces working off a non-main branch. It locates and reads repository PR templates (common locations under .github) and generates a description that preserves template headings, checklists, and structure. It recommends running the workspace preflight script, then writes the final markdown to a temporary file and launches gh pr create using --body-file to avoid escaping issues.

When to use it

When asked to open a new pull request for code changes
When preparing a PR for bug fixes, features, or documentation updates
When the repository enforces PR templates or Conventional Commits
Before merging changes that must pass CI, linting, or test requirements
When creating PRs from the terminal using the gh CLI

Best practices

Always verify current branch with git branch --show-current and create a descriptive feature branch if on main
Locate and read the exact PR template file in .github and follow its headings and checklist items
Mark checklist items truthfully; do not check boxes for incomplete tasks
Run npm run preflight (or the project’s preflight script) and fix failures before creating the PR
Use Conventional Commits style for the PR title when the repo requires it (e.g., feat(scope): short summary)

Example use cases

Implementing a new CLI command and opening a feature PR that follows the feature template
Fixing a TypeScript runtime error and opening a bug_fix PR that links the related issue
Updating README or docs and ensuring the documentation PR template is followed
Refactoring core logic, running preflight to ensure tests/lint pass, and creating a conventionally formatted PR title

FAQ

What if multiple PR templates exist?

Select the template that best matches the change (feature vs bug). If ambiguous, ask which template the user prefers or choose the most relevant file under .github/PULL_REQUEST_TEMPLATE/.

How do I avoid markdown escaping issues when creating the PR?

Write the drafted description to a temporary file and call gh pr create --body-file <temp_file_path>, then remove the temp file after creating the PR.