finesse-ui — скилл для Claude Code: интерфейсы без AI-слопа

---
name: finesse-ui
description: 'Build and refine high-craft web interfaces: brand sites, product dashboards and workflows, AI workbenches, commerce, H5/mobile screens, and individual components. Route by purpose, preserve project identity, and audit visual quality, accessibility and motion. Supports Apple-inspired / 苹果风 design through editorial, app and spatial modes with runnable card studies. Use for landing pages, portfolios, dashboards, admin panels, settings, agent consoles, product pages, checkout, mobile app UI, design-system extraction, redesign, typography, color, layout, animation, drag/swipe/sheet interactions and anti-generic iteration. Includes targeted audit, bolder, quieter, soul, diverge, animate, depth, densify, init and document workflows. Excludes backend-only tasks.'
version: 0.22.0
user-invocable: true
argument-hint: "[craft · audit · bolder|quieter|soul|diverge · animate|depth|densify · redesign · init|document] [target]"
license: MIT
metadata:
  short-description: Craft interfaces that never look cheap
---

# finesse — Technically Spectacular · Soul-Distinct · Never Cheap

> **finesse builds two kinds of interface and routes by register (§0):**
> - **brand** — design IS the product: landing pages, brand sites, launches, portfolios, hero pages. Optimize for **spectacle + soul + first impression** — a real visual engine, an opinionated personality.
> - **product** — design SERVES the product: dashboards, admin panels, analytics, data tables, app shells, settings. Optimize for **clarity + density + usability** — and still never cheap.
>
> The through-line is identical: **high craft, zero AI-slop.** What applies to **both** is the **universal craft floor** (tinted neutrals, no `#fff`/`#000`, translucent/hairline borders, tinted shadows, contrast floors), the cheapness blacklist (§6), and the pre-flight (§8). What **forks** is the *substrate above that floor* and the middle: **brand** lays the §3 brand substrate (`design-dna.md` — grain, vignette, display type) and reaches for a hero engine (§4); **product** lays its **own** substrate (`product-ui.md` §0 — surfaces, cards, KPI tiles, density) and reaches for a component system + data viz. A dashboard is a **different design language**, not a brand page with charts — it does **not** inherit grain / vignette / giant hero type / dark-default / a hero engine.
>
> **Two more registers sit alongside them, and they work differently from each other.** **commerce** (PDP/PLP/cart/checkout) is a *hybrid* — route it to brand or product by what the specific page is doing. **h5** (phone-only screens: app UI, 活动页, mobile PDP, report H5) is a **container**: it fixes the frame, the safe areas, the thumb hierarchy, and the OS furniture, then wraps one of the other three for the content grammar underneath. A mobile PDP is `h5` + `commerce`; an app dashboard screen is `h5` + `product`. h5 never replaces a content register — it wraps one.
>
> Every rule below is **contextual**. Nothing fires automatically. Read the brief, set the register, then pull only what fits. A skill that produces the same page for every brief has failed.

---

## Apple design language (optional)

For Apple style / 苹果风, read `references/apple-design.md` before choosing the substrate or persona. Keep the existing register, add `design-language=apple` and choose `apple-mode=editorial|app|spatial`. Its scoped overrides take precedence over conflicting aesthetic defaults below, including pure-black/white bans, mandatory grain/vignette, extreme leading and forced persona/engine rotation. Functional and accessibility gates still apply. Component requests retain component scope. Editorial recipes and seven runnable studies are indexed in `references/apple-patterns.md`.

## How to use this skill

