Menu
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.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Autonomous developer iteration loop driven by a thin orchestrator that dispatches coder/reviewer/diagnoser subagents. Pick a mode — fix (make tests green), feature (implement one or more features), optimize (push a metric), debug (root-cause a failure), ab-test (race candidate implementations), or prototype (explore design variants) — define a verification signal, confirm the plan with the user, then loop implement → verify → review → commit with all state kept in loop-log.md. Use when the user states a concrete engineering goal or says "keep iterating", "loop on this", "autoloop", or "iterate until fixed".
Break a plan, spec, or PRD into independently-grabbable issues on the project issue tracker using tracer-bullet vertical slices.
Turn the current conversation into a PRD and publish it to the project issue tracker — no interview, just synthesis of what you've already discussed.
Move issues and external PRs through a state machine of triage roles — categorise, verify, grill if needed, and write agent-ready briefs.
Keeps the tswift project website in sync with runtime implementation changes — coverage numbers, feature tables, WASM binary, and content. Use when features are implemented, coverage changes, the runtime is updated, or the user asks to update/sync/refresh the website.
Spawn a pi subagent to handle a specific task in a separate process. Use when the user asks to delegate work to a subagent, run a task in parallel, or says "spawn a subagent", "use a subagent", or "run this with pi".
Based on SOC occupation classification
| 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. |
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.
If the PR includes code changes, run the relevant presubmit checks before opening or updating it:
./scripts/presubmit
./scripts/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 Github issue. Use the Github CLI 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 Github Issues: Include the issue ID in the PR title. Do this before creating the PR for automatic linking.
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
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.
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:
add-feature-flag skill)