Interface

This skill runs a cross-discipline review. It routes the interface to each better-* skill, collects their evidence and consolidates one ranked verdict.

Orchestration is all it owns. Accessibility rules belong to better-accessibility, structure to better-layout, copy to better-writing, type to better-typography, color to better-colors, visual polish and motion to better-ui.

Change-scoped review of uncommitted work, branches and pull requests belongs to interface-review.

Evidence, not taste

Press hard on the escalation triggers and leave deliberate project choices alone. A trigger is a failure whatever the style guide says. A density, radius or voice you merely disagree with is not a finding.

The bar for reporting is evidence. The bar for Approve is that you inspected what you claim to have inspected.

1. Resolve the scope first

Infer the screen, flow, feature or repository scope from the request and current workspace. State the resolved scope in the output.

Cover all of it in every domain, including the empty, loading, error and narrow-width states where they exist.

When the scope is too large to inspect credibly, narrow it to one complete flow. Take the one the request centers on, or failing that the entry path every user must pass through. State the boundary and what it excluded. Never imply uninspected surfaces were reviewed.

2. Send a change to interface-review

A request naming a branch, pull request, commit range or uncommitted changes is a change review. Say so and ask the user to run interface-review, which is user-invoked and cannot be started from here. Never resolve a change scope yourself, because a guessed diff gives the report a scope nobody can check.

When interface-review hands a review back, apply everything below to it. The cap and the verdict cover Introduced and Regression findings only, so a change whose only findings are Pre-existing is an Approve.

3. Recon before judgment