0. **Check the scope before anything else.** If the brief is a **single element** — a button, an input, a card, a modal, a toast — go to `references/component-scope.md` and follow it instead; steps 1–6 below are page apparatus and are wrong for one component. Detection and the ambiguity question live in that file.
1. Run **§0 Brand Read** — read `.finesse/log.json` (the rotation memory, `divergence.md` §4), then infer **register** (brand vs product) + soul before touching code. Output the Design Read: the coordinate line, **a plain `You'll see:` line the user can actually veto**, the **`Images:` line naming every slot a picture would carry and where it would come from**, its two most likely objections, and the rotation as a sentence (§0.B). Before writing that `Images:` line, **check this session's actual tool list** — an image-gen tool, an MCP image tool, a network fetch, or none — because it decides what you can honestly offer (`asset-sourcing.md` §1), and **prove the one you're about to name actually runs here** before naming it (§1.1 — listed is not usable; a generator with no credential is not Path A). Offer it and **wait**; never generate or download off your own inference.
2. Set the **§1 Three Dials** (SOUL · SPECTACLE · DENSITY). Product register pins SPECTACLE low, DENSITY high.
3. **Lay the substrate — the right one for the register.** All share the **universal craft floor** (tinted neutrals, no `#fff`/`#000`, translucent/hairline borders, tinted shadows, contrast floors — `references/design-dna.md` §1). Above that floor the substrate forks:
   - **brand** → the **§3 brand substrate** (`references/design-dna.md`): grain, vignette, `clamp()` display type, dark-default, layered hero depth.
   - **product** → the **product substrate** (`references/product-ui.md` §0): premium surfaces/cards, KPI tiles, floating panels, fixed type scale, feedback-only motion. **Never** pour grain / vignette / giant hero type / dark-default / a hero engine into a dashboard — that's brand grammar, not product grammar.
   - **h5** → the **frame comes first** (`references/h5-mobile.md` §1): the viewport contract, the locked `body` + scrolling `#app`, the 560px desktop phone frame, then the safe-area math (§2). Only after the frame is standing do you lay the substrate of the register it wraps.
4. **Then the paths fork further:**
   - **brand** → pick a **§2 Soul** (`references/style-personas.md`) and build **one §4 Hero Engine** (`references/hero-engines.md`).
   - **product** → **pick a palette from `references/product-palettes.md` first** (the neutral ramp is 80% of the pixels; skipping this step is how every dashboard comes out blue). Then split by the page's job:
     - **pages you read** — dashboards, analytics, monitoring → `references/product-ui.md` (density, tables, charts, interaction states). **Before writing, open the closest dashboard in `examples/`** (index: `examples/EXAMPLES.md`) to see `product-ui.md` §0 applied in shipped code — lift patterns, not whole files.
     - **pages you operate** — publish/create wizards, merchant & admin consoles, config, settings, review queues → `references/workflow-ui.md` **on top of** `product-ui.md` (workflow shell, numbered sections, radio-card choices, live preview, pre-submit check, derived totals, draft/commit). There is **no form-workflow page in `examples/`** — build from the reference, and do **not** force-fit a dashboard example onto a form.
     - **pages you delegate on** — AI 工作台, agent consoles, copilot UI, anything where something *other than the user* does work over a duration → `references/ai-console.md` **on top of** `product-ui.md` (three tenses on one screen, the run stream, nine run states, a resident stop, the in-stream approval card, cost as a receipt). Open `examples/relay-agent-console.html`. A dashboard fails by being unreadable and a console by being unfinishable; **this one fails by being untrustworthy**, and none of the dashboard parts address that.
   - **h5** → pick one of the **six morphologies** (`h5-mobile.md` §4: app shell · paged deck · snap narrative · commerce stack · longform site · ambient screen), then load the **content register it wraps** and follow that bullet above. Build the native furniture from `h5-mobile.md` §5 rather than inventing it — a TabBar is a convention, not a design opportunity.
5. **Assemble the skeleton — again, the right one for the register.** **brand** → pick one of the four **§5 brand skeletons** (landing · portfolio · lookbook · studio) by what the page has to *do*. **product** → the skeleton is the **shell morphology** in `product-ui.md` §1 (sidebar · floating panel · bento · triptych …), **not** §5. **h5** → the skeleton is the frame (§1) plus the chosen morphology (§4); §5's brand skeletons and `product-ui.md` §1's desktop shells are both wrong inside 390px. Motion-motivated only, in all three.
6. Run the **§6 Cheapness Blacklist** (`references/anti-cheap.md`), the **mobile floor** (`references/mobile-floor.md`), and **§8 Pre-Flight** (`references/preflight.md`) before shipping. **h5 builds run `h5-mobile.md` §9–§10 instead of the mobile floor** — the notch/frame/scroll/touch gates, which are a different set of failures from "a desktop page reaching a phone". Then **record the build** — append to `.finesse/log.json` and stamp the CSS (`divergence.md` §4.3). An unrecorded build is one the next run will collide with.

