Pull request design checks

Pull request checks catch design drift before it merges. Each check is static: it reads only the lines a pull request adds, never runs the code, and compares them with your design system.

What is checked

Rule	Flags
off-theme-color	A colour that isn't in your palette.
off-scale-spacing	Spacing outside your spacing scale.
off-scale-typography	Type sizes or styles outside your type scale.
reimplemented-component	New code that rebuilds a component you already have.
low-contrast	Text and background colours below the contrast minimum.
missing-state	UI that leaves out a state the screen needs.

Results

Each pull request gets a verdict: Failing, Needs attention or Pass (Pass · no UI changes when no UI files changed). With the GitHub App's Checks permission the result is a check run named M1rror design check, with up to 50 notes on the changed lines and a link back to M1rror; without it, M1rror posts one pull request comment and updates it in place.

In M1rror, results are under Code mode › Pull requests, with Check again and Open pull request on GitHub.

Approved release coverage

When a pull request implements an approved release (one M1rror opened, one an agent linked, or one whose description contains an M1rror-Release: line), the report adds an Approved release coverage section: that release's counts and which of its approved items this pull request changes. It uses the same changed files as Ship › Coverage, so the two always agree. No extra check run is created.

Settings

On the Pull requests tab:

• Check pull requests automatically: on by default.
• Treat failing checks as blocking: off by default. When it's on, a failing verdict gives the M1rror design check run a failure conclusion, which blocks a merge only if your branch protection requires that check. A comment can never block a merge.
• Check draft pull requests: off by default.

Pull request checks need the M1rror GitHub App.

Cost

Each check uses 1 usage unit. On the Explore plan checks are capped at 20 a month.