create-pr
starsforks
How to install create-pr?
warpdotdev/common-skills/create-pr
$npx -y skills add warpdotdev/common-skills --skill create-prCreate 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.
SKILL.md
| 1 | # create-pr |
| 2 | |
| 3 | ## Overview |
| 4 | |
| 5 | This guide covers best practices for creating pull requests in the warp repository, including merging master, running presubmit checks, linking Linear tasks, ensuring appropriate test coverage, and structuring your PR for effective review. |
| 6 | |
| 7 | ## Related Skills |
| 8 | |
| 9 | - `fix-errors` - Fix presubmit failures (formatting, linting, tests) before opening PR |
| 10 | - `warp-integration-test` - Add or update integration coverage for user-visible flows, regressions, and P0 use cases |
| 11 | - `add-feature-flag` - Gate changes behind feature flags |
| 12 | |
| 13 | ## Pre-PR Checklist |
| 14 | |
| 15 | ### 1. Merge master into your feature branch |
| 16 | |
| 17 | **Always merge master into your feature branch before starting the review process.** |
| 18 | |
| 19 | ```bash |
| 20 | git fetch origin |
| 21 | git merge origin/master |
| 22 | ``` |
| 23 | |
| 24 | Resolve any merge conflicts locally before opening the PR. |
| 25 | |
| 26 | ### 2. Run presubmit checks for code changes |
| 27 | |
| 28 | If the PR includes code changes, run the relevant presubmit checks before opening or updating it: |
| 29 | |
| 30 | ```bash |
| 31 | ./script/presubmit |
| 32 | ``` |
| 33 | |
| 34 | `./script/presubmit` runs: |
| 35 | - `cargo fmt` - Code formatting |
| 36 | - `cargo clippy` - Linting with all warnings as errors |
| 37 | - All tests (unit, doc, and integration) |
| 38 | If the PR is documentation-only (for example, skills, markdown, or other non-code content), you do not need to run `cargo fmt` or `cargo clippy` just to open or update the PR. |
| 39 | |
| 40 | If presubmit fails for a code-changing PR, use the `fix-errors` skill to resolve issues. |
| 41 | |
| 42 | **You must run `cargo fmt` and `cargo clippy` before:** |
| 43 | - Opening a new PR that includes code changes |
| 44 | - Pushing new commits that include code changes to an existing PR branch |
| 45 | - Any reviewed branch update that changes code |
| 46 | |
| 47 | ### 3. Review your changes |
| 48 | |
| 49 | Before creating a PR, review what changes you're about to submit: |
| 50 | |
| 51 | ```bash |
| 52 | # View commits in your branch (comparing against base branch) |
| 53 | git --no-pager log <base-branch>..HEAD --oneline |
| 54 | |
| 55 | # View file statistics for changes |
| 56 | git --no-pager diff <base-branch>...HEAD --stat |
| 57 | |
| 58 | # View full diff |
| 59 | git --no-pager diff <base-branch>...HEAD |
| 60 | ``` |
| 61 | |
| 62 | This helps you: |
| 63 | - Verify all intended changes are included |
| 64 | - Catch unintended changes before review |
| 65 | - Write an accurate PR description |
| 66 | - Ensure you're comparing against the correct base branch |
| 67 | - **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. |
| 68 | |
| 69 | ### 4. Link to Linear task |
| 70 | |
| 71 | When possible, PRs should be associated with a Linear task. Use the Linear MCP tool (if available) to find corresponding issues. |
| 72 | |
| 73 | **Branch naming convention:** |
| 74 | Remote branches should be prefixed with your name (e.g., `zheng/feature`, `alice/fix-bug`). |
| 75 | |
| 76 | **How to link PRs to Linear:** |
| 77 | Include the issue ID in the PR title (e.g., `[WARP-1234] Add new feature`). Do this **before** creating the PR for automatic linking. |
| 78 | |
| 79 | ### 5. Open the PR |
| 80 | |
| 81 | Use the PR template at `.github/pull_request_template.md` when opening PRs. |
| 82 | |
| 83 | Add changelog entries when appropriate using the format at the bottom of the PR template. Some examples: |
| 84 | - Feature: "Global search in files across your current directories. Use CMD-F/CTRL-SHIFT-F to open." |
| 85 | - Improvement: "Added horizontal autoscrolling when jumping to line/column." |
| 86 | - Bug fix: "Fixed session viewer input being cleared when agent runs commands. |
| 87 | |
| 88 | **CLI workflow:** |
| 89 | |
| 90 | - **Check if PR exists** for current branch: |
| 91 | ```bash |
| 92 | gh pr view --json number,url |
| 93 | ``` |
| 94 | Exit code 0 if PR exists, 1 if not. |
| 95 | |
| 96 | - **Create a new PR:** |
| 97 | ```bash |
| 98 | # With title and body |
| 99 | gh pr create --title "Title" --body "Description" --draft |
| 100 | |
| 101 | # Auto-fill from commits |
| 102 | gh pr create --fill --draft |
| 103 | |
| 104 | # Use PR template file |
| 105 | gh pr create --body-file .github/pull_request_template.md --title "Title" --draft |
| 106 | ``` |
| 107 | Key flags: `--draft` / `-d`, `--fill` / `-f`, `--body-file` / `-F`, `--web` / `-w` |
| 108 | |
| 109 | - **Update an existing PR:** |
| 110 | ```bash |
| 111 | gh pr edit --title "New title" --body "New body" |
| 112 | gh pr edit --add-reviewer username --add-label bug |
| 113 | ``` |
| 114 | |
| 115 | - **Mark PR ready for review:** |
| 116 | ```bash |
| 117 | gh pr ready |
| 118 | ``` |
| 119 | |
| 120 | ### 6. Include co-author attribution |
| 121 | |
| 122 | When committing changes or creating a PR, include attribution at the end of every commit message or PR description: |
| 123 | |
| 124 | ``` |
| 125 | Co-Authored-By: Warp <agent@warp.dev> |
| 126 | ``` |
| 127 | |
| 128 | ## Testing Requirements |
| 129 | |
| 130 | ### Bug fixes require regression tests |
| 131 | |
| 132 | **All bug fixes should be accompanied by a regression test.** This helps prevent re-breaking something that was already broken once. |
| 133 | |
| 134 | The test should: |
| 135 | - Reproduce the original bug (would fail before the fix) |
| 136 | - Pass after the fix is applied |
| 137 | - Be clearly named to indicate what bug it's preventing |
| 138 | |
| 139 | ### Algorithmic code requires unit tests |
| 140 | |
| 141 | Code with non-trivial logic should have unit tests to validate functionality: |
| 142 | |
| 143 | **Examples of what needs unit tests:** |
| 144 | - Custom |
People who liked this also viewed
6 picksType
- caveman-commitUltra-compressed commit message generator. Cuts noise from commit messages while preserving intent and reasoning. Conventional Commits format. Subject ≤50 chars, body only when "why" isn't obvious. UsSkillsJul 2026
- git-guardrails-claude-codeSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026
- setup-pre-commitSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026
- resolving-merge-conflictsSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026
- using-git-worktreesUse when starting feature work that needs isolation from current workspace or before executing implementation plans - ensures an isolated workspace exists via native tools or git worktree fallbackSkillsJul 2026
- finishing-a-development-branchUse when implementation is complete, all tests pass, and you need to decide how to integrate the work - guides completion of development work by presenting structured options for merge, PR, or cleanupSkillsJul 2026