The `references/*.md` files are the deep material. Load the one you need for the current phase — do not inline all of them.

| Reference | When to load |
|-----------|-------------|
| `apple-design.md` | Explicit Apple / 苹果风 requests: mode routing, scoped overrides, typography, surfaces and materials |
| `apple-patterns.md` | Apple editorial cards, Bento, contrast, spacing, corners and galleries; seven runnable studies |
| `component-scope.md` | **Before the Brand Read, when the brief is one element, not a page** — a button, an input, a card, a modal. Routes to the component flow: keeps the register + craft floor + existing tokens, skips the skeleton / hero engine / rotation, and enforces the one gate that decides whether a component is well-made — **all eight states shipped**, plus a preview file that makes them visible instead of claimed |
| `divergence.md` | **At §0, before the Design Read — the anti-sameness layer.** Load it when output keeps converging, when the user says "feels generic / like every other AI site", or before *any* soul decision: the five-axis composition method (compose a soul, don't select one from a list), the anti-default two-altitude check, the die roll that breaks the model's argmax, and the assert-then-confirm direction proposal. **§4 is the memory** — `.finesse/log.json` + the CSS stamp, with a defined read step (§0) and write step (§8); without it "don't repeat" is a rule with nothing behind it. **Read its §0 register boundary first** — divergence is a goal for brand and a *bounded* tactic for product (never diverge on dashboard navigation conventions) |
| `design-dna.md` | Laying the **brand** substrate (grain, vignette, display type, color tokens, palette families). Product/dashboard inherits only its **universal craft floor** (§1: tinted neutrals, translucent borders, contrast floors) — the surfaces/cards/type/motion of a dashboard come from `product-ui.md` §0, not here |
| `theming.md` | Brief asks for a light/dark toggle or multiple swappable named themes — the token-role and hardcoded-color pitfalls of a runtime palette switch (not the single-locked-palette default) |
| `motion.md` | **Any brief that mentions motion — 动效 · 炫酷 · "make it move" · "有动画" — and every `brand` build.** The motion layer above the engines: the two axes nobody separates (**EFFECT** what's seen vs **ROUTE** how it's built), the **six routes** with their weight, their still form and their failure mode (CSS · native scroll-driven · View Transitions/WAAPI · GSAP · Canvas/WebGL · zero-dep CSS 3D space), a **ten-family effect catalogue** with ~80 variants and each family's *slop form*, the **effect → route lookup** that stops the model reaching for 60KB to do four lines of work, and the **beat sheet** that replaces "one hero engine + generic fade-ups" with four beats from four different families. Load it **before** `hero-engines.md`: that file answers *which engine*, this one answers *whether you need an engine at all* |
| `interaction-motion.md` | **Anything in the build is draggable, or the interface has to answer a finger** — bottom sheets, drawers, swipe rows, pickers, pull-to-refresh, swipe-back, detented panels, a card that expands into a page, a confirm button that has to resolve. The **other half of motion**: `motion.md` covers what the viewer *watches* (you own the timeline), this covers what the viewer *causes* (**the user** owns it). Carries the test a panel is judged by — *是否在处理输入本身的不确定性：速度 · 方向 · 阈值 · 丢帧* — the four-stage follow-the-finger chain (1:1 tracking → damping past the edge → commit → snap), **windowed velocity** (the two obvious formulas are both wrong), dual-condition dismiss, detent ordering, the **five decisions a sheet is** (origin · layer · controller · detent · destination), FLIP's load-bearing double `rAF`, and a counter-example table. Applies **above 390px too** — a collapsing console sidebar is the same machine. Running evidence: `examples/h5-sheet-lab.html` |
| `hero-engines.md` | Building the hero engine (brand register); also covers a secondary motion vocabulary (split-char reveal, magnetic buttons, curtain wipe, scan-line, per-card fly-in) for non-hero moments elsewhere on the page — the **decision** layer (which engine). **Scope note: these are the two heaviest routes (R4 GSAP · R5 Canvas/WebGL) of the six in `motion.md`** — reach here only once that file's lookup has sent you to a heavy route |
| `page-crafting.md` | **The brand implementation layer** — what `chart-crafting.md` is to `dataviz.md`. Load it when you stop choosing and start writing: the **motion gate** (`REDUCE`/`FINE` probes + terminal states — universal, product too), canvas **DPR** + cyclic palettes + amplitude envelopes, `mask-image` photo dissolve, the **photographic-hero scrim stack**, container-query panels, nav **scroll-spy** over alternating sections, zero-dependency **sticky horizontal pin**, **exploded-view** scrub, colorway **pin+snap**, `clip-path` wipes, hand-written **FLIP** lightbox, **generative** (guillotine-split) layouts, CSS-only **geometric collage**, full-page engine + section scrims, and the Fibonacci→KNN→traversal 3D recipe |
| `h5-mobile.md` | **The page only ever lives on a phone** — H5 / 移动端页面 / 活动页 / 小程序页 / app UI 原型 / mobile PDP / 报告 H5. The **fourth register**, and a *container* one: it fixes the frame and wraps another register for content. Carries the viewport contract, the locked-`body`/scrolling-`#app` architecture that inverts every other register, the 560px desktop phone frame, safe-area math, the thumb-zone inversion (primary actions at the **bottom**), the touch rules that have no desktop equivalent (`passive`, `pointercancel`, tap-highlight, 44px), six phone morphologies, and the native furniture recipes — status bar, TabBar, bottom sheet, FAB, push and hand-written FLIP transitions. **Not the same file as `mobile-floor.md`**: that one keeps a *desktop* page from breaking on a phone; this one is for a page that has no desktop form at all |
| `mobile-floor.md` | **Any build that will be seen on a phone** — i.e. nearly all of them. The six mechanical causes of a broken phone layout, with the fix for each: `overflow-x: clip` vs `hidden` (and why `hidden` kills your sticky nav), `minmax(0,1fr)` on image-bearing grid tracks, clickable text that never wraps at *any* width, `overflow-wrap: anywhere` on display headings, one sticky at `top:0`, and the **all-caps `line-height` floor** that overrides §3's `.86–.95` for uppercase display type. `preflight.md` asks whether it breaks; this file says why it breaks |
| `3d-effects.md` | Adding a 3D moment — CSS tilt/flip/coverflow/depth-parallax or Three.js model/displacement |
| `style-personas.md` | Picking a soul (brand register) |
| `inspiration-catalog.md` | Persona picked but you want a wider menu of proven techniques for that soul, or the brief doesn't fit any of the 10 personas cleanly |
| `plain-words.md` | **Any time you are writing text the *user* reads** — the §0.B Design Read, `audit` findings, the memory-lock notice. finesse's whole vocabulary (`register`, `SPECTACLE`, `grain`, `scrim`, `eyebrow`, `hairline`) is load-bearing internally and opaque externally, and it leaks out at exactly the moments the user is supposed to make a decision. One-clause observable glosses, plus the list of internal terms (five-axis coordinates, axis letters, reference filenames) that must **never** reach a user |
| `anti-cheap.md` | Before any delivery — cheapness scan |
| `product-ui.md` | Dashboard / admin / data app — pages you **read** (product register) |
| `workflow-ui.md` | Pages you **operate** (product register): publish/create wizards, merchant & admin consoles, config, settings, review queues — the workflow shell, numbered section cards, radio-card choices, live-preview aside, pre-submit check, derived budget panels, draft/commit |
| `ai-console.md` | **Something other than the user is doing the work, and the page's job is to make that trustworthy** — AI 工作台 / agent console / 智能体控制台 / copilot UI / 值守台. **A capability layer, not a page type**: decide 后台 vs 工作台 first (§1's resolver), pick the body, *then* stack this on — it fails by being *untrustworthy* rather than unreadable or unfinishable, and that failure can land on any of them. Carries the four questions it must answer continuously, the three tenses on one screen (queue · live run · history), the **run stream** that replaces the chart as the centrepiece, the **nine run states** that `product-ui.md` §5's eight component states don't cover (including `partial` and `stopped`), stop as a primary resident control, the in-stream approval card with linked evidence, cost/context as first-class, the artifact surface, the desktop three-column shell and **what changes on a phone** (§9). Also the palette rule this category dies on: the AI-violet default, and the `--auto` vs `--needs` semantic pair |
| `product-palettes.md` | **Any product-register page** — the color layer `design-dna.md` §6 doesn't cover: 5 tinted neutral ramps, 16 accents with light/dark + text-on-accent contrast, 12 paste-ready sets, the known-SaaS palettes (Linear/Stripe/Supabase/Grafana…). Load it **before** picking a color, or you will reach for blue |
| `examples/EXAMPLES.md` | The positive-reference corpus — 22 real shipped pages (9 brand + 8 dashboards + 1 AI console + 4 H5) with a per-file "what to study" table. **Open the closest one before building**, especially for dashboards and phone shells (lift patterns, not whole files) |
| `dataviz.md` | Chart-heavy product UI beyond the starter table — full 25-type selection matrix, a11y grade + mandatory fallback, library picks (the **decision** layer) |
| `chart-crafting.md` | **Any** hand-built dashboard chart in a single self-contained file (mandatory for bars — the barcode-chart trap) — the no-library **implementation** layer: the value→height rule, `div height:value/max%` bar recipe, SVG coordinate normalization, line/area draw-in, donut/gauge grow, stacked bars, sparklines, the three animations × reduced-motion pairing, slider-driven live update |
| `commerce-ui.md` | Product detail page (PDP), listing/category page (PLP), cart, checkout — commerce register |
| `asset-sourcing.md` | **At §0.B, as soon as the page has anywhere a picture would carry it** — a hero, a gallery, an H5 cover or scene, a PDP shot, even a dashboard's empty state or avatar row. Not a category checklist and not a delivery-time scan: the paths (generate · real stock · generative placeholder) and the **ask-first gate on all of them** only work if they fire before the layout is written. Carries the session-capability check that decides which path you can honestly offer, and the rule that naming images is an offer the user answers — never a licence to generate or download |
| `preflight.md` | Final checklist before saying "done" |
| `design-model.md` | Multi-page projects — token consistency |
| `redesign-mode.md` | Upgrading an existing page — audit-first protocol |
| `audit.md` | Read-only diagnostic — cheapness + spectacle + preflight scan |
| `init.md` | New project — write `PRODUCT.md` (the persistent brief) |
| `document.md` | Existing codebase — extract `design-model.yaml` from real code |

