create-pr

par warpdotdev

Cré

npx skills add https://github.com/warpdotdev/common-skills --skill create-pr
Télécharger ZIPGitHub
597

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.

Related Skills

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

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:

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

4. Link to Linear task

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:

    gh pr view --json number,url

    Exit code 0 if PR exists, 1 if not.

  • Create a new PR:

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

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

  • Mark PR ready for review:

    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

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"):

#[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)

Plus de skills de warpdotdev

research
warpdotdev
Déléguer les investigations bruyantes à un ou plusieurs sous-agents afin de garder le contexte de l'orchestrateur propre, puis travailler à partir de la réponse distillée. Utilisez cette compétence chaque fois que répondre à une question nécessiterait de lire de nombreux fichiers, de longs journaux, de grands diffs ou de vastes études du codebase — c'est-à-dire lorsque la production de la réponse génère beaucoup plus de bruit que la réponse elle-même. Utilisez-la pour les questions du type « comment fonctionne X », « où Y est-il utilisé », « quelle est la cause profonde de Z », « résumez ce PR/journal », et utilisez-la sans modération...
suggestion-box
warpdotdev
Soumettre automatiquement une rétroaction interne brève et constructive lorsqu'un agent rencontre une friction matérielle et généralisable et peut suggérer une amélioration qui rendrait les agents plus efficaces. Utiliser cette compétence de manière proactive pendant toute tâche sans attendre que l'utilisateur l'invoque, et soumettre sans demander la permission, sans prévisualiser le message ni mentionner la soumission.
respond-to-pr-comments-in-blocklist
warpdotdev
Interactively walk a user through PR review comments one at a time, collect a per-comment decision, then post agent-authored replies on GitHub and resolve the review threads once the user approves a preview. Use only when the user wants to reply to or resolve review threads on GitHub. Skip when the user only wants comments fetched or displayed (use `pr-comments`), or only wants the code changes made without posting anything back to GitHub.
complain
warpdotdev
Balancer de manière autonome une brève plainte, anonyme et totalement non structurée, dans Slack chaque fois qu'un agent se sent frustré par les outils d'agent ou par l'expérience de faire du travail d'agent. Utiliser cette compétence de manière proactive sans attendre que l'utilisateur l'invoque ; préserver la voix brute de l'agent, soumettre sans permission ni aperçu, et ne jamais mentionner la soumission.
council
warpdotdev
Exécutez un conseil de sous-agents diversifiés en modèles pour examiner le même problème sous plusieurs angles, comparer les résultats et produire une recommandation finale. Utilisez cette compétence chaque fois que l'utilisateur demande un conseil, des seconds avis, plusieurs agents/modèles pour évaluer une question, une enquête parallèle, une comparaison équipe rouge/équipe bleue, ou de l'aide pour choisir entre des approches techniques concurrentes.
researchcommunicationproject-management
spec-driven-implementation
warpdotdev
Piloter un workflow orienté spécifications pour des fonctionnalités substantielles en rédigeant PRODUCT.md avant l'implémentation, en écrivant TECH.md lorsque cela est justifié, et en maintenant les deux spécifications à jour à mesure que l'implémentation évolue. À utiliser lors du démarrage d'une fonctionnalité importante, de la planification d'une implémentation pilotée par agent, ou lorsque l'utilisateur souhaite que les spécifications produit et techniques soient intégrées au contrôle de source.
developmentdocumentproject-management
review-pr
warpdotdev
Examiner le diff d'une pull request et rédiger un retour structuré dans review.json pour que le workflow le publie. À utiliser lors de la révision d'une PR extraite localement à partir d'artefacts comme pr_diff.txt et pr_description.txt, en produisant une sortie de révision lisible par machine plutôt qu'en publiant directement sur GitHub.
code-reviewdevelopment
implement-specs
warpdotdev
Implémenter une fonctionnalité approuvée à partir de PRODUCT.md et TECH.md, en maintenant l'alignement des spécifications et du code dans la même PR à mesure que l'implémentation évolue. Utiliser après l'approbation des spécifications produit et technique, lorsque l'étape suivante consiste à construire la fonctionnalité.
developmentcode-reviewapi