القائمة
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.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
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 — when invoked fresh, e.g. "/readout on how github webhook events are processed" — by sharpening scope with clarifying questions and researching the codebase before documenting. The work runs in a child agent so the main conversation's context stays clean. Use whenever the user invokes /readout, says "write this up", "turn this into a doc/page", "make a readout", or asks for a readable, shareable document capturing findings or explaining how something works.
Scan warpdotdev/warp and warp-server for recently merged PRODUCT.md specs that don't yet have a corresponding docs PR in warpdotdev/docs. When a complete spec is found, auto-generates a full docs draft PR and tags the engineer. When a spec is too thin to draft from, pings the engineer directly. Designed to run as a scheduled Oz ambient agent (e.g., every 2-3 days). Use when setting up the automated docs trigger or running a manual docs coverage sweep.
Draft a complete documentation page for a new Warp feature from its PRODUCT.md and/or TECH.md spec. Use when an engineer has written a spec and needs to produce a first-pass MDX draft for the warpdotdev/docs repo. Also handles features without specs by researching the codebase first. Invoke this skill whenever an engineer mentions writing docs for a feature, drafting a docs page, creating feature documentation, starting the eng-docs workflow, or converting a spec into documentation. Works from warp-internal or warp-server.
Run an autonomous, spec-driven development "saga" for medium-to-large features using an orchestrator agent and a fleet of worker subagents. Use this skill whenever the user invokes /saga, asks to autonomously build a sizable feature end-to-end with minimal human intervention, wants a comprehensive spec broken into milestones and tasks with airtight validation criteria before parallelized implementation, or wants an orchestrator to delegate implementation to worker agents while preserving its own context window. Trigger on phrases like "run a saga", "autonomously implement this feature", "spec it out then build it with subagents", "orchestrate this big feature end-to-end", or "build this with workers and validate each step". Also use this skill when asked to continue, resume, or pick up an existing saga from its saga directory (e.g. under ~/.sagas).
Run a second round on a contested question by circulating each subagent's independent proposal to the other authors and asking for structured pros and cons, then synthesize. Use this skill whenever you have multiple independent proposals or opinions on a contested decision — architecture tradeoffs, code review disagreements, design choices, competing root-cause theories — and want sharper analysis than you'd produce by synthesizing alone. Pairs naturally with the council and research skills; reach for it liberally whenever proposals diverge.
Delegate noisy investigation to one or more subagents so the orchestrator's context stays clean, then work from the distilled answer. Use this skill whenever answering a question would require reading many files, long logs, large diffs, or wide codebase surveys — i.e. when producing the answer generates far more noise than the answer itself. Use it for "how does X work", "where is Y used", "what's the root cause of Z", "summarize this PR/log" style questions, and reach for it liberally before reading a pile of files inline.
استنادا إلى تصنيف SOC المهني
| 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. |
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.
fix-errors - Fix presubmit failures (formatting, linting, tests) before opening PRwarp-integration-test - Add or update integration coverage for user-visible flows, regressions, and P0 use casesadd-feature-flag - Gate changes behind feature flagsAlways 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.
If the PR includes code changes, run the relevant presubmit checks before opening or updating it:
./script/presubmit
./script/presubmit runs:
cargo fmt - Code formattingcargo clippy - Linting with all warnings as errorscargo fmt or cargo clippy just to open or update the PR.If presubmit fails for a code-changing PR, use the fix-errors skill to resolve issues.
You must run cargo fmt and cargo clippy before:
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:
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.
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:
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
When committing changes or creating a PR, include attribution at the end of every commit message or PR description:
Co-Authored-By: Warp <agent@warp.dev>
All bug fixes should be accompanied by a regression test. This helps prevent re-breaking something that was already broken once.
The test should:
Code with non-trivial logic should have unit tests to validate functionality:
Examples of what needs unit tests:
SumTree)Not required for:
Follow the repository's local testing conventions for guidance on writing unit 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
});
})
}
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 PRNo, continue without an integration testIf the user chooses to add one, use the warp-integration-test skill.
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:
integration/ directoryUse the warp-integration-test skill for implementation details, test registration steps, and validation workflow.
Your PR summary under the "Description" section should include:
cargo fmt/cargo clippy (and other relevant checks); for documentation-only changes, this is not required.add-feature-flag skill)