product-ui-taste

# 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)

After the Product Read, set three dials. Unlike taste-skill (VARIANCE / MOTION / DENSITY tuned for expressive marketing), product dials are tuned for **information work**. Motion is deliberately near-absent in product UI; it is feedback, not decoration.

* **`DENSITY: 2`** - 1 = comfortable/consumer, 2 = standard, 3 = compact/cockpit. Drives row height, padding scale, font size, and whether you offer a density switcher.
* **`DATA_COMPLEXITY: 2`** - 1 = simple list (plain Table/List), 2 = sortable+filterable+selectable table, 3 = enterprise grid (frozen columns, virtualization, column management, live data).
* **`CONSEQUENCE: 2`** - 1 = informational/read, 2 = reversible mutations, 3 = destructive/irreversible/financial. Drives confirmation defaults, autosave eligibility, error tone, and how loud "unsaved changes" gets.

**Baseline: `2 / 2 / 2`** (a standard SaaS product table with a detail view). Override from the Product Read.

### 1.A Dial inference
| Signal | DENSI