frontend-taste-layer

Frontend Taste Layer

Raise the taste level without turning the work into a random aesthetic stunt.

Use this after the task is understood and the surface register is known. If the project still lacks design context, start with design-register-bootstrap.

Best Fit

• landing pages;
• portfolios;
• brand-forward promo pages;
• redesigns where the current UI feels boilerplate or interchangeable;
• hero sections and first-screen composition work.

Not The Best Fit

• dense dashboards;
• table-heavy app UI;
• settings forms where utility matters more than expressive styling;
• projects that must preserve a strict existing enterprise design system.

Route Before Styling

• For marketing, editorial, portfolio, and brand-forward pages, continue with this skill.
• For dashboards, settings, onboarding, checkout, paywalls, and other product UI, use Lazyweb evidence first, then user-experience, design-critique-polish, or the project's product-specific skill.
• If one page mixes both registers, apply this skill only to the marketing/editorial regions. Product-task clarity wins at the seam.

Design Read

Before changing code, state one sentence:

Reading this as: <surface> for <audience>, with a <vibe> language, leaning toward <design family>.

Do not skip this. Most generic output comes from styling before the read is explicit.

Creator Intent Check

Before widening into polish, state briefly:

• what the person is actually trying to make possible;
• what must remain recognizably theirs;
• which single decision most changes first-use experience.

If the answer is still too vague to guide a real choice, ask one sharp clarifying question, not a survey. If ambiguity does not block a real choice, move.

Three Dials

Set these as relative directions for the pass; do not impose universal numeric defaults:

• variance: symmetry versus surprise;
• motion: static versus cinematic;
• density: airy versus packed.

Use them to keep decisions consistent. Do not expose a pile of disconnected visual tweaks.