mcpbeat Sign in

Pr Creator Agent Skill

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

925 tokens
context cost
the whole folder, loaded on every use
1
files
instructions only
0
copies elsewhere
how many repositories repackaged it
106350
stars on the repo
on the repository, not the skill itself

Install

one command, takes just this skill from the repository
npx skills add https://github.com/google-gemini/gemini-cli --skill pr-creator

The instruction itself

3 sections, as written by the author

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

Other skills for the same job

different authors, same section of the catalogue
Receiving Code Review
by ZhanlinCui
×7

Use when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical rigor and verification, not performative agreement or blind implementation

2k tokens
Requesting Code Review
by ZhanlinCui
×6

Use when completing tasks, implementing major features, or before merging to verify work meets requirements

2k tokens
Git Commit
by github
vendor ×3

Execute git commit with conventional commit message analysis, intelligent staging, and message generation. Use when user asks to commit changes, create a git commit, or mentions "/commit". Supports: (1) Auto-detecting type and scope from changes, (2) Generating conventional commit messages from diff, (3) Interactive commit with optional type/scope/description overrides, (4) Intelligent file staging for logical grouping

799 tokens
Github Code Review
by ComeOnOliver
×3

Comprehensive GitHub code review with AI-powered swarm coordination

13k tokens
Karpathy Guidelines
by hyyhf
×3

Behavioral guidelines to reduce common LLM coding mistakes. Use when writing, reviewing, or refactoring code to avoid overcomplication, make surgical changes, surface assumptions, and define verifiable success criteria.

629 tokens
Agent MD Refactor
by softaworks
×2

Refactor bloated AGENTS.md, CLAUDE.md, or similar agent instruction files to follow progressive disclosure principles. Splits monolithic files into organized, linked documentation.

4k tokens
Commit Work
by softaworks
×2

Create high-quality git commits: review/stage intended changes, split into logical commits, and write clear commit messages (including Conventional Commits). Use when the user asks to commit, craft a commit message, stage changes, or split work into multiple commits.

2k tokens
Gemini
by softaworks
×2

Use when the user asks to run Gemini CLI for code review, plan review, or big context (>200k) processing. Ideal for comprehensive analysis requiring large context windows. Uses Gemini 3 Pro by default for state-of-the-art reasoning and coding.

5k tokens

How to use it

Copy the folder

Take google-gemini/pr-creator from the repository into ~/.claude/skills for personal use, or into .claude/skills inside a project.

Check the name does not clash

The agent identifies a skill by the name field in its header. Two skills with the same name cannot sit side by side — one of them will be ignored.