---

## Commands

finesse runs as a full build by default, but supports **verb commands** for targeted iteration on an existing page — so you don't re-run the whole Brand Read for a single complaint. Each command loads one reference and does one job.

| Command | Category | Does | Reference |
|---------|----------|------|-----------|
| `craft [brief]` | Build | The full flow: Brand Read → Dials → substrate → engine → assemble (the default) | all |
| `init` | Setup | New project: write `PRODUCT.md` (register, soul, locked dials, anti-references) — the brief every later task reads | `init.md` |
| `document` | Setup | Existing codebase: extract the built design system into `design-model.yaml`; report drift | `document.md` |
| `audit [target]` | Evaluate | **Read-only** diagnostic: run the cheapness blacklist + spectacle-shown + pre-flight, output a findings list. **Changes nothing.** | `audit.md` |
| `bolder [target]` | Refine | Raise SPECTACLE +2, upgrade the engine (e.g. Canvas → Three.js) | `hero-engines.md` |
| `quieter [target]` | Refine | Lower SPECTACLE −2, step down to GSAP / CSS-only; calm an overloaded page | `hero-engines.md` |
| `soul [target]` | Refine | Re-pick the persona / soul when **this page** is the wrong vibe | `style-personas.md` |
| `diverge [target]` | Refine | **Every page comes out the same.** The systemic fix, not the per-page one: recompose the soul from the five orthogonal axes, run the two-altitude anti-default check, roll against the model's argmax, and check the used-list. Use when the user says "feels generic / like every other AI site / 每次都差不多" | `divergence.md` |
| `animate [target]` | Enhance | Re-cut the page's **beat sheet** — motion only, soul and substrate untouched. Not just the hero: pick the families (§2), take the cheapest route each (§3), hold the budget (one heavy beat, four total, no two from one family), compose every still. Swapping the hero engine is one case of this, not the whole command. **Fork first: is the beat something the viewer *watches* or something they *cause*?** 「抽屉能不能拖」「手势不跟手」「弹窗感觉很假」 is the second kind and goes to `interaction-motion.md` — its budget rules don't apply there, because a draggable panel isn't a beat you can cut | `motion.md` → `hero-engines.md` · (pointer-driven → `interaction-motion.md`) |
| `depth [target]` | Enhance | Add **one** 3D moment — CSS pseudo-3D (tilt · flip · coverflow · depth-parallax) or Three.js (model viewer · image displacement) | `3d-effects.md` |
| `densify [target]` | Enhance | Adjust DENSITY ± — add/remove content, tune information-per-viewport | `product-ui.md` |
| `redesign [target]` | Iterate | Upgrade an existing page, audit-first; never full-rebuild for one complaint | `redesign-mode.md` |

