tasteskill: Anti-Slop Frontend Skill

Landing pages, portfolios, and redesigns. Not dashboards, not data tables, not multi-step product UI. Every rule below is contextual. None of it fires automatically. First read the brief, then pull only what fits.

0. BRIEF INFERENCE (Read the Room Before Anything Else)

Before touching code or tweaking dials, infer what the user actually wants. Most LLM design output is bad because the model jumps to a default aesthetic instead of reading the room.

0.A Read these signals first

1. Page kind - landing (SaaS / consumer / agency / event), portfolio (dev / designer / creative studio), redesign (preserve vs overhaul), editorial / blog.
2. Vibe words the user used - "minimalist", "calm", "Linear-style", "Awwwards", "brutalist", "premium consumer", "Apple-y", "playful", "serious B2B", "editorial", "agency-y", "glassy", "dark tech".
3. Reference signals - URLs they linked, screenshots they pasted, products they named, brands they're competing with.
4. Audience - B2B procurement panel vs. design-conscious consumer vs. recruiter scanning a portfolio. The audience picks the aesthetic, not your taste.
5. Brand assets that already exist - logo, color, type, photography. For redesigns, these are starting material, not optional input (see Section 11).
6. Quiet constraints - accessibility-first audiences, public-sector, regulated industries, trust-first commerce, kids' products. These constraints OVERRIDE aesthetic preference.

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

Before any code, state in one line: "Reading this as: <page kind> for <audience>, with a <vibe> language, leaning toward <design system or aesthetic family>."

Example reads:

• "Reading this as: B2B SaaS landing for technical buyers, with a Linear-style minimalist language, leaning toward Tailwind utilities + Geist + restrained motion."
• "Reading this as: solo designer portfolio for hiring managers, with an editorial / kinetic-type language, leaning toward native CSS + scroll-driven animation + custom typography."
• "Reading this as: redesign of a public-sector service site, with a trust-first language, leaning toward GOV.UK Frontend or USWDS."

0.C If the brief is ambiguous, ask one question, do not guess

Ask exactly one clarifying question - never a multi-question dump - and only when the design read genuinely diverges. Example: "Should this feel closer to Linear-clean or Awwwards-experimental?"

If you can confidently infer from context, do not ask. Just declare the design read and proceed.

0.D Anti-Default Discipline

Do not default to: AI-purple gradients, centered hero over dark mesh, three equal feature cards, generic glassmorphism on everything, infinite-loop micro-animations everywhere, Inter + slate-900. These are the LLM defaults. Reach past them deliberately based on the design read.

1. THE THREE DIALS (Core Configuration)

After the design read, set three dials. Every layout, motion, and density decision below is gated by these.

• DESIGN_VARIANCE: 8 - 1 = Perfect Symmetry, 10 = Artsy Chaos
• MOTION_INTENSITY: 6 - 1 = Static, 10 = Cinematic / Physics
• VISUAL_DENSITY: 4 - 1 = Art Gallery / Airy, 10 = Cockpit / Packed Data

Baseline: 8 / 6 / 4. Use these unless the design read overrides them. Do not ask the user to edit this file - overrides happen conversationally.

1.A Dial Inference (design read → dial values)

1.B Use-Case Presets

1.C How the Dials Drive Output

Use these (or user-overridden values) as global variables. Cross-references throughout this document refer to these exact variable names - never invent aliases like LAYOUT_VARIANCE or ANIM_LEVEL.

2. BRIEF → DESIGN SYSTEM MAP

Once you have the design read (Section 0) and dials (Section 1), pick the right foundation. Do not invent CSS for things that have an official package. Do not pretend an aesthetic trend is an official system.

2.A When to reach for a real design system (use official packages)

Honesty rule: if the brief reads as one of the systems above, install and use the official package. Do not recreate its CSS by hand. Do not import a system's tokens but then override 90% of them.

One system per project. Do not mix Fluent React with Carbon in the same tree. Do not import shadcn/ui components into a Material 3 app.

2.B When the brief is an aesthetic, not a system

For these directions, there is no single official package. Build with native CSS + Tailwind + a maintained component library. Be honest in code comments about what is borrowed inspiration vs. official material.

3. DEFAULT ARCHITECTURE & CONVENTIONS

Unless the design read picks a real design system (Section 2.A), these are the defaults:

3.A Stack

