Design Taste Pro

Ask an agent for a dashboard and you get a screen that demos well and fails on the first real day: a KPI card that repeats the header, a total that disagrees with its own rows, a list laid out for five items, tinted icon chips on every card, glass on everything, and a scroll bar on the monitor it was built for. Ask it to review one and it flags your 10 px section labels as an accessibility failure while missing that the on-time rate is typed in.

Free taste skills are good at landing pages. This one is for product screens: the ones people use every day, with real data, at every size the data comes in.

Seven laws, each with a check.

1. The user's work is the brightest thing on screen.
2. One number, one source: every value computed, the same metric agrees everywhere.
3. A fact is told once.
4. Colour only where it means something, and data colour is not status colour.
5. The screen survives any N: zero, one, typical, ten times typical, long names.
6. Controls sit next to what they affect.
7. Restraint is not absence: after the decoration goes, the screen still says whose it is, answers the question people open it for, and shows that answer as a figure, not a diagram of how the system works.

Settled arguments instead of folklore. WCAG as written (24 px targets at AA, 3:1 for large text, disabled controls exempt), not "44 px and 4.5:1 for everything". When glass is right and when it is a grey fill. When uppercase labels, dot lists and a coloured domain glyph are fine. A screen-type guide for dashboards, pro tools, device control, money, AI studios and multi-product shells.

Native iOS with SwiftUI and Liquid Glass (iOS 26 and later, tested on iOS 27). Native controls before custom ones, Liquid Glass on the layer above content and nowhere else, bars that carry navigation only, one icon family (custom SF Symbols for objects the library lacks), sheets that don't stack, empty states the platform's way. The Liquid Glass snippets compile with Xcode 27.

Proof, not "looks good". The build loop renders every target viewport in both themes and measures them:

• render.mjs: screenshots plus the checks below, per viewport and theme;
• measure.js: contrast per text style per surface, targets, type sizes in use;
• layout-check.js: overflow, clipped text, dead zones, uneven columns, a monitor screen that stops at two thirds;
• slop-scan.js: the markers of generated-looking UI, counted before and after;
• swiftui-scan.mjs: SwiftUI patterns to look at (glass on content, global appearance proxies, white on adaptive ink, a shape inside a bar button's glass, mixed icon families).

Reviews a team can act on. It starts from the jobs people open the product for, walks each one through the screens, holds them against the leading apps in the category, taps every element and tries the device. Every finding has evidence, a confidence level (confirmed, likely, question) and a severity. A critique of one widget is treated as a class: it finds every instance and fixes them in one pass. Product decisions come with a proposed default, marked as an assumption.

Four modes: Build a new screen, Review an existing one, Refine after a critique, or Transfer: work inside someone else's design system without repainting it.