### Routing rules

1. **First word matches a command** → load that command's reference and follow it. Everything after the command name is the target. Lay the **§3 substrate** and run the relevant **§6/§8 checks**, but skip the parts of §0–§5 that don't apply to that single action (e.g. `quieter` doesn't re-pick a soul).
2. **First word doesn't match, but intent clearly maps to one command** ("too plain / boring" → `bolder`; "too flashy" → `quieter`; "wrong vibe *for this page*" → `soul`; "**feels generic / every page looks the same / 每次都差不多**" → `diverge`; "make it pop" → `animate`; "**动效 / 炫酷 / 加点动画 / 让它动起来 / 太静了**" → `animate` (load `motion.md` first — these words select nothing on their own, so §4's beat sheet is what turns them into a decision the user can veto); "add depth / make it 3D / tilt / parallax" → `depth`; "too sparse / too dense" → `densify`; "improve / fix this page" → `redesign`) → route to that command and proceed as if invoked. If two fit, ask once which.
3. **No argument at all** (bare `/finesse`) → the user is asking *"what should I do here?"* Don't dump the static menu. Read a few cheap signals and **lead with the 2-3 highest-value commands**, each with a one-line reason, then offer the full table as fallback. Never auto-run — recommend, the user confirms. Signal → pick:
   - **no `PRODUCT.md`** and there's real code/pages → lead with `document` (capture what's built) and/or `init` (write the brief). Brand-new empty project → `init` then `craft`.
   - **`PRODUCT.md` exists, has built pages, never audited** → lead with `audit <surface>` (read-only health check).
   - **git working tree points at one page/file** → scope `audit` or `redesign` to those files, naming them.
   - **a recent `audit` found P0/P1** → lead with `redesign` (fix the backlog) or the specific refine verb the findings point to (gradient-text/eyebrows → `quieter`/`soul`; flat motion → `animate`).
   - **nothing built yet, clear brief** → `craft`.
   Keep it to 2-3 pointed picks with the exact command to type. The menu is the fallback, not the lede.
