How it works

From pull request to a decision you can trust

Open or update a pull request and ShipWright takes it from there. In a few minutes, the PR has a review, a verdict and the evidence behind it.

01
Map the change
ShipWright reads the diff and the files around it, then classifies the change and gives it a risk tier from T0 (trivial) to T3 (high risk).
02
Plan the checks
It builds a bounded verification plan for that risk: which tests, static analysis, dependency and policy checks to run, within a fixed cost cap.
03
Review the code
Reviewers read the change and flag real problems on the exact lines. Large diffs are split and reviewed in parallel, then merged without duplicates.
04
Challenge its own findings
An adversarial pass tries to disprove each finding, so you get fewer comments and more of them are worth fixing.
05
Recommend
You get a clear verdict, ship or don’t ship, with the evidence behind it: check results, logs and the reasoning, kept for audit.

What shows up on your pull request

A ShipWright / release-recommendation check with the verdict, so it can gate your merge like any other CI check.

Findings on the lines they’re about, with the severity, the impact and a suggested fix.

One sticky comment per PR that updates as you push, instead of a new wall of text every time.

A replayable record of what ran, what it found and why it decided, for when someone asks later.

Every pass or fail comes from a real command with hashed logs. The model can’t mark its own homework.

Each run has a hard budget. When it’s reached, ShipWright falls back to its deterministic checks instead of failing open.

Read access to code, write access only to checks and comments. It never pushes, merges or deploys.

We onboard teams in small batches. Request an invite and we'll be in touch.