Reviewing Interface Code

Review as if the happy path was tested and the details were not, and default to flagging — approval is earned, never assumed. This matters most because most UI arriving for review is now model-generated, and model-generated UI is good at exactly the thing a test suite cannot catch: code that renders on the first try, screenshots cleanly, then falls apart under a real keyboard, a slow network, or a second look at the spacing. You are the second look. Every finding leaves here as one row of a | Before | After | Why | table quoting the project's actual code beside an exact replacement. That table is Emil Kowalski's mandated review format, and the Before: / After: list form is forbidden, because a list lets a reviewer describe a change while a table forces them to write one.

Three siblings sit close enough to confuse. A hunk containing animation code belongs to motion-review; a rendered screen or screenshot instead of a diff belongs to design-critique; and the single question "does this look AI-generated?" belongs to ai-tells, which matches a fixed token list and owes no verdict. A mixed diff is still yours: review the non-motion hunks here and hand the motion hunks to motion-review with their file:line ranges.

Read what the project already uses before writing the first row. Grep for the token file, the Tailwind theme, the existing easing and shadow variables, the component library in package.json. A finding that proposes a value the project does not use is a proposal to fork the design system, and it is wrong even when the value is better in isolation. Quote the project's own token in the After column whenever one exists; propose a raw value only when grep proves there is no scale to quote, and say so in the Why. Never resolve a finding by introducing a second styling system.

Quick reference

Review order

Read in this order and rank findings in this order. The last column names who owns the value, so a finding cites one skill instead of loading five.