4. **A target but no command, building something new** → **check the scope, then the surface.** If the brief names a *single element* (a button, an input, a card, a modal), route to `references/component-scope.md` — the page flow's skeleton, engine, and rotation are all wrong for one component, and the thing that actually decides its quality (all eight states shipped) isn't checked anywhere in the page flow. If the brief names a **phone-only page** (H5 / 移动端页面 / 活动页 / 小程序页 / app 原型), load `references/h5-mobile.md` **first** and build the frame before anything else — a page assembled desktop-first and then squeezed into 406px is the failure mode that file exists to prevent. Otherwise run the full `craft` flow (§0 → §8) — the default for "build me a landing page / dashboard".
5. **`audit` is read-only.** It only reports findings; it never edits code. Every other command is allowed to modify the target.

> Auto-trigger is unchanged: finesse still activates from natural language via its `description`. Commands are an **added** precision entry-point (`/finesse quieter page.html`), not a replacement — both routes lead to the same references.

After any command that modified the page, run the relevant **§8 Pre-Flight** gates before declaring done.

---

## 0. BRAND READ (Before Anything Else)

Most AI design output is bad because the model jumps to a default aesthetic instead of reading the brief. Don't.

### 0.A Determine the Register (this forks every later decision)

> **Ask the surface question first: does this page have a desktop form at all?** If the answer is no — it's an **H5 / 移动端页面 / 活动页 / 小程序页 / app 原型**, opened from a chat message or a QR code, looked at in a phone mock — then the register is **h5**, and it is a **container**: go to `references/h5-mobile.md`, build the frame, then come back here and pick the *content* register underneath it. h5 wraps one of the three below; it never replaces one. The one-question tiebreak when the brief just says "手机端的页面" is in `h5-mobile.md` §0: *"这个页面只在手机上打开，还是电脑上也要好看？"* — "both" means it's a brand/product page with `mobile-floor.md` applied, and building a phone frame for it would be wrong.

