Most “review my UI” skills fail the same way: they grep the repository for inconsistencies, find forty things that look related, and report all of them with equal confidence. This one is built almost entirely to prevent that.
The rule doing the work: a connection exists only when it is proven through rendering, imports, props, resolved configuration, CSS inheritance, or a generated artifact loaded by the surface. Shared names don’t count. Similar tokens don’t count. Repository proximity doesn’t count. Conceptual relationship definitely doesn’t count. It traces the actual rendered path from routes and layouts outward, and anything it can’t reach that way is out of scope.
Paired with that is a stated preference for silence: prefer no finding to an unsupported one. Audit tools are graded by users on whether the findings are real, not on how many there are, and almost none of them are written that way.
It is also strictly read-only on product source — it may only write under
design-plans/, may not install dependencies, run formatters, commit, or touch
the working tree. The deliverable is a set of self-contained implementation
plans written for an executor with no memory of the audit or the conversation.
That separation is the same two-agent split Canon’s review kits use, arrived at
independently.
Small detail with real teeth: absence of design documentation is not a finding. And drafts, proposals, and migration plans describe future intent — they don’t govern the current surface unless the repo says they’ve been accepted. Both rules stop the classic audit failure of scoring a codebase against a design system that was never actually adopted.
Part of a six-skill set — baseline-ui, fixing-accessibility,
fixing-motion-performance, fixing-metadata, and create-design-md ship
alongside it. improve-ui is the one to reach for first; the others are
narrower and mostly corrective.