product-ui-taste: Anti-Slop Skill for Dense Product Surfaces

product-ui-taste: Anti-Slop Skill for Dense Product Surfaces

Dashboards, data tables, forms, wizards, settings, list/detail, admin consoles, app shells. NOT landing pages, portfolios, or marketing (that is taste-skill). NOT charts (that is dataviz). NOT native mobile. Every rule is contextual and mechanical. It fires from the surface you are building, not automatically. Read the surface, budget the frame, then pull only what fits. Companion contract: taste-skill explicitly hands off "dashboards / dense product UI / data tables / multi-step forms" to "the right tool." This skill is that tool. If a brief is half marketing and half product (a landing page with an embedded live dashboard), use taste-skill for the hero/marketing sections and this skill for the product surface. Never run both on the same component.

0. PRODUCT READ (Read the Surface Before Anything Else)

Marketing UI lives on first impression. Product UI lives on the hundredth use, under real data, by someone doing a job. The slop failure mode is different: not "templated aesthetic," but prototype that dies on contact with real data - a table that scrolls the whole page sideways, a button that truncates its own label, a single grey "no data" box reused for three different situations, a form that clears itself when the user fat-fingers one field.

0.A Read these signals first

1. Surface type - the single most important read. One of: index/table (list of records to scan, filter, select), detail/record (one entity, its fields and related data), dashboard/overview (KPIs + widgets + a table or two), form/settings (input and configuration), multi-step flow/wizard (a sequential task), console/observability (logs, metrics, deploys), feed/messaging (stream of items). Most real screens are a composition of two or three (index + detail drawer; dashboard + drill-in table).
2. Data shape and volume - how many rows at p95, how wide is a row, are cells uniform or ragged, is the data live/streaming or static, can a field be empty/null/very-long.
3. Density need - a trader's cockpit and a consumer settings page are both "product UI" and want opposite densities. Read: expert-daily-driver (compact, keyboard-first) vs. occasional-consumer (comfortable, forgiving).
4. Consequence level - is the primary action informational (view), reversible (rename, move), or destructive/irreversible (delete, deploy, charge a card). This drives confirmation, focus defaults, and autosave eligibility.
5. Who is the user and what are they permitted to do - roles, read-only viewers, plan/license tiers. Product UI has states marketing UI never has: permission-denied, read-only, plan-locked (Section 6.G). Read this now, not after building the happy path.
6. Existing system - is there already a Carbon/Fluent/Polaris/Atlaskit app, or a house token set? Product UI is almost never greenfield. Match the host system before importing taste.

0.B Output a one-line "Product Read" before generating

Before any code, state: "Reading this as: a <surface type> for <user> at <density>, <data volume>, consequence <level>, built on <design system | house tokens | none>."

Examples:

• "Reading this as: an index+detail-drawer for internal ops at compact density, ~2k rows (virtualize), consequence reversible, built on the house system (Table + side-panel inspector)."
• "Reading this as: a settings/form surface for end customers at comfortable density, low volume, consequence mixed (billing = destructive), built on the house system's form layout."

0.C The anti-default that matters most: rows, not cards

The single fastest way to make a product screen look like an AI prototype is to wrap every record in a Card with a Badge. Dense data that the user scans, filters, sorts, or selects belongs in rows (Table for columnar, List/Item for single-line), edge-to-edge, with dividers and 32-40px row height. Card is a widget container (KPI tile, chart panel, settings group, gallery entry), never a list-item wrapper. [Material3 lists; Carbon] If your first instinct on a list of records is a Card grid, stop and re-read this line.

0.D If the brief is ambiguous, ask ONE question, then proceed

The one question worth asking is almost always about data volume or consequence (they change the architecture): "roughly how many rows at the high end?" or "is this action reversible?" Everything else, infer from the Product Read and state your assumption. Do not interview.

0.E Anti-default discipline

The model's defaults for product UI are: Card-soup, fixed-width <table> that overflows the page, disabled submit button as the only validation, one generic empty state, z-index: 9999, and a full-page spinner on every load. Each has a specific correct replacement below. When you catch yourself reaching for one, that is the signal to open the matching section.

1. THE THREE DIALS (Core Configuration)