What happened
Warp’s Merge Risk page says developers can run /merge-risk on any pull request to evaluate its alignment with the issue and PR description, its impact, verification, rollback cost and error detection. The five criteria are weighted into an overall merge-risk score intended to direct human attention toward changes that need the most scrutiny. The page does not state a version number or release date for the skill.
The alignment check looks for a match with the issue and PR description, undocumented assumptions and drive-by edits. The impact check considers the change’s blast radius and flags sensitive areas such as authentication, permissions, payments, personally identifiable information, migrations, dependencies and infrastructure. These checks are meant to make scope and risk visible rather than treating every diff as equally consequential.
For verification, the skill checks whether tests cover the relevant behavior and whether user-facing changes have computer-use screenshots or recordings as evidence. Warp says computer use can catch things tests miss and gives an example of a QA agent using a screen reader to find a missing required announcement in a pull request. The page encourages enabling computer use in Warp Factories for this kind of end-to-end proof; it does not describe it as a requirement for running the risk assessment itself.
The rollback criterion distinguishes reversible changes from destructive or hard-to-undo ones. Error detection checks whether logs, monitoring and alerts would expose a failure before users report it. Warp’s example grades a sample pull request as good on alignment, small in impact, poor on verification, low in rollback cost and decent on error detection, producing medium overall risk. Its recommendation is to review verification before merging.
The page offers a “Run the skill” link and a GitHub link, but does not specify the skill’s license, installation steps, supported coding agents, or whether access requires a Warp account. It also describes Warp Factories as an environment for automating software-development workflows, with API, CLI, SDK and MCP integrations, and says early access can be requested. No price for Merge Risk is listed.
What the archive adds
New Runtime has covered an open-source skill that turns photos or shop listings into sliced Bambu Studio projects and a skill for locating photos without GPS or landmarks. Those were task-specific capabilities; Warp’s page is a new event about using a skill to structure software-change review.
Trend signal
This supports the assumption that organizations will keep a named human accountable for releasing agent-produced changes, rather than letting agents merge and deploy on their own: Verification ownership. The risk grade is explicitly framed as a way to focus human attention, not to replace the reviewer’s decision.
Why now
Warp frames the tool around a code-review bottleneck and presents it alongside a discussion of agent verification and PR risk assessment. Its example also points to a specific gap in agent-written changes: passing tests may not establish that a user-facing experience works as intended.
Why it matters
As coding agents produce more pull requests, review capacity can become the limiting step. A consistent set of questions about scope, verification, reversibility and observability may help teams decide where human attention is most valuable, instead of relying on a vague sense that a diff looks safe.
The framework is useful even apart from the score: it makes teams ask whether a change matches the request, whether it touches sensitive paths, what evidence demonstrates behavior, how quickly it can be reversed and how failures will be detected. Those are operational questions teams can build into PR templates and review procedures. But a weighted grade is only a triage aid; it cannot establish correctness by itself. Teams still need to inspect evidence, especially for high-impact or hard-to-reverse changes, and retain clear human ownership of merge decisions.
Limits and uncertainty
Warp’s page does not disclose the weighting formula, how the skill reaches its judgments, or measured accuracy against human review. It does not establish which coding-agent environments can run the skill, and it gives no license terms or installation instructions despite linking to GitHub. The screen-reader example is a company anecdote, not an independently evaluated result. Teams should treat the risk grade as an aid to review, not as proof that a change is safe.
Reader takeaway
The useful idea is the five-part review checklist, not the risk label alone. If your team accepts agent-written pull requests, make verification and rollback evidence explicit, and keep a human responsible for deciding whether each change is ready to merge.
To apply it this week, add impact and rollback-cost fields to a PR template and ask reviewers to attach behavior-level verification for user-facing changes. This creates a small trial without depending on an unverified score: compare the questions it surfaces with the team’s existing review process, and keep the final merge call with the named reviewer.