New: 97,000+ skills indexed from GitHub repos with 100+ stars · every skill safety-checkedBrowse top skillsTop skills
Esc to closeBrowse all skills
Submit a skillBrowse skills
Submit a skillBrowse skills

Agent skill

Create PR

by warpdotdev in warpdotdev/common-skills

Create a pull request in the warp repository for the current branch.

MITAuto-check passedDevelopment

Install Create PR

skills CLI
$ npx skills add warpdotdev/common-skills --skill create-pr -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install warpdotdev/common-skills create-pr --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/warpdotdev/common-skills.git skills-src && mkdir -p .claude/skills && cp -r skills-src/.agents/skills/create-pr .claude/skills/create-pr && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
create-pr
GitHub stars
606
Token cost
~2.2k tokens
SKILL.md length
1,015 words
Files
1
Skills in repo
28
Repo updated
First seen
Licence
MIT

At a glance

Create a pull request in the warp repository for the current branch.

  • Works in 6 steps: Merge master into your feature branch → Review your changes → Respect implementation agent validation → …
  • The user mentions opening a PR
  • SKILL.md covers Overview, Related Skills, Pre-PR Checklist and Testing Requirements, plus 3 more sections
  • Calls gh and git

What it does

Create PR is an agent skill from warpdotdev/common-skills. Create a pull request in the warp repository for the current branch. Use when the user mentions opening a PR, creating a pull request, submitting changes for review, or preparing code for merge.

Its SKILL.md is about 2.2k tokens, which your agent loads only when the skill is triggered. It is a single SKILL.md file with no bundled scripts.

It sits in Development, covering Pull requests. The licence is MIT.

When your agent uses it

  • The user mentions opening a PR
  • Creating a pull request
  • Submitting changes for review
  • Preparing code for merge

Example prompts

  • “/create-pr”

Workflow steps

6 steps, taken from the step headings in SKILL.md.

  1. Merge master into your feature branch
  2. Review your changes
  3. Respect implementation agent validation
  4. Link to Linear task
  5. Open the PR
  6. Include co-author attribution

What it can do on your machine

Read from SKILL.md and the folder at commit 69b4753. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    Shell commands in SKILL.md call:

    • gh
    • git

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md. Its commands use gh and git, which can reach the network depending on how they are called.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Create PR loads about 2.2k tokens when it runs. Until then it costs about 51 tokens; SKILL.md has 1,015 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~51
When it runs · the whole SKILL.md, loaded when a task matches
~2.2k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from warpdotdev/common-skills at commit 69b4753, republished under its MIT licence (© warpdotdev). 1,015 words, ~2,176 tokens.

