warpdotdev / common-skills

brandalf

Anything that carries the Warp or Oz name is made to the company's own brand rules, pulled fresh from the brand site each time instead of recalled from memory.

check-impl-against-spec

Compares what a pull request actually built against the plan that was approved for it, and raises only the differences big enough to matter.

council

A second, third and fourth opinion on one hard call: several different AI models investigate the same question separately, and their answers are compared to produce one recommendation.

create-pr

Opens the pull request for your branch in Warp's codebase, once the groundwork is done: your branch brought up to date, the tests that kind of change requires, and the tracking ticket linked.

cross-critique

A second round for a decision people disagree on: each author reads the rival proposals and argues their strengths and weaknesses, so the final call rests on more than your own reading of the reports.

diagnose-ci-failures

Works out why the automated checks on a pull request are failing, reading the build logs, sorting the errors by kind and naming the cause of each one.

fix-errors

Gets Warp's Rust code building and passing its checks again, taking the compiler errors, style warnings and failing tests one kind at a time.

implement-specs

Builds a feature from the written plan that was already signed off, and keeps that plan updated as the code changes, so the two ship together instead of drifting apart.

pr-walkthrough

A clickable map of a pull request, built as a small local web page, so a reviewer can get their bearings in an unfamiliar part of the codebase before reading the diff.

reproduce-bug-report

Hands a reported bug to a cloud agent that opens the app, tries the steps itself and records the screen, so you can see for yourself whether the bug is real.

research

Sends the heavy digging through files, logs and long diffs to a separate helper, which reports back just the answer and where it found it, so the main assistant's memory stays clear.

resolve-merge-conflicts

Clears up the clashes Git reports when two sets of changes touch the same lines, showing only the few lines actually in dispute rather than the whole file.

respond-to-pr-comments-in-blocklist

Goes through a reviewer's comments on your code with you one at a time, makes the changes you agree to, and posts the replies back on GitHub only after you have seen a preview of every one.

review-pr

Reads the changes in a pull request and writes up a full review: an overall verdict, a summary, and comments pinned to the exact lines that need attention.

saga

Hands a whole feature over to a crew of AI workers and keeps the person out of it except at three moments — approving the plan, answering something the plan cannot, and accepting the finished result.

scan-new-specs

spec-driven-implementation

Big features get thought through in writing before anyone starts coding them.

update-skill

Writing a skill file for this project, to the same naming, description and layout pattern the existing ones already follow.

validate-changes-match-specs

Reads the spec a change promised to deliver, then walks you through every place the code does something else — fixing either side is your call.

write-feature-docs

An engineer who just shipped a feature gets a first-draft help page out of it, filed for the docs team to review.

write-product-spec

Pins down how a feature should behave for the person using it, down to the edge cases, so nobody has to guess the intent later.

write-tech-spec

Researches the code a feature has to fit into, then writes the plan for building it — with links to the exact lines it was based on.