• Framework: React or Next.js. Default to Server Components (RSC).
  • RSC SAFETY: Global state works ONLY in Client Components. In Next.js, wrap providers in a "use client" component.
  • INTERACTIVITY ISOLATION: Any component using Motion, scroll listeners, or pointer physics MUST be an isolated leaf with 'use client' at the top. Server Components render static layouts only.
• Styling: Tailwind v4 (default). Tailwind v3 only if the existing project demands it.
  • For v4: do NOT use tailwindcss plugin in postcss.config.js. Use @tailwindcss/postcss or the Vite plugin.
• Animation: Motion (the library formerly known as Framer Motion). Import from motion/react (import { motion } from "motion/react"). The framer-motion package still works as a legacy alias - prefer motion/react in new code.
• Fonts: Always use next/font (Next.js) or self-host with @font-face + font-display: swap. Never link Google Fonts via <link> in production.

3.B State

• Local useState / useReducer for isolated UI.
• Global state ONLY for deep prop-drilling avoidance - Zustand, Jotai, or React context.
• NEVER use useState to track continuous values driven by user input (mouse position, scroll progress, pointer physics, magnetic hover). Use Motion's useMotionValue / useTransform / useScroll. useState re-renders the React tree on every change and collapses on mobile.

3.C Icons

• Allowed libraries (priority order): @phosphor-icons/react, hugeicons-react, @radix-ui/react-icons, @tabler/icons-react.
• Discouraged: lucide-react. Acceptable only when the user explicitly asks for it or the project already depends on it.
• NEVER hand-roll SVG icons. If a glyph is missing, install a second library or compose from primitives - do not draw icon paths from scratch.
• One family per project. Do not mix Phosphor with Lucide in the same component tree.
• Standardize strokeWidth globally (e.g. 1.5 or 2.0).

3.D Emoji Policy

Discouraged by default in code, markup, and visible text. Replace symbols with icon-library glyphs. Override: allow emojis only when the user explicitly asks for a playful / chat-style / social-native vibe - and even then use them sparingly with intent.

3.E Responsiveness & Layout Mechanics

• Standardize breakpoints (sm 640, md 768, lg 1024, xl 1280, 2xl 1536).
• Contain page layouts using max-w-[1400px] mx-auto or max-w-7xl.
• Viewport Stability: NEVER use h-screen for full-height Hero sections. ALWAYS use min-h-[100dvh] to prevent layout jumping on mobile (iOS Safari address bar).
• Grid over Flex-Math: NEVER use complex flexbox percentage math (w-[calc(33%-1rem)]). ALWAYS use CSS Grid (grid grid-cols-1 md:grid-cols-3 gap-6).

3.F Dependency Verification (mandatory)

Before importing ANY 3rd-party library, check package.json. If the package is missing, output the install command first. Never assume a library exists.

4. DESIGN ENGINEERING DIRECTIVES (Bias Correction)

LLMs default to clichés. Override these defaults proactively. Each rule has a context-aware override path.

See references/design-directives.md for Sections 4.1-4.6 and 4.8-4.11.

4.7 Layout Discipline (Hard Rules. Failing any of these is shipping broken work)

• Hero MUST fit in the initial viewport. Headline max 2 lines on desktop, subtext max 20 words AND max 3-4 lines, CTAs visible without scroll. If the copy is too long: reduce font scale OR cut copy. If you cannot describe the value-prop in 20 words of subtext, the value-prop is unclear, not the rule too tight. Never let the hero overflow and force scroll to find the CTA.
• Hero font-scale discipline. Plan font size and image size together. If the hero asset is large and the headline is more than 6 words, do not start at text-7xl/text-8xl. Default sensible range: text-4xl md:text-5xl lg:text-6xl for most heroes; text-6xl md:text-7xl only when the headline is 3-5 words. A 4-line hero headline is always a font-size error, never a copy-length error.
• HERO TOP PADDING CAP (mandatory): Hero top padding max pt-24 (≈6rem) at desktop. More than that means the hero content floats halfway down the viewport and reads as a layout bug, not as intentional space. If your hero needs more breathing room, increase font scale or asset size, not top padding.
• HERO STACK DISCIPLINE (max 4 text elements). The hero is a single moment, not a feature list. Allowed text elements, max 4 in total:
  1. Eyebrow (small uppercase label) OR brand strip OR neither - pick zero or one
  2. Headline (max 2 lines, see above)
  3. Subtext (max 20 words, max 4 lines)
  4. CTAs (1 primary + max 1 secondary)
  • BANNED in the hero: tiny tagline below CTAs ("Works with GitHub, GitLab, and self-hosted Git"), trust micro-strip ("Used by engineering teams at..."), pricing teaser ("Free for solo, $10/user for teams"), feature bullet list, social-proof avatar row. All of those move to dedicated sections directly below the hero.
  • If you have an eyebrow AND a tagline below CTAs in the same hero, drop the tagline. If you have a brand strip AND a tagline, drop the tagline. One small text element per hero, max.
