Review interfaces across design disciplines

Better Interface coordinates a cross-discipline interface review and consolidates the evidence into one ranked verdict. It owns orchestration rather than the individual design rules. Accessibility, layout, writing, typography, colors, and visual polish each remain the responsibility of their corresponding better-* skill.

The review follows that order so foundational failures are considered before polish. Each owning skill contributes its principles, references, and verification checks, while Better Interface supplies the shared severity scale and consolidated reporting structure. If a required skill is unavailable, its domain is marked Not reviewed instead of being reconstructed from memory.

Use it for a screen, flow, feature, or repository interface review within an authorized scope. The resolved scope must be stated, and each domain should cover relevant empty, loading, error, and narrow-width states. If the requested area is too broad to inspect credibly, the workflow narrows to one complete flow and explicitly records exclusions.

Requests about a branch, pull request, commit range, or uncommitted work are directed to interface-review. That change-review skill is user-invoked. When it hands results back, Better Interface applies its cap and verdict to Introduced and Regression findings; pre-existing findings alone do not prevent approval.

The workflow distinguishes demonstrable failures from differences in taste. A documented project convention can settle a stylistic preference, but it cannot excuse a confirmed accessibility or usability trigger. Reviews are read-only unless implementation is also requested.

The review begins with project reconnaissance: framework, styling system, component library, design tokens, supported viewports, and preview or test commands. It also checks available contribution instructions, coding standards, design-system documentation, Storybook material, and interface decisions. Proposed fixes must fit the project's existing stack and conventions.

Each finding cites a file and line and shows the current implementation. Runtime or visual claims require rendered inspection when behavior determines the result. A check that cannot be run is recorded as Not verified, rather than converted into a finding. Approval requires actual inspection of the coverage claimed.

Findings use HIGH, MEDIUM, and LOW severity based on user impact. HIGH covers blocked tasks, misleading behavior, hidden controls, data-loss risk, and repeated systemic failure. Confirmed escalation triggers include missing accessible names or visible keyboard focus, pointer-only paths, ignored reduced-motion preferences, clipping at 320px or 200% zoom, contrast failures, color-only meaning, inaccessible truncated values, unclear recovery paths, and destructive actions lacking distinct treatment or recovery safeguards.

Within severity, systemic reach matters: a shared-token or component fix outranks an isolated symptom. One root cause becomes one finding with all confirmed locations. The consolidated table is capped at 15 findings, with triggers listed first and any excluded trigger count disclosed. The report does not pad toward that cap.

Fix proposals follow an explicit cost order: delete unnecessary elements, use native platform behavior, reuse existing project primitives, correct an existing value, then add something new. A needless wrapper or token is therefore challenged before proposing more structure.

The output follows review-format.md and includes scope, coverage, findings, verification, and a verdict. If implementation is authorized, the consolidated findings define its scope and relevant verification is rerun afterward.

The orchestration depends on better-accessibility, better-layout, better-writing, better-typography, better-colors, and better-ui. Project-provided checks and rendered browser inspection supply evidence where available. Authorized Figma or browser connections may send requested design or page data to their configured service.

Verification remains limited by available browser, assistive-technology, and design tools. Source inspection alone cannot establish visual coverage or conformance. The workflow uses synthetic fixtures and keeps publication, form submission, external contact, spending, and deployment outside the review unless separately authorized.