Download SKILL.mdSave it as .claude/skills/create-pr/SKILL.md (or your agent's skills folder).
name
create-pr
description
Create a pull request in the warp repository for the current branch. Use when the user mentions opening a PR, creating a pull request, submitting changes for review, or preparing code for merge.

create-pr

Overview

This guide covers best practices for creating pull requests in the warp repository, including merging master, validating changes efficiently, linking Linear tasks, ensuring appropriate test coverage, and structuring your PR for effective review.

  • write-pr-description - Write the PR body itself: template sections, prose, and reviewer guidance
  • fix-errors - Fix targeted compilation, test, lint, or formatting failures before opening a PR
  • warp-integration-test - Add or update integration coverage for user-visible flows, regressions, and P0 use cases
  • add-feature-flag - Gate changes behind feature flags

Pre-PR Checklist

1. Merge master into your feature branch

Always merge master into your feature branch before starting the review process.

bash
git fetch origin
git merge origin/master

Resolve any merge conflicts locally before opening the PR.

2. Review your changes

Before creating a PR, review what changes you're about to submit:

bash
# View commits in your branch (comparing against base branch)
git --no-pager log <base-branch>..HEAD --oneline

# View file statistics for changes
git --no-pager diff <base-branch>...HEAD --stat

# View full diff
git --no-pager diff <base-branch>...HEAD

This helps you:

  • Verify all intended changes are included
  • Catch unintended changes before review
  • Write an accurate PR description
  • Ensure you're comparing against the correct base branch
  • Tests: Include tests when required—bug fixes (regression test), algorithmic code (unit tests), UI components (layout test), P0 use cases (integration test). See Testing Requirements below.
3. Respect implementation agent validation

PR creation is not a validation boundary. If the implementation workflow already completed its tests, lint checks, and final formatting pass and the candidate has not changed, do not rerun them.

If merging master or preparing the PR changed source, tests, manifests, generated code, or configuration, validate the new candidate in this order:

  1. Run the relevant tests and fix the code until they pass.
  2. Run the applicable Clippy and other lint, typecheck, or build checks and fix their findings. Return to affected tests only when a fix materially changes behavior.
  3. Run ./script/format once after all other code changes are complete.

Do not rerun tests or lint after formatting, and do not run ./script/presubmit, unless the user, task, or approved spec explicitly requires it. CI owns uncommon failures outside targeted local coverage. Documentation-only changes do not require Rust tests, Clippy, or formatting.

When possible, PRs should be associated with a Linear task. Use the Linear MCP tool (if available) to find corresponding issues.

Branch naming convention: Remote branches should be prefixed with your name (e.g., zheng/feature, alice/fix-bug).

How to link PRs to Linear: Include the issue ID in the PR title (e.g., [WARP-1234] Add new feature). Do this before creating the PR for automatic linking.

5. Open the PR

Use the PR template at .github/pull_request_template.md when opening PRs.

Add changelog entries when appropriate using the format at the bottom of the PR template. Some examples:

  • Feature: "Global search in files across your current directories. Use CMD-F/CTRL-SHIFT-F to open."
  • Improvement: "Added horizontal autoscrolling when jumping to line/column."
  • Bug fix: "Fixed session viewer input being cleared when agent runs commands.

CLI workflow:

  • Check if PR exists for current branch:

    bash
    gh pr view --json number,url

    Exit code 0 if PR exists, 1 if not.

  • Create a new PR:

    bash
    # With title and body
gh pr create --title "Title" --body "Description" --draft

# Auto-fill from commits
gh pr create --fill --draft

# Use PR template file
gh pr create --body-file .github/pull_request_template.md --title "Title" --draft

    Key flags: --draft / -d, --fill / -f, --body-file / -F, --web / -w

  • Update an existing PR:

    bash
    gh pr edit --title "New title" --body "New body"
gh pr edit --add-reviewer username --add-label bug

  • Mark PR ready for review:

    bash
    gh pr ready
6. Include co-author attribution

When committing changes, include attribution as a trailer at the end of the commit message only — never in the PR description — and never add a second Warp/Oz co-author trailer if the commit already has one:

Co-Authored-By: Warp Agent <agent@warp.dev>

Testing Requirements

Bug fixes require regression tests

All bug fixes should be accompanied by a regression test. This helps prevent re-breaking something that was already broken once.

The test should:

  • Reproduce the original bug (would fail before the fix)
  • Pass after the fix is applied
  • Be clearly named to indicate what bug it's preventing
Show full SKILL.md (422 more words)Show less
Algorithmic code requires unit tests

Code with non-trivial logic should have unit tests to validate functionality:

Examples of what needs unit tests:

  • Custom data structures (e.g., SumTree)
  • Search-related APIs that should return expected results for a given query
  • Core layout code in the UI framework
  • Any algorithmic or computational logic

Not required for:

  • Sufficiently-simple functions
  • Trivial getters/setters

Follow the repository's local testing conventions for guidance on writing unit tests.

UI components need layout validation tests

All UI components (implementations of View) should have a simple unit test to validate that they can be laid out without a panic.

This provides high-level coverage over rendering "safety" (though not "correctness"):

rust
#[test]
fn test_component_can_layout() {
    use warpui::App;
    use warp::test_util::{terminal::initialize_app_for_terminal_view, add_window_with_terminal};
    
    App::test((), |mut app| async move {
        initialize_app_for_terminal_view(&mut app);
        let term = add_window_with_terminal(&mut app, None);
        
        // Render the component - should not panic
        term.update(&mut app, |view, ctx| {
            // Create and layout your component
        });
    })
}
Ask before skipping integration coverage

If the PR changes a user-visible flow, fixes an end-to-end regression, or otherwise looks like it would benefit from integration coverage, use the ask_user_question tool before creating or updating the PR to ask whether the user wants an integration test added as part of the work.

Prefer a direct choice such as:

  • Yes, add an integration test before creating the PR
  • No, continue without an integration test

If the user chooses to add one, use the warp-integration-test skill.

P0 use cases require integration tests

All "P0 use cases" require an integration test that covers the behavior/flow in question.

A "P0 use case" is defined as: Any behavior of the application that, if broken, warrants an out-of-band release.

Integration tests should:

  • Exercise the full user-facing flow
  • Validate end-to-end functionality
  • Be placed in the integration/ directory

Use the warp-integration-test skill for implementation details, test registration steps, and validation workflow.

PR Description Guidelines

Use the write-pr-description skill for the body itself. It covers following the repository's template, the prose baseline, and when to add a reading order and focus areas for the reviewer.

After Opening the PR

  1. Monitor CI checks - Ensure all automated checks pass
  2. Respond to review comments - Address feedback promptly
  3. Keep the PR up to date - Merge master if conflicts arise
  4. Validate changed candidates - After code changes from review feedback, run affected tests, then lint checks, then ./script/format once. Do not repeat validation for PR metadata or an unchanged candidate.

Best Practices

  • Keep PRs focused - One logical change per PR when possible
  • Write clear commit messages - Explain what and why, not just what
  • Self-review first - Review your own diff before requesting review
  • Update tests - Ensure test coverage reflects your changes
  • Document breaking changes - Call out any API changes or breaking modifications
  • Use feature flags - Gate risky changes behind feature flags when appropriate (see the add-feature-flag skill)

© warpdotdev, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

Just SKILL.md in .agents/skills/create-pr of warpdotdev/common-skills.

Open the folder on GitHubat commit 69b4753

Compare with similar skills

Create PR next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Create PR compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Create PR this skillwarpdotdev/common-skills606—~2.2kAutomated safety check: PassMIT
PR Babysitteropeninterpreter/openinterpreter69k3 repos~4.2kAutomated safety check: PassApache-2.0
Iterate PRmeshery/meshery-operator1517 repos~2.2kAutomated safety check: PassApache-2.0
Simple Issue Descriptionevery-app/open-seo23k1 repos~1.2kAutomated safety check: PassMIT
Tabularis Local PR ReviewTabularisDB/tabularis5.1k—~1.4kAutomated safety check: PassApache-2.0
Docs AuthoringTracecatHQ/tracecat3.8k—~3.1kAutomated safety check: NotesAGPL-3.0

Similar skills

  • PR Babysitter

    openinterpreter/openinterpreter

    Watches an open GitHub pull request until it merges, handling review comments, diagnosing CI failures and retrying flaky checks along the way.

    69k GitHub starsUsed in 3 repos~4.2k tokens
    DevelopmentAuto-check passed

  • Iterate PR

    meshery/meshery-operator

    Iterate on a PR until CI passes. An agent skill from meshery/meshery-operator.

    151 GitHub starsUsed in 7 repos~2.2k tokens
    DevelopmentAuto-check passed

  • Simple Issue Description

    every-app/open-seo

    Turn a rough bug report, feature request, support note, or pull request into a short, plain-language issue focused on the problem and desired behavior.

    23k GitHub starsUsed in 1 repo~1.2k tokens
    DevelopmentAuto-check passed

  • Tabularis Local PR Review

    TabularisDB/tabularis

    Reviews a Tabularis pull request locally, judging the diff against the repo's rule files, verifying every claim in its description against the code, and running its tests on the real branch.

    5.1k GitHub stars~1.4k tokensUpdated yesterday
    DevelopmentAuto-check passed

  • Docs Authoring

    TracecatHQ/tracecat

    A skill your agent uses when adding or updating documentation pages in an existing docs site.

    3.8k GitHub stars~3.1k tokensUpdated today
    DevelopmentAuto-check: notes

  • MAUI PR Performance Analysis

    dotnet/maui

    Official

    Interprets pinned managed benchmark evidence for a dotnet/maui pull request and writes a narrative for the performance review workflow, without running or publishing anything.

    23k GitHub stars~2.4k tokensUpdated today
    DevelopmentAuto-check passed

More from warpdotdev/common-skills

All 28 skills in this repo

  • Skill Doctor

    warpdotdev/common-skills

    Grades agent skills by scoring agent conversations for efficiency, code quality, procedure compliance, and verbosity, then drafts concrete skill edits and a shareable report.

    606 GitHub starsUsed in 2 repos~2.6k tokens
    Auto-check passed

  • Readout

    warpdotdev/common-skills

    Produce a polished, self-contained HTML "readout" document under ~/.readouts (with an auto-maintained index page), either by snapshotting the findings accumulated in the current conversation or —…

    606 GitHub stars~2k tokensUpdated 6 days ago
    Auto-check passed

  • Resolve Merge Conflicts

    warpdotdev/common-skills

    Resolve Git merge conflicts by extracting only unresolved paths, conflict hunks, and compact diffs instead of loading whole files into context.

    606 GitHub stars~733 tokensUpdated 6 days ago
    Auto-check passed

  • Review PR

    warpdotdev/common-skills

    Review a pull request diff and write structured feedback to review.json for the workflow to publish.

    606 GitHub stars~2.6k tokensUpdated 6 days ago
    Auto-check passed

  • Saga

    warpdotdev/common-skills

    Run an autonomous, spec-driven development "saga" for medium-to-large features using an orchestrator agent and a fleet of worker subagents.

    606 GitHub stars~4.1k tokensUpdated 6 days ago
    Auto-check passed

  • PR Walkthrough

    warpdotdev/common-skills

    Generate a static interactive D3 walkthrough of a pull request.

    606 GitHub starsUsed in 1 repo~7.2k tokens
    Auto-check passed

Categories

Questions about Create PR

What does Create PR do?

Create a pull request in the warp repository for the current branch. Create PR is an agent skill from warpdotdev/common-skills. Create a pull request in the warp repository for the current branch.

When should I use Create PR?

Create PR fits situations like: the user mentions opening a PR; creating a pull request; submitting changes for review; preparing code for merge.

How do I install Create PR in Claude Code?

Run `npx skills add warpdotdev/common-skills --skill create-pr -a claude-code`. Or copy the skill folder (.agents/skills/create-pr in warpdotdev/common-skills) into .claude/skills/create-pr in your project. Claude Code loads it when a task matches its description.

How do I install Create PR in Codex?

Run `npx skills add warpdotdev/common-skills --skill create-pr -a codex`. Or copy the skill folder (.agents/skills/create-pr in warpdotdev/common-skills) into .agents/skills/create-pr in your project. Codex loads it when a task matches its description.

Can I use Create PR in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add warpdotdev/common-skills --skill create-pr -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/create-pr, .gemini/skills/create-pr, .github/skills/create-pr and .opencode/skills/create-pr in your project.

What does Create PR need to run?

Going by SKILL.md and its folder, Create PR needs the command-line tools its instructions call (gh and git).

Does Create PR access the network?

SKILL.md contains no URLs. Its commands use gh and git, which can reach the network depending on how they are called. This is read from the text; nothing was executed.

Is Create PR safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Create PR use?

Create PR is published under the MIT licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Create PR use?

About 2.2k tokens (SKILL.md is roughly 8.7k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to Create PR?

Skills that share tags, products or a category with Create PR: PR Babysitter (openinterpreter/openinterpreter, 69k stars), Iterate PR (meshery/meshery-operator, 151 stars), Simple Issue Description (every-app/open-seo, 23k stars) and Tabularis Local PR Review (TabularisDB/tabularis, 5.1k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Create PR?

warpdotdev (a GitHub organization) maintains it in warpdotdev/common-skills, which has 606 GitHub stars. The repository holds 28 skills in this directory. The repository was last updated on September 30, 2026.

Source: warpdotdev/common-skills on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.