• "Used by" / "Trusted by" logo wall belongs UNDER the hero, never inside it. The hero is for the value prop and primary CTA. The logo wall is a separate section directly below. Do not stuff trust logos into the same flex row as the hero copy.
• Navigation MUST render on a single line on desktop. If items don't fit at lg (1024px), condense labels, drop secondary items, or move to a hamburger. A two-line nav at desktop is broken design.
• Navigation height cap: 80px max desktop, default 64-72px. No huge "agency" nav bars that eat 15% of the viewport.
• Bento grids MUST have rhythm, not one-sided repetition. Do not stack 6 left-image / right-text rows. Vary the composition: alternate full-width feature rows, asymmetric tile sizes, vertical breaks.
• BENTO CELL COUNT RULE (mandatory): A bento grid has EXACTLY as many cells as you have content for. 3 items → 3 cells (1+2 split, or 2+1, or asymmetric trio). 5 items → 5 cells (2+3, 3+2, hero+4, etc.). If your grid has an empty cell in the middle or at the end, you planned wrong. Re-shape the grid; do not paste a blank tile.
• Section-Layout-Repetition Ban. Once you use a layout family for a section (e.g., 3-column-image-cards, full-width-quote, split-text-image), that family can appear at most ONCE on the page. "Selected commissions" must not look like "What we do." A landing page with 8 sections must use at least 4 different layout families.
• ZIGZAG ALTERNATION CAP (mandatory). Alternating "left-image + right-text" then "left-text + right-image" zigzag layout = banal. Max 2 sections in a row with this image+text-split pattern. The 3rd consecutive image+text split is a Pre-Flight Fail. Break the pattern with a full-width section, a vertical-stack section, a bento grid, a marquee, or a different layout family.
• EYEBROW RESTRAINT (mandatory, the #1 violated rule in production tests). An "eyebrow" is the small uppercase wide-tracking label sitting above a section headline (e.g. FOUR COLORWAYS, SELECTED WORK, THE HARDWARE, Git-native task management). Typical CSS signature: text-[11px] uppercase tracking-[0.18em], font-mono text-[10.5px] uppercase tracking-[0.22em]. Every AI-built site puts an eyebrow above EVERY section header, producing the same templated rhythm. Hard rule:
  • Maximum 1 eyebrow per 3 sections. Hero counts as 1. So a page with 9 sections may use at most 3 eyebrows total.
  • If section A has an eyebrow, the next 2 sections cannot have one.
  • Pre-Flight Check is mechanical: count instances of uppercase tracking (or similar small-caps mono labels above headlines) across all section components. If count > ceil(sectionCount / 3), the output fails.
  • What to do instead of an eyebrow: drop it entirely. The headline alone is enough. If you need to categorize a section, the section's location on the page already categorizes it; no label needed.
• SPLIT-HEADER BAN (mandatory). The pattern "left big headline + right small explainer paragraph" as a section header (left col-span-7/8, right col-span-4/5 with a small body paragraph floating in the right column) is banned as default. Sections should have ONE focused message. If you genuinely need both a headline and an explainer paragraph, stack them vertically (headline on top, body below, max-width 65ch). Reach for the split-header pattern only when there is a real compositional reason (e.g., the right column carries a visual or interactive element, not just filler text).
• Bento Background Diversity (mandatory). Bento and feature-grid sections cannot be 6 white-on-white cards with text inside. At least 2-3 cells in any multi-cell grid need real visual variation: a real image, a brand-appropriate gradient (not AI-purple), a pattern, a tinted background. A cream-on-cream bento with only typography inside reads as boring AI default, even when the rest of the page is good.
• Mobile collapse must be explicit per section. For every multi-column layout, declare the < 768px fallback in the same component. No "it'll work, Tailwind handles it" assumptions.

9. AI TELLS (Forbidden Patterns)

Avoid these signatures unless the brief explicitly asks for them.

9.A Visual & CSS

• NO neon / outer glows by default. Use inner borders or subtle tinted shadows.
• NO pure black (#000000). Off-black, zinc-950, or charcoal.
• NO oversaturated accents. Desaturate to blend with neutrals.
• NO excessive gradient text for large headers.
• NO custom mouse cursors. Outdated, accessibility-hostile, perf-hostile.

9.B Typography

• AVOID Inter as default. See Section 4.1. Override path exists.
• NO oversized H1s that just scream. Control hierarchy with weight + color, not raw scale.
• Serif constraints: Serif for editorial / luxury / publication. Not for dashboards.

9.C Layout & Spacing

• Mathematically perfect padding and margins. No floating elements with awkward gaps.
• NO 3-column equal feature cards. The generic "three identical cards horizontally" feature row is banned. Use 2-column zig-zag, asymmetric grid, scroll-pinned, or horizontal-scroll alternative.

9.D Content & Data ("Jane Doe" Effect)

• NO generic names. "John Doe", "Sarah Chan", "Jack Su" → use creative, realistic, locale-appropriate names.
• NO generic avatars. No SVG "egg" or Lucide user icons → use believable photo placeholders or specific styling.
• NO fake-perfect numbers. Avoid 99.99%, 50%, 1234567. Use organic, messy data (47.2%, +1 (312) 847-1928).
• NO startup-slop brand names. "Acme", "Nexus", "SmartFlow", "Cloudly" → invent contextual, premium names that sound real.
• NO filler verbs. "Elevate", "Seamless", "Unleash", "Next-Gen", "Revolutionize" → concrete verbs only.

9.E External Resources & Components

• NO hand-rolled SVG icons. Use Phosphor / HugeIcons / Radix / Tabler. Lucide on explicit request only.
• Hand-rolled decorative SVGs strongly discouraged as default (see Section 4.8).
• NO div-based fake screenshots. Never build a fake product UI out of <div> rectangles to simulate a screenshot. Use real images, generated images, or skip the preview.
• NO broken Unsplash links. Use https://picsum.photos/seed/{descriptive-string}/{w}/{h}, or generated photo placeholders, or actual assets.
• shadcn/ui customization: Allowed, but NEVER in default state. Customize radii, colors, shadows, typography to the project aesthetic.
• Production-Ready Cleanliness: Code visually clean, memorable, meticulously refined.

See references/anti-slop-rulebook.md for Sections 9.F-9.G.

11. REDESIGN PROTOCOL

This skill handles greenfield builds AND redesigns. Misclassifying the mode is the single biggest source of bad redesign output.

11.A Detect the Mode (first action)

• Greenfield - no existing site, or full overhaul approved. Dial baseline from Section 1.
• Redesign - Preserve - modernise without breaking the brand. Audit first, extract brand tokens, evolve gradually.
• Redesign - Overhaul - new visual language on top of existing content. Treat as greenfield for visuals; preserve content and IA.

If ambiguous, ask once: "Should this redesign preserve the existing brand, or are we starting visually from scratch?"

11.B Audit Before Touching

Document the current state before proposing changes:

• Brand tokens - primary / accent colors, type stack, logo treatment, radii.
• Information architecture - page tree, primary nav, key conversion paths.
• Content blocks - what exists, what's doing work, what's filler.
• Patterns to preserve - signature interactions, recognisable hero, copy voice.
• Patterns to retire - AI-slop tells, broken layouts, dead links, generic stock imagery, perf traps.
• Dial reading of the existing site - infer current DESIGN_VARIANCE / MOTION_INTENSITY / VISUAL_DENSITY. That's your starting point, not the baseline.
• SEO baseline - current ranking pages, meta titles, structured data, OG cards. SEO migration is the #1 redesign risk.

11.C Preservation Rules

• Do not change information architecture unless asked. Keep page slugs, anchor IDs, primary nav labels stable for SEO and muscle memory.
• Extract brand colors before applying Section 4.2. A brand that is already purple stays purple - apply the LILA RULE's override.
• Preserve copy voice unless asked for a rewrite. Visual modernisation ≠ content rewrite.
• Honor existing accessibility wins. Do not regress focus states, alt text, keyboard nav, contrast.
• Respect existing analytics events. Do not rename buttons, form fields, section IDs that downstream tracking depends on.

11.D Modernisation Levers (priority order)

Apply in order - stop when the brief is satisfied:

1. Typography refresh - biggest visual lift per unit of risk.
2. Spacing & rhythm - increase section padding, fix vertical rhythm.
3. Color recalibration - desaturate, unify neutrals, keep brand accent.
4. Motion layer - add MOTION_INTENSITY-appropriate micro-interactions to existing components.
5. Hero & key-section recomposition - restructure top-of-funnel using Section 10 vocabulary.
6. Full block replacement - only when the existing block is unsalvageable.

11.E Decision Tree: Targeted Evolution vs Full Redesign

• IA, content, and SEO sound → targeted evolution (Levers 1-4). ~70% of value at ~40% of risk.
• Visual debt is structural (broken IA, no design system, broken mobile) → full redesign with strict content preservation.
• Brand itself is changing → greenfield.

11.F What Never Changes Silently

Never modify without explicit user approval:

• URL structure / route slugs.
• Primary nav labels.
• Form field names or order (breaks analytics + autofill).
• Brand logo or wordmark.
• Existing legal / consent / cookie copy.

13. OUT OF SCOPE

This skill is NOT for:

• Dashboards / dense product UI / admin panels (use Fluent, Carbon, Atlassian, or Polaris from Section 2.A).
• Data tables (use TanStack Table or AG Grid).
• Multi-step forms / wizards (use Form-specific patterns; this skill won't make them better).
• Code editors (use Monaco / CodeMirror with their official skinning).
• Native mobile (use Apple HIG / Material directly).
• Realtime collab UIs (presence, cursors, OT-aware - different problem class).

If the brief is one of the above, say so explicitly, point to the right tool, and only apply this skill's marketing-page / about-page / landing-page parts to the surfaces where they apply.

14. FINAL PRE-FLIGHT CHECK

Run this matrix before outputting code. This is the last filter.

THIS IS NOT OPTIONAL. Run every box. If any box fails, the output is not done.

• Brief inference declared (Section 0.B one-liner)?
• Dial values explicit and reasoned from the brief, not silently using baseline?
• Design system chosen from Section 2 if applicable, or aesthetic labeled honestly?
• Redesign mode detected and audit performed (if applicable, Section 11)?
• ZERO em-dashes (—) anywhere on the page. Headlines, eyebrows, pills, body, quotes, attribution, captions, buttons, alt text. Zero. (Section 9.G - non-negotiable.)
• Page Theme Lock: ONE theme (light, dark, or auto) for the whole page. No section flips to inverted mode mid-page (Section 4.11)?
• Color Consistency Lock: one accent color used identically across all sections (Section 4.2)?
• Shape Consistency Lock: one corner-radius system applied consistently (Section 4.4)?
• Button Contrast Check: every CTA text is readable against its background (no white-on-white, WCAG AA 4.5:1)?
• CTA Button Wrap: no CTA label wraps to 2+ lines at desktop?
• Form Contrast Check: form inputs, placeholders, focus rings, labels all pass WCAG AA against the section background?
• Serif discipline: if a serif is used, it is NOT Fraunces or Instrument_Serif (or it is, with explicit brand justification)? Different serif from your previous project?
• Premium-consumer palette check: if the brief is premium-consumer (cookware / wellness / artisan / luxury), the palette is NOT the AI-default beige+brass+oxblood+espresso family? Different family from your previous premium-consumer project?
• Italic descender clearance: every italic word with y g j p q has leading-[1.1] min + pb-1 reserve?
• Hero fits the viewport: headline ≤ 2 lines, subtext ≤ 20 words AND ≤ 4 lines, CTA visible without scroll, font scale planned around image?
• Hero top padding: max pt-24 at desktop, hero content does not float halfway down the viewport?
• Hero stack discipline: max 4 text elements in hero (eyebrow OR brand strip, headline, subtext, CTAs)? No tiny tagline below CTAs, no trust micro-strip in hero?
• EYEBROW COUNT (mechanical): count instances of uppercase tracking micro-labels above section headlines across all components. Count ≤ ceil(sectionCount / 3)? Hero counts as 1.
• Split-Header Ban: no "left big headline + right small explainer paragraph" pattern as a section header (vertical stack instead)?
• Zigzag Alternation Cap: no 3+ consecutive sections with the same image+text-split layout?
• No Duplicate CTA Intent: no two CTAs with the same intent ("Get in touch" + "Let's talk" both on page = Fail)?
• Logo wall = logo only: no industry / category labels printed below logos?
• Bento Background Diversity: at least 2-3 bento cells have real visual variation (image, gradient, pattern), not all white-on-white text cards?
• "Used by / Trusted by" logo wall lives UNDER the hero, not inside it, uses REAL SVG logos (Simple Icons / devicon) or generated SVG marks, NOT plain text wordmarks?
• Copy Self-Audit: every visible string re-read, no grammatically-broken or AI-hallucinated phrases ("free on its past" type) shipped?
• Motion motivated: every animation can be justified in one sentence (hierarchy / storytelling / feedback / state transition), no GSAP-for-show?
• Marquee max-one-per-page: no two horizontal marquees on the same page?
• Navigation on ONE line at desktop, height ≤ 80px?
• Section-Layout-Repetition check: no two sections share the same layout family (at least 4 different families across 8 sections)?
• Bento has rhythm AND exact cell count (N items → N cells, no empty cells in middle or at end)?
• Long lists use the right UI component (not default <ul> with divide-y for > 5 items - see Section 4.9 alternatives)?
• Real images used (gen-tool first, then Picsum-seed, then explicit placeholder slots) - NO div-based fake screenshots, NO hand-rolled decorative SVGs, NO pure-text minimalism?
• No pills/labels overlaid on images (no Plate · Brand, no Field notes - journal)?
• No photo-credit captions as decoration (Field study no. 12 · Ines Caetano)?
• No version footers (v1.4.2, Build 0048) on marketing pages?
• No micro-meta-sentences under eyebrows ("Each of these is a feature we ship today...")?
• No decoration text strip at hero bottom (BRAND. MOTION. SPATIAL.)?
• No floating top-right sub-text in section headings?
• No scoring/progress bars with filled background tracks as comparison visuals?
• No locale / city-name / time / weather strips unless brief is genuinely globally-distributed or place-focused?
• No scroll cues (Scroll, ↓ scroll, Scroll to explore)?
• No version labels in hero (V0.6, BETA, INVITE-ONLY) unless the brief is a launch?
• No section-numbering eyebrows (00 / INDEX, 001 · Capabilities, 06 · how it works)?
• No decorative dots (zero by default, only for real semantic state)?
• No border-t + border-b on every row of long lists / spec tables?
• Content density sane: no 20-row data tables, no fake-precise specs without justification, ≤ 25-word sub-paragraphs by default?
• Quotes ≤ 3 lines of body, attribution clean (no em-dash)?
• Motion claimed = motion shown: if MOTION_INTENSITY > 4, page actually animates, not just claimed?
• GSAP sticky-stack / horizontal-pan implemented per Section 5.A / 5.B canonical skeleton (start: "top top", pin: true, correct scrub)?
• No window.addEventListener('scroll') - using Motion useScroll() / ScrollTrigger / IntersectionObserver / CSS scroll-driven animations only?
• Reduced motion wrapped for everything MOTION_INTENSITY > 3?
• Dark mode tokens defined and tested in both modes?
• Mobile collapse explicit (w-full, px-4, max-w-7xl mx-auto) for high-variance layouts?
• Viewport stability: min-h-[100dvh], never h-screen?
• useEffect animations have strict cleanup functions?
• Empty / loading / error states provided?
• Cards omitted in favor of spacing where possible?
• Icons from an allowed library only (Phosphor / HugeIcons / Radix / Tabler), no hand-rolled SVG paths?
• Motion isolated in client-leaf components with 'use client' at the top, memoized?
• No AI Tells from Section 9 (Inter as default, AI-purple, three-equal cards, Jane Doe, Acme, "Quietly in use at")?
• Core Web Vitals plausibly hit (LCP < 2.5s, INP < 200ms, CLS < 0.1)?
• One design system per project (no Material + shadcn mixed)?

If a single checkbox cannot be honestly ticked, the page is not done. Fix it before delivering.

References

Deep-dive sections of this skill live in references/ (moved verbatim; section numbers preserved). Read a file only when its trigger below fires.

• references/design-directives.md — Read when: composing typography, color, layout variety, materiality, interactive states, data/form patterns, imagery, content density, quotes, or page theme lock (Sections 4.1-4.6, 4.8-4.11).
• references/anti-slop-rulebook.md — Read when: finishing a page or auditing output for production-test tells and the em-dash ban (Sections 9.F-9.G).
• references/motion-and-animation.md — Read when: implementing scroll or motion (sticky-stack, horizontal-pan, scroll-reveal canonical skeletons; forbidden animation patterns) (Section 5).
• references/guardrails-and-specs.md — Read when: tuning performance/accessibility, dark-mode tokens, or reading dial level definitions 1-10 (Sections 6-8).
• references/pattern-vocabulary-and-blocks.md — Read when: naming or reaching for a UI pattern, or adding blocks to the Block Library (Sections 10, 12).
• references/design-system-appendices.md — Read when: installing a design system (exact commands), checking canonical source links, or approximating Apple Liquid Glass on the web (Appendices A-C).