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)
0. 需求推断(先读懂需求场景)
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.B Output a one-line "Design Read" before generating
0.B 生成前输出一行「设计解读」
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
0.C 若需求模糊,只提一个问题,不要猜测
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.
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.
Use these (or user-overridden values) as global variables. Cross-references throughout this document refer to these exact variable names - never invent aliases like
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)
2.A 何时选用真实设计系统(使用官方包)
Brief reads as…
Reach for
Why
Microsoft / enterprise SaaS / dashboards
@fluentui/react-components
or
@fluentui/web-components
Official Fluent UI, Microsoft tokens, accessibility done
Google-ish UI, Material-flavored product
@material/web
+ Material 3 tokens
Official, theme-able via Material Theming
IBM-style B2B / enterprise analytics
@carbon/react
+
@carbon/styles
Official Carbon, mature data-density patterns
Shopify app surfaces
polaris.js
web components / Polaris React
Required for Shopify admin UI
Atlassian / Jira-style product
@atlaskit/*
+
@atlaskit/tokens
Official Atlassian DS
GitHub-style devtool / community page
@primer/css
or
@primer/react-brand
Official Primer; Brand variant for marketing
Public-sector UK service
govuk-frontend
Legally / regulatorily expected
US public-sector / trust-first
uswds
Same
Fast local-business / agency MVP
Bootstrap 5.3
Boring, fast, works
Modern accessible React foundation
@radix-ui/themes
Primitives + polished theme
Modern SaaS where you own the components
shadcn/ui (
npx shadcn@latest add ...
)
You own the code, easy to customise; never ship default state
Tailwind-based modern SaaS / AI marketing
Tailwind v4 utilities +
dark:
variant
Default for indie + small team builds
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.
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.
Aesthetic
Honest implementation
Glassmorphism / "frosted glass"
backdrop-filter
, layered borders, highlight overlays. Provide solid-fill fallback for
prefers-reduced-transparency
.
Bento (Apple-style tile grids)
CSS Grid with mixed cell sizes. No single library owns this.
Brutalism
Native CSS, monospace, raw borders. No library.
Editorial / magazine
Serif type, asymmetric grid, generous whitespace. No library.
Dark tech / hacker
Mono + accent neon, terminal motifs. No library.
Aurora / mesh gradients
SVG or layered radial gradients. No library.
Kinetic typography
Native CSS animations, scroll-driven animations, GSAP for hijacks. No library.
Apple Liquid Glass
Apple documents this for Apple platforms only. There is no official
liquid-glass.css
. Web implementations are approximations using
backdrop-filter
+ layered borders + highlights. Label clearly as approximation.
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.
局部
useState
/
useReducer
用于隔离UI状态。
全局状态仅用于避免深层属性透传——使用Zustand、Jotai或React context。
绝不使用
useState
跟踪由用户输入驱动的连续值(鼠标位置、滚动进度、指针物理效果、磁吸悬停)。使用Motion的
useMotionValue
/
useTransform
/
useScroll
。
useState
会在每次变化时重新渲染React树,在移动端会导致卡顿。
3.C Icons
3.C 图标
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
).
允许的库(优先级顺序):
@phosphor-icons/react
、
hugeicons-react
、
@radix-ui/react-icons
、
@tabler/icons-react
。
不推荐:
lucide-react
。仅当用户明确要求或项目已依赖时使用。
绝不手动绘制SVG图标。如果缺少某个图标,安装第二个库或用基础元素组合——不要从头绘制图标路径。
每个项目只用一个图标家族。不要在同一组件树中混合使用Phosphor和Lucide。
全局标准化
strokeWidth
(例如
1.5
或
2.0
)。
3.D Emoji Policy
3.D Emoji规则
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.
Override: Inter is acceptable when the user explicitly asks for a neutral / standard / Linear-style feel, or when the brief is a public-sector / accessibility-first site.
Pairings to know:
Geist
+
Geist Mono
,
Satoshi
+
JetBrains Mono
,
Cabinet Grotesk
+
Inter Tight
,
GT America
+
IBM Plex Mono
.
SERIF DISCIPLINE (VERY DISCOURAGED AS DEFAULT):
Serif is very discouraged as the default font for any project. "It feels creative / premium / editorial" is NOT a reason to reach for serif. The agent's default mental model that "creative brief = serif" is the single most-tested AI tell in production rounds.
Serif is only acceptable when ONE of these is explicitly true:
The brand brief literally names a serif font, OR
The aesthetic family is genuinely editorial / luxury / publication / manuscript / heritage / vintage AND you can articulate why this specific serif fits this specific brand
For everything else (creative agency, design studio, modern brand, premium consumer, portfolio, lifestyle), default sans-serif display (Geist Display, ABC Diatype, Söhne Breit, Cabinet Grotesk Display, Migra Sans, GT Walsheim, Inter Display, PP Neue Montreal). Sans display fonts are not "boring" — they are the default for the same reason black is the default in fashion.
EMPHASIS RULE (related): When you want to emphasize a word within a headline (the kinetic "and
spatial
design" type move), use italic or bold of the SAME font. Do NOT inject a random serif word into a sans headline (or vice versa) just to add visual interest. Mixed-family emphasis is amateur. Italic/bold emphasis in the same family is the right move.
Specifically BANNED as defaults:
Fraunces
and
Instrument_Serif
(the two LLM-favorite display serifs).
If a serif is justified (rare, per the above), rotate from this pool, do NOT reuse the same serif across consecutive projects: PP Editorial New, GT Sectra Display, Cardinal Grotesque, Reckless Neue, Tiempos Headline, Recoleta, Cormorant Garamond, Playfair Display, EB Garamond, IvyPresto, Migra, Editorial Old, Saol Display, Söhne Breit Kursiv, Domaine Display, Canela, Schnyder, Tobias, NB Architekt, ITC Galliard.
ITALIC DESCENDER CLEARANCE (mandatory): When italic is used in display type and the word contains a descender letter (
y g j p q
),
leading-[1]
or
leading-none
will clip the descender. Use
leading-[1.1]
minimum and add
pb-1
or
mb-1
reserve on the wrapping element. Audit every italic word in display headlines before shipping.
THE LILA RULE: The "AI Purple / Blue glow" aesthetic is discouraged as a default. No automatic purple button glows, no random neon gradients. Use neutral bases (Zinc / Slate / Stone) with high-contrast singular accents (Emerald, Electric Blue, Deep Rose, Burnt Orange, etc.).
Override: if the brand or brief explicitly asks for purple / violet / lila, embrace it. But execute with intent: consistent palette, harmonised neutrals, restrained gradients. Not generic AI gradient slop.
One palette per project. Do not fluctuate between warm and cool grays within the same project.
COLOR CONSISTENCY LOCK (mandatory): Once an accent color is chosen for a page, it is used on the WHOLE page. A warm-grey site does not suddenly get a blue CTA in section 7. A rose-accented site does not get a teal status badge in the footer. Pick one accent, lock it, audit every component before shipping.
PREMIUM-CONSUMER PALETTE BAN (mandatory, second-most-recurring AI-tell):
For premium-consumer briefs (cookware, wellness, artisan, luxury, heritage craft, DTC home goods, etc.) the LLM default is warm beige/cream + brass/clay/oxblood/ochre + espresso/ink dark text. Concretely banned hex families as default backgrounds and accents:
Backgrounds:
#f5f1ea
,
#f7f5f1
,
#fbf8f1
,
#efeae0
,
#ece6db
,
#faf7f1
,
#e8dfcb
(all "warm paper / cream / chalk / bone")
Accents:
#b08947
,
#b6553a
,
#9a2436
,
#9c6e2a
,
#bc7c3a
,
#7d5621
(all "brass / clay / oxblood / ochre")
Text:
#1a1714
,
#1a1814
,
#1b1814
(all "espresso / warm near-black")
This palette is BANNED as the default reach for premium-consumer briefs. Every premium-consumer site you have ever shipped uses this exact palette. The brand becomes invisible.
Forest: deep green + bone + amber accent (think Filson, Patagonia premium)
Black and Tan: true off-black + warm tan, sharp contrast, no beige
Cobalt + Cream: saturated blue against a single neutral, no brass
Terracotta + Slate: warm rust against cool grey, no brass
Olive + Brick + Paper: muted olive plus brick-red accent
Pure monochrome + single saturated pop: off-white + off-black + one bright accent (electric blue, emerald, hot pink, etc.)
Palette-rotation rule: if the previous premium-consumer project you generated used the beige+brass family, this one MUST use a different family. Do not ship the same warm-craft palette twice in a row.
Override: the beige+brass+espresso palette is acceptable ONLY when the brand brief explicitly names those colors, or when the brand identity is genuinely vintage / artisan / warm-craft AND you can articulate why this specific palette fits this specific brand. Default-reaching for it because "this is a cookware brief" is banned.
Use cards ONLY when elevation communicates real hierarchy. Otherwise group with
border-t
,
divide-y
, or negative space.
When a shadow is used, tint it to the background hue. No pure-black drop shadows on light backgrounds.
For
VISUAL_DENSITY > 7
: generic card containers are banned. Data metrics breathe in plain layout.
SHAPE CONSISTENCY LOCK (mandatory): Pick ONE corner-radius scale for the page and stick to it. Options: all-sharp (radius 0), all-soft (radius 12-16px), all-pill (full radius for interactive). Mixed systems are allowed only when there is a documented rule (e.g. "buttons are full-pill, cards are 16px, inputs are 8px") and that rule is followed everywhere. Round buttons in a square layout, or square cards on a pill-button page, is broken design.
LLMs default to "static successful state only." Always implement full cycles:
Loading: Skeletal loaders matching the final layout's shape. Avoid generic circular spinners.
Empty States: Beautifully composed; indicate how to populate.
Error States: Clear, inline (forms), or contextual (toasts only for transient).
Tactile Feedback: On
:active
, use
-translate-y-[1px]
or
scale-[0.98]
to simulate a physical push.
BUTTON CONTRAST CHECK (mandatory, a11y): Before shipping any button, verify the button text is readable against the button background. White button + white text,
bg-white
CTA with
text-white
label, transparent button against the page background with no border → all banned. Audit every CTA: contrast ratio WCAG AA min (4.5:1 for body, 3:1 for large text 18px+). Same rule applies to ghost buttons over photographic backgrounds (use a backdrop, scrim, or stroke).
CTA BUTTON WRAP BAN (mandatory): Button text MUST fit on one line at desktop. If a label like "VIEW SELECTED WORK" wraps to 2 or 3 lines, the button is broken. Fix by EITHER shortening the label (3 words max for primary CTAs, ideally 1-2) OR widening the button (do not artificially constrain
max-width
on CTAs). Wrapped CTAs at desktop are a Pre-Flight Fail.
NO DUPLICATE CTA INTENT (mandatory): Two CTAs with the same intent on one page is a Pre-Flight Fail. Examples of same intent: "Get in touch" + "Contact us" + "Let's talk" + "Start a project" + "Start something" + "Reach out" = all "contact" intent → pick ONE label and use it everywhere on the page (nav, hero, footer). Same for "Try free" + "Get started" + "Sign up free" (all "signup" intent) and "View work" + "See selected work" + "Browse projects" (all "portfolio" intent). One label per intent.
FORM CONTRAST CHECK (mandatory, a11y): Form inputs, placeholder text, focus rings, helper text, and error text all pass WCAG AA contrast against the section background. Light placeholders on a near-white form, white form on white page section, form labels grayer than 4.5:1 contrast → all banned. Audit every form before shipping.
Label ABOVE input. Helper text optional but present in markup. Error text BELOW input. Standard
gap-2
for input blocks.
No placeholder-as-label. Ever.
标签位于输入框上方。辅助文本可选但需在标记中存在。错误文本位于输入框下方。输入块默认使用
gap-2
。
绝不使用占位符作为标签。永远不要。
4.7 Layout Discipline (Hard Rules. Failing any of these is shipping broken work)
4.7 布局规则(硬性规则,违反任何一条均为交付不合格)
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:
Eyebrow (small uppercase label) OR brand strip OR neither - pick zero or one
Headline (max 2 lines, see above)
Subtext (max 20 words, max 4 lines)
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.
. 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.
Hero中禁止的元素: CTAs下方的小标语(“Works with GitHub, GitLab, and self-hosted Git”)、信任微条(“Used by engineering teams at...”)、价格预告(“Free for solo, $10/user for teams”)、功能项目符号列表、社交证明头像行。所有这些元素应移至Hero正下方的专门区域。
Landing pages and portfolios are visual products. Text-only pages with fake-screenshot divs are slop.
Priority order for visual assets:
Image-generation tool first. If ANY image-gen tool is available in the environment (
generate_image
, MCP image tool, IDE-integrated gen, OpenAI image tools, etc.) you MUST use it to create section-specific assets: hero photography, product shots, texture backgrounds, mood images. Generate at the right aspect ratio for the section. Do not skip this step because hand-rolled CSS feels faster.
Real web images second. When no gen tool is available, use real photography sources. Acceptable defaults:
for placeholder photography (seed should describe the section, e.g.
marrow-cookware-kitchen
)
Actual stock or brand URLs when the brief provides them
Open-license sources (Unsplash via direct URL, Pexels) if explicitly allowed
Last resort: tell the user. If neither is possible, do NOT fill the page with hand-rolled SVG illustrations or div-based "fake screenshots." Instead, leave clearly-labeled placeholder slots (
<!-- TODO: hero product photo, 1600x1200 -->
) and at the end of the response say: "This page needs real images at: [list of placements]. Please generate or provide them."
Even minimalist sites need real images. A pure-text page is not minimalism. It is incomplete work. Even an editorial Linear-style site needs at least 2-3 real images (hero, one product/lifestyle shot, one supporting image). Generate B&W minimalist photography if the brief is restrained; do not skip images entirely because the dial is low.
Real company logos for social proof. When the brief calls for a "Trusted by / Used by / Customers" logo wall, do NOT default to plain text wordmarks (
<span>Acme Co</span>
styled in a row). Use real SVG logos:
Source: Simple Icons (
https://cdn.simpleicons.org/{slug}/ffffff
for any color, or
simple-icons
npm package). Covers most known brands.
Alternative: devicon for tech-stack logos (
@svgr/cli
or CDN).
Make-up the brand name? Then make-up an SVG mark too. Generate a simple monogram (one letter in a circle, two-letter ligature, abstract glyph) rendered as an inline
<svg>
matching the page style. Plain text wordmarks for invented brand names look generic.
Always ensure logos render in both light and dark mode (white-on-dark, black-on-light, or single-color theme variable).
LOGO-ONLY rule (mandatory): logo wall = logos and nothing else. Do NOT print industry / category labels below each logo (no
Vercel
+
hosting
underneath, no
Stripe
+
payments
, no
Cloudflare
+
infra
). The logo is the credibility, the label adds nothing the user does not already know. Optional: brand name as alt-text for screen readers, optional link to the brand's site. That is it.
Hand-rolled illustrations:
SVG icons from libraries: fine (see Section 3.C).
Hand-rolled decorative SVGs (custom illustrations, logos, marks): strongly discouraged, never as default. Acceptable only when:
The brief explicitly calls for it ("draw me an SVG logo")
It's a single, simple geometric mark (a square, a circle, a wordmark in display type)
You're confident in the output quality
Div-based fake screenshots are banned. A "hand-built product preview" rendered with
<div>
rectangles, fake task lists, fake dashboards, fake terminal windows is a Tell. If you need to show a product:
Use a real screenshot URL if one exists
Generate one via image tool
Use a real component preview (an actual mini-version of the UI inside the page)
Or skip the preview entirely and use editorial photography
Hero needs a real visual. Text + gradient blob is not a hero - it's a placeholder.
Landing pages live on the first impression, not the full read. Cut ruthlessly.
Default content shape per section: short headline (≤ 8 words) + short sub-paragraph (≤ 25 words) + one visual asset OR one CTA. Anything more must be justified by the section's job.
No data-dump sections. A 20-row publication table, a 30-row award list, a giant pricing matrix on a marketing page = wrong layout. Use:
Top 3-5 highlights + "View full list" link
Marquee / carousel for breadth
Different page entirely if the data is the product
Long lists need a different UI component, not a longer list. Default
<ul>
with bullets /
divide-y
rows is the lazy choice. If you have > 5 items, reach for one of these instead:
2-column split with grouped items
Card grid with image + label per item
Tabs / accordion if items are categorisable
Horizontal scroll-snap pills
Carousel for breadth-heavy lists (testimonials, logos, capabilities)
Marquee for "lots-of-things-that-don't-need-individual-attention"
A spec sheet with 10 rows + a hairline under every row is the WORST default. Either group rows into 2-3 chunks with sparse dividers, or move to a card-per-spec layout.
Spec sheets specifically (the Marrow-cookware pattern). A long product specification table with
border-b
on every row is the AI default for cookware / hardware / apparel / artisan-goods briefs. Banned. Concrete alternatives:
2-col card grid: each spec gets its own card with the spec name, the value (large display number), and a one-line "why it matters" body. Cards arranged 2-col on desktop, 1-col mobile.
Scroll-snap horizontal pills: each spec is a pill, user can flick through.
Grouped chunks: group 10 specs into 3 logical clusters (e.g. "Materials", "Cooking", "Warranty"), each cluster gets ONE soft divider and a cluster heading.
Featured-vs-rest: 3-4 hero specs visualised as large display tiles, the rest collapsed under a "View full specifications" disclosure.
COPY SELF-AUDIT (mandatory before ship): Before declaring any task done, re-read every visible string on the page (headlines, subheads, eyebrows, button labels, body copy, captions, alt text, footer text, error messages). Flag any string that is:
Grammatically broken ("free on its past", "two plans but one is honest", "to put it on the table" out of context)
Has unclear referents ("we plan to stay that way" without prior context)
Sounds like AI hallucination (cute-but-wrong wordplay, forced metaphors that don't track, "elegant nothing" phrases)
Reads like an LLM trying to sound thoughtful (passive-aggressive humility, fake-craftsman labels, mock-poetic micro-meta)
Rewrite every flagged string. If unsure whether a string makes sense, replace it with a plain functional sentence. AI-generated cute copy is worse than boring copy.
Fake-precise numbers are flagged. Numbers like
92%
,
4.1×
,
48k
,
5.8 mm
,
13.4 lb
either:
Come from real data (brief, brand guidelines, public metrics) - fine
Are explicitly labeled as mock (
<!-- mock -->
, "example", "sample data") - fine
Are AI-invented spec aesthetics - banned. Don't fake engineering precision the brand doesn't claim.
One copy register per page. Don't mix technical mono ("47 tasks · 0.6 ctx-switches/day"), editorial prose, and marketing punch in the same composition unless the brand voice explicitly calls for it.
Max 3 lines of quote body. Never 6. If the original quote is longer → cut it. A landing-page quote is a snippet, not the full review.
For very small font sizes (e.g. footer-style testimonials), the line cap can stretch slightly. Spirit: "fits in a glance."
No em-dashes inside the quote text as design flourish (long pauses, kinetic em-dashes, em-dash-bullets). See Section 9.G - em-dash is completely banned.
Attribution: name + role + (optionally) company. Never name only ("- Sarah").
Quote marks: use real typographic quotes ( " " ) or none at all. Not straight ASCII ( " ).
4.11 Page Theme Lock (Light / Dark Mode Consistency)
4.11 页面主题锁定(浅色/深色模式一致性)
The page has ONE theme. Sections do not invert.
If the page is dark mode, ALL sections are dark mode. No light-mode-warm-paper section sandwiched between dark sections (or vice versa). The user must not feel they walked into a different website mid-scroll.
The exception: if the brief explicitly calls for a "Color Block Story" or "Theme Switch on Scroll" device AND that is a deliberate composition (one full theme switch with a strong transition, not random alternation), it is allowed once per page.
Default behaviour: pick light, dark, or auto (
prefers-color-scheme
) at the page level and lock it. Section-level background tints within the same theme family are fine (
bg-zinc-950
next to
bg-zinc-900
); flipping to
bg-amber-50
in the middle of a
bg-zinc-950
page is broken.
When using a design system with built-in theming (Radix Themes, shadcn/ui with
<Theme>
), set the theme ONCE in
layout.tsx
or the page root. Do not let individual sections override.
These are tools, not defaults. Use them when the design read calls for them. None of these fire automatically.
Liquid Glass / Glassmorphism: Appropriate for premium consumer, Apple-adjacent, luxury brand, or media-overlay vibes. Inappropriate for dashboards, public-sector, or "boring B2B." When used, go beyond
backdrop-blur
: add a 1px inner border (
border-white/10
) and a subtle inner shadow (
shadow-[inset_0_1px_0_rgba(255,255,255,0.1)]
) for physical edge refraction. Provide a solid-fill fallback under
prefers-reduced-transparency
.
Magnetic Micro-physics: Use when
MOTION_INTENSITY > 5
AND the brief reads premium / playful / agency. Implement EXCLUSIVELY with Motion's
useMotionValue
/
useTransform
outside the React render cycle. Never
useState
. See Section 3.B.
Perpetual Micro-Interactions (Pulse, Typewriter, Float, Shimmer, Carousel): Use when
MOTION_INTENSITY > 5
AND the section actively benefits from motion (status indicators, live feeds, AI-feel). Not every card needs an infinite loop. If a section is informational, leave it still. Apply Spring Physics (
type: "spring", stiffness: 100, damping: 20
) - no linear easing.
"Motion claimed, motion shown." If
MOTION_INTENSITY > 4
, the page must actually move: entry transitions on hero, scroll-reveal on key sections, hover physics on CTAs, at minimum. A static page that claims
MOTION_INTENSITY: 7
is broken. Conversely, if you cannot ship working motion in the available scope, drop the dial to 3 and ship a clean static page. Never half-build motion that breaks (cut-off ScrollTriggers, jumpy enters, missing cleanups).
MOTION MUST BE MOTIVATED (mandatory). Before adding any animation, ask: "what does this animation communicate?" Valid answers: hierarchy (drawing attention to the right thing), storytelling (revealing content in sequence that matches a narrative), feedback (acknowledging a user action), state transition (showing something changed). Invalid answer: "it looked cool". GSAP everywhere because GSAP is available is amateur. Each ScrollTrigger, each marquee, each pinned section needs a reason. If you cannot articulate the reason in one sentence, drop the animation.
MARQUEE MAX-ONE-PER-PAGE (mandatory). Horizontal scrolling text marquees ("logos endlessly scrolling", "manifesto scrolling sideways", "kinetic word strip") are appropriate at most ONCE per page. Two or more marquees on the same page reads as lazy filler. Pick the one section where the marquee actually serves the content; the others get a different layout.
GSAP Sticky-Stack Pattern (when scroll-stack is used). A "card stack on scroll" must be a REAL sticky-stack, not a sequential reveal list. See Section 5.A below for the canonical code skeleton. Common failure: trigger fires halfway through scroll instead of pinning at viewport top. Fix:
start: "top top"
not
start: "top center"
or
"top 80%"
.
GSAP Horizontal-Pan Pattern (when horizontal scroll-hijack is used). See Section 5.B below for the canonical skeleton. Common failure: animation starts before the section is pinned, so the user sees half a slide. Same fix:
, every card except the last is pinned, the scale/opacity transform is driven by the NEXT card's scroll trigger (so previous card shrinks as next one arrives).
is banned. It runs on every scroll frame, jank-prone, no batching. Use Motion's
useScroll()
, GSAP's
ScrollTrigger
, IntersectionObserver, or CSS
scroll-driven animations
(
animation-timeline: view()
).
Custom scroll progress calculations using
window.scrollY
in React state. Same reason. Re-renders on every frame.
requestAnimationFrame
loops that touch React state. Use motion values (
useMotionValue
+
useTransform
) instead.
Layout Transitions: Use Motion's
layout
and
layoutId
props for visible state changes (re-ordering lists, expanding modals, shared elements between routes). Do not wrap static content in
layout
props "for safety" - it costs measurement work.
Staggered Orchestration: Use
staggerChildren
(Motion) or CSS cascade (
animation-delay: calc(var(--index) * 100ms)
) for reveal moments where sequence matters. For
staggerChildren
, parent (
variants
) and children MUST share the same Client Component tree.
window.addEventListener("scroll", ...)
禁止使用。它在每个滚动帧运行,容易卡顿,无批处理。使用Motion的
useScroll()
、GSAP的
ScrollTrigger
、IntersectionObserver或CSS滚动驱动动画(
animation-timeline: view()
)。
在React状态中使用
window.scrollY
计算自定义滚动进度。原因同上。每次变化都会重新渲染。
requestAnimationFrame
循环修改React状态。改用运动值(
useMotionValue
+
useTransform
)。
布局过渡: 使用Motion的
layout
和
layoutId
属性处理可见状态变化(列表重排、模态框展开、路由间共享元素)。不要为了“安全”将静态内容包裹在
layout
属性中——这会增加测量开销。
交错编排: 使用
staggerChildren
(Motion)或CSS级联(
animation-delay: calc(var(--index) * 100ms)
)处理序列重要的展示时刻。对于
staggerChildren
,父组件(
variants
)和子组件必须共享同一Client Component树。
6. PERFORMANCE & ACCESSIBILITY GUARDRAILS
6. 性能与无障碍防护措施
6.A Hardware Acceleration
6.A 硬件加速
Animate ONLY
transform
and
opacity
. Never animate
top
,
left
,
width
,
height
.
Use
will-change: transform
sparingly - only on elements that will actually animate.
仅对
transform
和
opacity
设置动画。绝不对
top
、
left
、
width
、
height
设置动画。
谨慎使用
will-change: transform
——仅对实际会动画的元素使用。
6.B Reduced Motion (mandatory)
6.B 减少动效(强制要求)
Any motion above
MOTION_INTENSITY > 3
MUST honor
prefers-reduced-motion
. This is non-negotiable.
In Motion: wrap with
useReducedMotion()
and degrade to static.
In CSS: gate animations behind
@media (prefers-reduced-motion: no-preference)
or provide an override block under
@media (prefers-reduced-motion: reduce)
that disables.
Infinite loops, parallax, scroll-hijack, and magnetic physics MUST collapse to static / instant under reduced motion.
任何
MOTION_INTENSITY > 3
的动效必须尊重
prefers-reduced-motion
。这是不可协商的。
在Motion中:用
useReducedMotion()
包裹并降级为静态。
在CSS中:将动画放在
@media (prefers-reduced-motion: no-preference)
中,或在
@media (prefers-reduced-motion: reduce)
下提供禁用动画的覆盖块。
无限循环、视差、滚动劫持和磁吸物理效果在减少动效模式下必须降级为静态/即时效果。
6.C Dark Mode (mandatory for any consumer-facing page)
6.C 深色模式(面向消费者的页面强制要求)
Design for both modes from the start. Never ship light-only or dark-only without explicit user instruction.
Use Tailwind
dark:
variant OR CSS variables for tokens. Pick one strategy per project.
Do not prescribe specific dark-mode colors here. The brief decides. Maintain visual hierarchy, brand identity, and WCAG AA contrast (AAA for body) across both modes.
Respect
prefers-color-scheme: dark
. Default to system preference unless the brand insists on one mode.
unless the brand insists. Add a manual toggle if either mode would lose key brand expression.
除非品牌坚持,否则尊重
prefers-color-scheme
。如果任一模式会丢失关键品牌表达,添加手动切换按钮。
8.D Test in Both Modes Before Finishing
8.D 完成前在两种模式下测试
Open the page in both modes during development. Do not ship a page you've only seen in one mode.
开发过程中在两种模式下打开页面。绝不交付仅在一种模式下查看过的页面。
9. AI TELLS (Forbidden Patterns)
9. AI特征(禁止模式)
Avoid these signatures unless the brief explicitly asks for them.
除非需求明确要求,否则避免这些特征。
9.A Visual & CSS
9.A 视觉与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.
默认禁止霓虹/外发光。使用内边框或微妙的 tinted阴影。
禁止纯黑色(
#000000
)。使用米黑、zinc-950或炭黑色。
禁止过度饱和的强调色。降低饱和度以融入中性色。
禁止大标题使用过多渐变文本。
禁止自定义鼠标光标。过时、无障碍不友好、性能不友好。
9.B Typography
9.B 排版
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.
默认避免使用Inter。见第4.1节。存在例外路径。
禁止过大的H1。通过字重+颜色控制层级,而非单纯缩放。
衬线字体约束: 衬线字体用于社论/奢华/出版物。不用于仪表盘。
9.C Layout & Spacing
9.C 布局与间距
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.
These patterns came out of real LLM-generated landing-page tests. They are the signatures the model defaults to when it tries to "look designed." Treat them as hard bans unless the brief explicitly calls for one.
Hero & top-of-page
NO version labels in the hero.
V0.6
,
v2.0
,
BETA
,
INVITE-ONLY PREVIEW
,
EARLY ACCESS
,
ALPHA
- banned as default eyebrows. Only acceptable when the brief is explicitly about a product launch / preview status.
NO "Brand · No. 01"-style sub-eyebrows. "Marrow · No. 01 · The 6-quart" type micro-meta lines. Skip them.
Section numbering & micro-labels
NO section-number eyebrows.
00 / INDEX
,
001 · Capabilities
,
002 · Featured commission
,
06 · how it works
,
05 · The honest table
- banned. Eyebrows should name the topic in plain language, not enumerate.
NO
01 / 4
-style pagination on images or bento tiles. If the user can count, they don't need the label.
NO
Scroll · 001 Capabilities
-style scroll cues. A simple arrow or "Scroll" is enough; no section-number prefix.
NO "Index of Work, 2018 - 2026"-style range labels as eyebrows. Just say what the section is.
Separators & dots
The middle-dot (
·
) is rationed. Maximum 1 per line in metadata strips. Do NOT use it as the default separator for everything ("foo · bar · baz · qux · quux"). If you need a separator family, prefer line breaks, hairlines, or columns.
NO decorative colored status dots on every list/nav/badge. A colored dot before "ONE Q4 SLOT OPEN" or before every nav link, or every task row - banned by default. Acceptable only when the dot conveys actual semantic state (a server status, an availability flag) and is used sparingly.
Em-dashes & typography flourishes
NO em-dash (
—
) as a design element OR anywhere else. See Section 9.G below for the complete, non-negotiable ban. The em-dash character is forbidden in headlines, eyebrows, pills, body copy, quotes, attribution, captions, button text, and alt text. Use the regular hyphen (
-
).
NO
<br>
-broken-and-italicized headlines as a default "design move." "for thirty<br>years." type splits. Headlines should read naturally first, get clever only when the brief demands it.
NO vertical rotated text ("INDEX OF WORK, 2018 - 2026" rotated 90°). Agency-portfolio cliché. Use it only when the brief is explicitly agency / Awwwards / experimental AND it serves a real composition purpose.
NO crosshair / hairline grid lines as decoration. Vertical and horizontal lines drawn just to make the page "feel designed" - banned. Use them only when they organize real content.
Fake product previews
NO div-based fake product UI in the hero (fake task list, fake terminal, fake dashboard built from styled divs). It is the #1 LLM-design Tell. Use a real screenshot, a generated image, a real component preview, or none at all.
NO fake version footers ("v0.6.2-rc.1", "last sync 4s ago · main") inside fake screenshots. Adds nothing, screams AI.
Marketing-copy Tells
NO "Quietly in use at" / "Quietly trusted by" social-proof headers. Use natural language: "Trusted by", "Used at", "Customers include", or skip the heading entirely if the logos speak.
NO "From the field" / "Field notes" / "Currently on the bench" / "On our desks" / "Loose plates" style poetic labels on quote, blog, or sidebar sections. Reads as performative-craftsman. Use plain functional labels ("Testimonials", "Latest writing", "Now working on") or skip the label.
NO "We respect the French ones"-style mock-humble industry-references in body copy. Cute and AI-y.
NO weather / locale strips ("LIS 14:23 · 18°C") in headers/footers unless the brief is explicitly about a place / time-zone-distributed studio.
NO micro-meta-sentences under eyebrows. Sentences like "Each of these is a feature we ship today, not a roadmap promise. The list will stay short on purpose." sitting under a section heading are clutter. Eyebrow + Headline + Body is enough.
NO generic step labels. "Stage 1 / Stage 2 / Stage 3", "Step 1 / Step 2 / Step 3", "Phase 01 / Phase 02 / Phase 03", "Pass One / Pass Two / Pass Three". Banned. The actual step content is the label. If you must show progression, use the verb-noun directly ("Install", "Configure", "Ship") not "Stage 1: Install".
Pills, labels and version stamps
NO pills/labels/tags overlaid on images. No
<span>
overlays on photos with tags like
Brand · 02
,
PLATE · BRAND
,
Field notes - journal
. Either let the image speak alone, or add a caption directly below (outside the image).
NO photo-credit captions as decoration. Strings like
Field study no. 12 · Ines Caetano
,
Plate 03 · House archive
,
Frame XII · 35mm
under stock/picsum images are pretentious. Photo credit is allowed ONLY when there is a real photographer being credited for a real photo (with permission). Otherwise: skip the caption or use a one-line functional caption ("The 6-quart, in Sage.").
NO version footers on marketing pages. Footer strings like
v1.4.2
,
Build 0048
,
last sync 4s ago · main
are CLI / devtool fixtures, not landing-page content. Banned on marketing/landing/portfolio pages.
NO "Reservation 412 of 800"-style live-stock counters as decoration. Only if the brief is explicitly a limited-run waitlist with real data.
Decoration text strips
NO decoration text strip at hero bottom. Patterns like
BRAND. MOTION. SPATIAL.
,
TYPE / FORM / MOTION
,
DESIGN · BUILD · SHIP
,
ESTD. 2018 · LISBON · BRAND. MOTION. SPATIAL.
as a small mono-caps strip across the bottom of the hero are an agency-portfolio cliché. Banned by default. Only acceptable when the strip carries real, navigable links (sticky bottom nav) or real status info (cookie banner, build info on a docs site).
NO floating top-right sub-text in section headings. Pattern: section has a giant left-aligned headline; in the top-right corner of the same section header there is a small explainer paragraph floating with no clear alignment to anything else. That floater is the Tell. Either put the sub-text directly under the headline, or build a clean 2-column header (left: headline, right: aligned body), but not a tiny corner paragraph.
Lists, dividers and scoring
NO
border-t
+
border-b
on every row of a long list / spec table. Pick one (bottom-border between rows OR top-border above the group) and use it sparsely. A 10-row spec table with hairlines under each row is the laziest layout - see Section 4.9 for alternative UI components.
NO scoring/progress bars with filled background tracks as comparison visuals. If you need to show "X out of Y" comparisons, prefer a number + small icon, or a tiny inline bar WITHOUT a background track. Big filled
bg-zinc-200
tracks with a partial fill on top are dashboard-UI clutter on a landing page.
Locale, time, scroll cues
Locale / city-name / time / weather strips are banned for 99% of briefs. "Lisbon, working with founders" in the hero, "1200-690 Lisbon, Portugal" in the footer, "Lisbon 14:23 · 18°C" in the nav. These are agency-portfolio decoration tells. Allowed ONLY when: the brief explicitly describes a globally-distributed studio with timezone-relevant work, OR a travel-focused brand, OR a real-world physical venue. A single contact-address mention in the footer is fine; an atmospheric locale strip is not.
Scroll cues are banned.
Scroll
,
↓ scroll
,
Scroll to explore
,
Scroll to walk through it
, animated mouse-wheel icons. If the user has not scrolled yet, they are looking at the hero. They know what scroll is. The bottom of the viewport does not need a label.
ZERO decorative status dots by default. A coloured dot before nav items, before list rows, before badges, before status labels is a Tell. Only acceptable when conveying real semantic state (a live indicator on actual server status, a live availability flag) and limited to one per page section.
禁止假截图中的假版本页脚(“v0.6.2-rc.1”、“last sync 4s ago · main”)。毫无意义,暴露AI生成特征。
营销文案特征
禁止“Quietly in use at”/“Quietly trusted by”社交证明标题。使用自然语言:“Trusted by”、“Used at”、“Customers include”,或如果Logo足够有说服力,完全跳过标题。
禁止“From the field”/“Field notes”/“Currently on the bench”/“On our desks”/“Loose plates”风格的诗意标签用于引用、博客或侧边栏区域。听起来像刻意的工匠风格。使用平实的功能性标签(“Testimonials”、“Latest writing”、“Now working on”)或跳过标签。
禁止“We respect the French ones”风格的假谦逊行业引用正文。可爱但充满AI特征。
禁止眉题下的微元句子。像*“Each of these is a feature we ship today, not a roadmap promise. The list will stay short on purpose.”*这样的句子位于区域标题下方,属于杂乱内容。眉题+标题+正文就足够了。
禁止使用带填充背景轨道的评分/进度条作为对比视觉。如果需要展示“X out of Y”对比,优先使用数字+小图标,或不带背景轨道的小型内联条。大型填充
bg-zinc-200
轨道搭配部分填充,在着陆页上属于仪表盘UI杂乱内容。
区域、时间、滚动提示
区域/城市名称/时间/天气条99%的需求禁止使用。Hero中的“Lisbon, working with founders”、页脚中的“1200-690 Lisbon, Portugal”、导航中的“Lisbon 14:23 · 18°C”。这些是代理机构作品集装饰特征。仅当以下情况时允许:需求明确描述全球分布的工作室且时区相关工作,或旅游品牌,或真实物理场所。页脚中提及单个联系地址是可以的;氛围区域条不行。
) is COMPLETELY banned. It is the LLM's signature stylistic crutch and it is the #1 visual Tell in production tests. There is no "limited use" allowance, no "natural language frequency" allowance, no "in body copy is fine" allowance. None.
Banned in headlines. Use a period or a comma.
Banned in eyebrows / labels / pills / button text / image captions / nav items. Replace with line breaks, columns, or hairlines.
Banned in body copy. Restructure the sentence: two sentences with a period, OR a comma, OR parentheses, OR a colon.
Banned in quote attribution. Use a normal hyphen with spaces (
-
) or a line break + smaller-weight name.
Banned in en-dash form too (
–
) when used as a separator. Date ranges (
2018-2026
) use a hyphen. Number ranges (
€40-80k
) use a hyphen.
The ONLY permitted dash characters on the page are:
Regular hyphen
-
(for compound words, ranges, line dividers in markup)
Minus sign in math (
-5°C
)
If your output contains a single
—
or
–
anywhere visible to the user, the output fails the Pre-Flight Check and must be rewritten.
This rule is non-negotiable. The agent has historically ignored em-dash limits when phrased as "use sparingly." The phrasing here is binary: zero em-dashes.
10. REFERENCE VOCABULARY (Pattern Names the Agent Should Know)
10. 参考词汇(Agent应了解的模式名称)
This is a vocabulary, not a library. The agent should KNOW these pattern names to communicate about them, design with them in mind, and reach for them when the design read calls for them. Implementations and code sketches live in the Block Library (Section 12), which is populated iteratively.
---name: asymmetric-split-hero
category: hero
dial_compatibility:variance:[6,10]motion:[3,10]density:[2,5]when_to_use:"Landing pages with one strong asset and one strong message. Default hero for SaaS, agency, premium consumer."not_for:"Editorial / manifesto launches where the message IS the design."stack:["react","next","tailwind","motion"]---
Every block must work standalone (drop it into a page, it renders).
Every block must pass the Pre-Flight Check (Section 14).
Blocks that depend on a design system from Section 2.A live under
blocks/<category>/<name>--<system>.md
(e.g.
feature/bento-grid--material.md
).
每个文件一个块。不要多块文件。
每个块必须可独立工作(放入页面即可渲染)。
每个块必须通过预发布检查(第14节)。
依赖第2.A节设计系统的块放在
blocks/<category>/<name>--<system>.md
下(如
feature/bento-grid--material.md
)。
13. OUT OF SCOPE
13. 超出范围
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.
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)?
APPENDICES - Real Source-Backed Reference Material
附录 - 真实来源支持的参考资料
The sections below are vendored reference content. They give the agent real install commands, real canonical doc links, and real working starter snippets for each design system named in Section 2. Use them to ground decisions in production reality, not training-data fiction.
Appendix C - Apple Liquid Glass: Honest Web Approximation
附录C - Apple液态玻璃:诚实的Web近似实现
Do not treat random CSS snippets as official Apple Liquid Glass.
不要将随机CSS片段视为官方Apple液态玻璃。
What is official
什么是官方的
Apple documents Liquid Glass inside Apple's Human Interface Guidelines and Developer Documentation for Apple platforms. It is a dynamic material used across Apple platform UI. Apple's native implementation belongs to Apple platform APIs and system components, not a public web CSS package.
Relevant official docs:
Apple Human Interface Guidelines → Materials
Apple Developer Documentation → Liquid Glass
Apple Developer Documentation → Adopting Liquid Glass
has uneven browser support; test it. Always provide enough contrast even without blur.
End of appendices. Install commands above are reality anchors. The Apple Liquid Glass skeleton is a labeled approximation, not an Apple-issued package. For canonical docs per design system, consult the system's official docs (links in Section 2 plus Appendix B).