> **Ask the same question for 「工作台」, and ask it before anything else.** **「工作台」 and 「后台」 are two different products**, and defaulting the former to the latter is the most likely mis-build in this skill. Ask what it revolves around — **一批业务对象 → 后台; 他自己反复在做的一件事 → 工作台** — never how many people use it. Only then does the screen matter, and only to pick the workbench's body (desktop shell vs `h5-mobile.md` morph A.1); an agent doing the work is a **capability layer** on top (`ai-console.md`), not a third species. Full resolver under §1's dials table.

- **brand** — design IS the product: landing page, brand site, launch, portfolio, campaign, hero page. Be bold, opinionated, spectacular. Goes the soul + hero-engine route (§2, §4).
- **product** — design SERVES the product: dashboard, admin, analytics, data table, app shell, settings, tool. Optimize for clarity, density, usability. Goes the component-system route (`references/product-ui.md`). Still never cheap — it inherits the **universal craft floor** (§3's last three bullets) + the cheapness blacklist (§6), and builds on the **product substrate** (`product-ui.md` §0), **not** the brand substrate's grain/vignette/hero-type/dark-default.
  - **Split it once more — but the first split is 后台 vs 工作台, not a list of page jobs.** Ask what it revolves around: **a batch of business objects → 后台**; **one thing he does over and over → 工作台** (full resolver under §1's dials table — it is the most consequential fork in this skill and the easiest to get wrong).
    - **后台** splits by job into **read** and **operate**. A dashboard you *read* fails by being unreadable — `product-ui.md`, unchanged. A page whose primary action is a **consequential commit** (发布 / 上线 / 提交 / 保存配置 — a merchant publishing a campaign, an admin configuring a rule) is one you *operate*, and it fails by being **unfinishable**: load `references/workflow-ui.md` on top. Login forms and search filters don't count; `product-ui.md` §4 covers those.
    - **工作台** splits by **body, not by job** — desktop keeps `product-ui.md`'s shell at A.1's density and soul; phone goes to `h5-mobile.md` morph **A.1**. Same species either way.
    - **Then, orthogonal to all of the above: does something other than the user do the work over a duration?** An agent runs multi-step tasks, output streams in, a run can fail ha...