vercel-geist-design-system

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Vercel Geist Design System

Vercel Geist设计系统

Use this community-authored skill to make interfaces feel like they belong in Vercel's Geist design system: precise, calm, high-contrast, developer-focused, and production-ready. Treat the official Geist pages as the source of truth. This skill is not official Vercel guidance, and it is a style and implementation contract, not permission to copy Vercel product screens wholesale.

使用这款社区编写的技能，让界面贴合Vercel的Geist设计系统风格：精准、沉稳、高对比度、面向开发者且具备生产就绪能力。以官方Geist文档作为唯一权威来源。本技能并非Vercel官方指导，而是一份风格与实现约定，不允许直接复制Vercel产品界面。

Default App Policy

默认应用规则

Use this skill as the default visual operating mode for any frontend app, site, page, component, dashboard, or UI polish work unless the user explicitly names a non-Geist final visual system/art direction as the final visual authority, supplies a non-Geist design artifact as the final visual authority, or asks for game/illustrative output where Geist UI is not the requested surface. Generic requests such as "clean", "modern", "premium", "beautiful", "polished", "SaaS", or "developer tool" still use Geist.

Apply Geist style to the entire app surface: app shell, navigation, pages, forms, data views, dialogs, empty states, loading states, errors, toasts, command menus, and marketing sections.
Scope is explicit. For greenfield apps, full redesigns, or broad UI polish requests, "entire app surface" means all routable app surfaces and shared states must be built or audited. For a narrow existing-project task, migrate the requested workflow and any shared primitives it touches; the final response must say
```
whole app not verified
```
unless every route/surface was audited.
Do not create isolated Vercel-looking components inside an otherwise unrelated visual system. Establish shared tokens and primitives first, then build every new surface from them.
If broader creative design guidance also applies, this skill owns the visual system whenever it is triggered. Treat generic frontend-design directives such as bold aesthetic direction, unforgettable visuals, unexpected layouts, distinctive font pairing, gradient meshes, dramatic shadows, textures, scroll-triggered spectacle, and surprising motion as disabled for Vercel/Geist work unless the user explicitly overrides Geist.
If the user explicitly names another non-Geist final visual system/art direction as the final visual authority, such as Material, Apple, Linear, Stripe, Notion, a supplied non-Geist design artifact explicitly designated by the user as the final visual authority, or game/illustrative output where Geist UI is not the requested surface, respect that request and do not force Geist. Domain, industry, brand, product, company, API, integration, content subject, Tailwind, shadcn, Radix, or component library mentions are not visual-system overrides; for example, a Stripe webhook dashboard still uses Geist unless the user asks for Stripe-style visuals.
Use the official Geist docs as the reference for every matching foundation or component before inventing a custom pattern.

除非用户明确指定非Geist的最终视觉系统/设计方向作为权威标准、提供非Geist设计制品作为权威依据，或要求制作游戏/插画类输出且Geist UI并非所需界面，否则本技能应作为所有前端应用、网站、页面、组件、仪表盘或UI优化工作的默认视觉操作模式。诸如“简洁”“现代”“高端”“美观”“精致”“SaaS”或“开发者工具”等通用请求仍需使用Geist风格。

将Geist风格应用于整个应用界面：应用外壳、导航、页面、表单、数据视图、对话框、空状态、加载状态、错误状态、提示框、命令菜单以及营销板块。
范围明确。对于全新应用、全面重设计或大范围UI优化请求，“整个应用界面”意味着所有可路由的应用界面和共享状态都必须构建或审核。对于现有项目中的窄范围任务，迁移请求的工作流及其涉及的所有共享原语；除非审核了每个路由/界面，否则最终响应必须标注
```
whole app not verified
```
。
不得在无关视觉系统中创建孤立的类Vercel组件。应先建立共享令牌和原语，再基于它们构建所有新界面。
如果同时适用更广泛的创意设计指导，触发本技能时，视觉系统由本技能主导。对于Vercel/Geist相关工作，除非用户明确覆盖Geist规则，否则诸如大胆美学方向、令人难忘的视觉效果、非常规布局、独特字体搭配、渐变网格、夸张阴影、纹理、滚动触发特效和惊喜动效等通用前端设计指令均不生效。
如果用户明确指定其他非Geist最终视觉系统/设计方向作为权威标准（如Material、Apple、Linear、Stripe、Notion），提供用户指定为权威依据的非Geist设计制品，或要求制作游戏/插画类输出且Geist UI并非所需界面，则需尊重该请求，不得强制使用Geist。领域、行业、品牌、产品、公司、API、集成、内容主题、Tailwind、shadcn、Radix或组件库的提及并不构成视觉系统覆盖；例如，Stripe webhook仪表盘仍需使用Geist，除非用户要求Stripe风格的视觉效果。
在自定义模式之前，需参考官方Geist文档中对应的基础或组件内容。

Reference-First Contract

优先参考约定

The linked Geist docs are the design system. This skill is the enforcement layer that makes the agent use them.

Do not rely only on this skill summary for design decisions when official docs are available.
Before implementing any UI that creates or materially changes rendered output, consult the official Vercel Font page plus Geist Introduction, Colors, Typography, Materials, and Guidelines pages.
Before implementing a specific UI pattern, consult the matching Geist component page from the reference map. A docs fallback is allowed only after attempting the required official URL in the current turn using every available browsing/docs tool.
If current docs remain unavailable after those attempts, state the attempted URLs, tools, and exact failure mode. During blocked-doc fallback, local rules in this skill are advisory only; they cannot satisfy
```
Docs Evidence
```
, cannot support strict/docs-verified claims, and cannot be enforced as source-of-truth visual rules. If a needed decision has no current official source trace, mark that decision blocked and do not enforce an invented local visual rule. Shell/package-manager network failure alone is not enough if web/browser access exists. Do not use the fallback merely because the reference map, memory, or existing class names seem sufficient. When any required official page could not be read, label the result as
```
local Geist fallback, not docs-verified
```
; do not claim strict Geist, official Geist compliance, source-of-truth alignment, or Vercel Taste Gate passage for affected surfaces unless all required docs, screenshot checks, and interaction checks were completed.
Do not treat using Geist fonts or class names as sufficient. The visual result must match the Geist/Vercel product language: restrained, precise, systematic, dense when useful, and visually coherent across every surface.
If a generated design looks only generically "SaaS" or "clean" but not recognizably Vercel/Geist, revise it before finishing.
The final UI should be judged as a product system, not a single screen: tokens, shell, navigation, controls, data displays, dialogs, feedback, and states must all belong together.

链接的Geist文档即为设计系统。本技能是确保代理使用该设计系统的执行层。

当官方文档可用时，不得仅依赖本技能摘要做出设计决策。
在实现任何会创建或实质性更改渲染输出的UI之前，需查阅官方Vercel Font页面以及Geist介绍、颜色、排版、材质和指南页面。
在实现特定UI模式之前，需查阅参考映射中对应的Geist组件页面。仅当在当前回合尝试使用所有可用浏览/文档工具访问所需官方URL均失败时，才允许使用文档回退方案。
如果尝试后当前文档仍不可用，需说明尝试的URL、工具和具体失败模式。在文档受阻回退期间，本技能中的本地规则仅作为参考；它们无法满足
```
Docs Evidence
```
要求，无法支持严格/文档验证的声明，也不能作为权威视觉规则强制执行。如果所需决策没有当前官方来源记录，需标记该决策受阻，不得强制执行自定义的本地视觉规则。仅当没有网页/浏览器访问权限时，Shell/包管理器网络故障才构成有效受阻理由。不得仅因参考映射、记忆或现有类名看似足够而使用回退方案。当任何所需官方页面无法读取时，需将结果标记为
```
local Geist fallback, not docs-verified
```
；除非完成了所有所需文档、截图检查和交互检查，否则不得声称受影响界面符合严格Geist、官方Geist合规、权威对齐或通过Vercel品味审核。
不得仅将使用Geist字体或类名视为合规。视觉结果必须匹配Geist/Vercel产品语言：克制、精准、系统化、必要时紧凑，且所有界面在视觉上保持连贯。
如果生成的设计仅看起来是通用“SaaS”或“简洁”风格，而非可识别的Vercel/Geist风格，需在完成前进行修改。
最终UI应作为产品系统进行评判，而非单个屏幕：令牌、外壳、导航、控件、数据展示、对话框、反馈和状态必须保持统一。

Required Workflow

必要工作流

Identify the surface type: marketing hero, product dashboard, settings page, table/list view, command workflow, docs, or component library.
Check the existing project first: framework, Tailwind version, component library, icon library, font setup, theme tokens, and existing design-system conventions.
Open and read the required foundation pages for the surface, then complete the Foundation Gate before any screen-level work in this order: fonts, semantic color tokens, typography utilities, material/radius utilities, focus rings, shared app shell, component primitives, shared state system, and screen composition rules.
Do not edit route/page/screen-level styles until those shared layers are present in real app entrypoints, theme files, primitives, and app shell components.
Map every UI requirement to the closest Geist foundation or component, then open and read each matching official page before creating a custom pattern.
Prefer established packages and project primitives over custom implementations. For complex accessible primitives, use headless Radix primitives or existing shadcn code only as behavior/accessibility infrastructure after the Geist mapping pass; never import shadcn/Radix visual defaults, themes, or variants as design authority.
When implementing or composing any UI pattern, consult the matching official Geist page first. Use this skill's Official Reference Map only to locate the official URL, or as fallback after every available browsing/docs tool fails for the required official URLs in the current turn. In fallback mode, state that live docs were not checked, include exact failure modes, choose the closest official component conservatively, and treat local rules as advisory rather than enforceable source-of-truth requirements. When any required official page could not be read, label the result as
```
local Geist fallback, not docs-verified
```
; do not claim strict Geist, official Geist compliance, source-of-truth alignment, or Vercel Taste Gate passage for affected surfaces unless all required docs, screenshot checks, and interaction checks were completed.
Follow the host project's language, framework, package-management, and validation conventions.

识别界面类型：营销首屏、产品仪表盘、设置页面、表格/列表视图、命令工作流、文档或组件库。
首先检查现有项目：框架、Tailwind版本、组件库、图标库、字体设置、主题令牌和现有设计系统约定。
打开并阅读该界面所需的基础页面，然后按以下顺序完成基础审核后再进行屏幕级工作：字体、语义颜色令牌、排版工具、材质/圆角工具、焦点环、共享应用外壳、组件原语、共享状态系统和屏幕组合规则。
除非这些共享层已在实际应用入口、主题文件、原语和应用外壳组件中存在，否则不得编辑路由/页面/屏幕级样式。
将每个UI需求映射到最接近的Geist基础或组件，然后在创建自定义模式之前打开并阅读每个对应的官方页面。
优先使用已确立的包和项目原语，而非自定义实现。对于复杂的可访问原语，仅在完成Geist映射后将无头Radix原语或现有shadcn代码作为行为/可访问性基础设施使用；不得将shadcn/Radix的视觉默认值、主题或变体作为设计权威导入。
在实现或组合任何UI模式时，首先查阅对应的官方Geist页面。仅在定位官方URL时使用本技能的官方参考映射，或在当前回合尝试所有可用浏览/文档工具访问所需官方URL均失败后作为回退方案。在回退模式下，需说明未检查实时文档，包含具体失败模式，保守选择最接近的官方组件，并将本地规则视为参考而非可强制执行的权威要求。当任何所需官方页面无法读取时，需将结果标记为
```
local Geist fallback, not docs-verified
```
；除非完成了所有所需文档、截图检查和交互检查，否则不得声称受影响界面符合严格Geist、官方Geist合规、权威对齐或通过Vercel品味审核。
遵循宿主项目的语言、框架、包管理和验证约定。

Official Source-Of-Truth Gate

官方权威审核

For any task using this skill, current official Vercel docs are binding design input, not optional inspiration. Before visual implementation, open the relevant official pages for foundations, components, brand assets, and guidelines. Do not rely on memory, screenshots, generic SaaS heuristics, or Tailwind class names when an official Geist page covers the decision.

Required pages by decision type:

Foundations:

https://vercel.com/geist/introduction

https://vercel.com/geist/colors

https://vercel.com/geist/typography

https://vercel.com/geist/materials

https://vercel.com/font

Guidelines:
```
https://vercel.com/design/guidelines
```
Brand/logo/assets:
```
https://vercel.com/geist/brands
```
Components: every concrete matching component URL from the reference map or live Geist component nav, such as
```
https://vercel.com/geist/button
```

If a listed page redirects or cannot be loaded, do not treat it as source of truth. Use the closest accessible official Vercel page only as supplemental context and state the fallback. The original required URL remains

blocked

unless that exact official page or anchor was read; a substitute page cannot satisfy source-of-truth verification for the blocked required page.

For any task using this skill that creates, changes, critiques, specifies, or materially directs rendered UI, the final response must include a

Docs Evidence

table with one row for every required official page for the task, not merely pages claimed as consulted: all required foundation pages, the guidelines page, every mapped component page, and brand/assets pages when brand or logo decisions are made. Use columns:

official URL | status (consulted/blocked/not applicable) | exact official section/anchor | short exact quote or exact failure mode | implementation target | concrete decision/change | verification

. Keep any quote short, source-specific, and compliant with source quotation limits. Foundation and guidelines rows can be only

consulted

blocked

. Component rows split into required applied rows and adjacent rejected rows: rows for components actually implemented, restyled, or required by custom-pattern mapping can be only

consulted

blocked

; adjacent checked-and-rejected component rows can be

not applicable

only with a rejection reason and do not block strict claims by themselves. Brand/assets rows are required only when brand or logo decisions are made. A required applied page is blocked only if every available browsing/docs tool was tried in the current turn and the row names the tools and exact failures. A final answer may not claim Geist, strict Geist, docs-aligned Geist, source-of-truth verification, or Vercel Taste Gate passage if any required applied row is missing, blocked, lacks an exact section/anchor, or lacks a page-specific short quote that affected a concrete decision; if any required source is blocked, the only allowed claim for affected surfaces is

local Geist fallback, not docs-verified

. Strict Geist, docs-verified Geist, docs-aligned Geist, official Geist compliance, and source-of-truth alignment require complete

Docs Evidence

plus screenshot and interaction checks when those checks are possible. If screenshots or interaction checks are blocked, allowed wording is limited to

docs consulted; visual/interaction verification blocked

对于使用本技能的任何任务，当前官方Vercel文档是具有约束力的设计输入，而非可选灵感。在视觉实现之前，需打开相关的官方基础、组件、品牌资产和指南页面。当官方Geist页面涵盖相关决策时，不得依赖记忆、截图、通用SaaS启发法或Tailwind类名。

按决策类型划分的必要页面：

基础：

https://vercel.com/geist/introduction

https://vercel.com/geist/colors

https://vercel.com/geist/typography

https://vercel.com/geist/materials

https://vercel.com/font

指南：
```
https://vercel.com/design/guidelines
```
品牌/Logo/资产：
```
https://vercel.com/geist/brands
```
组件：参考映射或实时Geist组件导航中的每个具体对应组件URL，例如
```
https://vercel.com/geist/button
```

如果列出的页面重定向或无法加载，不得将其视为权威来源。仅将最接近的可访问官方Vercel页面作为补充上下文使用，并说明回退方案。除非读取了确切的官方页面或锚点，否则原始所需URL仍视为

blocked

；替代页面无法满足受阻所需页面的权威验证要求。

对于使用本技能创建、更改、评判、指定或实质性指导渲染UI的任何任务，最终响应必须包含

Docs Evidence

表格，每行对应任务所需的每个官方页面，而非仅声称查阅过的页面：所有必要的基础页面、指南页面、每个映射组件页面，以及涉及品牌或Logo决策时的品牌/资产页面。表格列：

official URL | 状态（已查阅/受阻/不适用） | 确切官方章节/锚点 | 简短确切引用或确切失败模式 | 实现目标 | 具体决策/更改 | 验证

。引用需简短、来源明确，并符合来源引用限制。基础和指南行只能是

已查阅

或

受阻

。组件行分为已应用的必要行和相邻的已拒绝行：实际实现、重新设计或自定义模式映射所需的组件行只能是

已查阅

或

受阻

；已检查并拒绝的相邻组件行仅在提供拒绝理由时可标记为

不适用

，且本身不会阻止严格声明。仅在涉及品牌或Logo决策时才需要品牌/资产行。仅当在当前回合尝试了所有可用浏览/文档工具且行中注明了工具和具体失败时，已应用的必要页面才视为受阻。如果任何已应用的必要行缺失、受阻、缺少确切章节/锚点，或缺少影响具体决策的页面特定简短引用，则最终答案不得声称符合Geist、严格Geist、文档对齐Geist、权威验证或通过Vercel品味审核；如果任何所需来源受阻，受影响界面仅允许声明

local Geist fallback, not docs-verified

。严格Geist、文档验证Geist、文档对齐Geist、官方Geist合规和权威对齐要求完整的

Docs Evidence

，以及在可能的情况下进行截图和交互检查。如果截图或交互检查受阻，允许的表述仅限于

已查阅文档；视觉/交互验证受阻

。

Companion Skills Routing

配套技能路由

These Skills.sh entries can help route work, but they are not design-system source of truth and they do not satisfy

Docs Evidence

. Official Vercel Geist docs, Vercel Font, Geist Brands, Geist component pages, and Vercel Web Interface Guidelines remain the only design-system authorities for strict Geist claims.

```
geist
```
: use
```
https://www.skills.sh/vercel-labs/vercel-plugin/geist
```
only for Geist Sans, Geist Mono, Geist Pixel, package installation, and font import guidance. Still verify
```
https://vercel.com/font
```
for strict Geist work.
```
geistdocs
```
: use
```
https://www.skills.sh/vercel-labs/vercel-plugin/geistdocs
```
only when the task is a documentation site, MDX/Fumadocs surface, or Geistdocs configuration. It does not replace the Geist foundation, component, brand, or Web Interface Guidelines checks for rendered docs UI.
```
web-design-guidelines
```
: use
```
https://www.skills.sh/vercel-labs/agent-skills/web-design-guidelines
```
as an audit helper when installed or accessible. It may route an audit against the latest Web Interface Guidelines, but the official guideline source remains
```
https://vercel.com/design/guidelines
```
, and findings must still be reconciled with Geist foundations/components. If the helper is unavailable, use the official page's Integrate with Agents fallback and fetch the raw command prompt directly from
```
https://raw.githubusercontent.com/vercel-labs/web-interface-guidelines/main/command.md
```
when network access allows. Skills.sh and raw GitHub prompts may only route or run an audit helper; they cannot supply design-system authority, cannot satisfy
```
Docs Evidence
```
, and cannot replace reading
```
https://vercel.com/design/guidelines
```
in the current turn.
```
geist-learning-lab
```
: use
```
https://www.skills.sh/vercel-labs/skill-geist-learning-labs/geist-learning-lab
```
only for interactive learning, tutorial, lab, or training products. Do not apply learning-loop, dark-first, or tutorial-specific rules to ordinary apps, dashboards, sites, or docs.
```
create-remotion-geist
```
: use
```
https://www.skills.sh/vercel-labs/skill-remotion-geist/create-remotion-geist
```
only for Remotion videos, motion graphics, or video-generation tasks. Do not apply video-specific dark-theme, spring-animation, or Remotion entrypoint rules to normal web UI.

这些Skills.sh条目可帮助路由工作，但它们并非设计系统权威来源，也无法满足

Docs Evidence

要求。官方Vercel Geist文档、Vercel Font、Geist Brands、Geist组件页面和Vercel Web Interface Guidelines仍是严格Geist声明的唯一设计系统权威。

```
geist
```
：仅将
```
https://www.skills.sh/vercel-labs/vercel-plugin/geist
```
用于Geist Sans、Geist Mono、Geist Pixel、包安装和字体导入指导。严格Geist工作仍需验证
```
https://vercel.com/font
```
。
```
geistdocs
```
：仅当任务是文档站点、MDX/Fumadocs界面或Geistdocs配置时，使用
```
https://www.skills.sh/vercel-labs/vercel-plugin/geistdocs
```
。它无法替代Geist基础、组件、品牌或Web Interface Guidelines对渲染文档UI的检查。
```
web-design-guidelines
```
：当已安装或可访问时，将
```
https://www.skills.sh/vercel-labs/agent-skills/web-design-guidelines
```
作为审核辅助工具。它可能会根据最新的Web Interface Guidelines进行审核，但官方指南来源仍是
```
https://vercel.com/design/guidelines
```
，且发现的问题仍需与Geist基础/组件协调。如果辅助工具不可用，当网络允许时，使用官方页面的Integrate with Agents回退方案，并直接从
```
https://raw.githubusercontent.com/vercel-labs/web-interface-guidelines/main/command.md
```
获取原始命令提示。Skills.sh和原始GitHub提示仅可路由或运行审核辅助工具；它们无法提供设计系统权威，无法满足
```
Docs Evidence
```
要求，也无法替代在当前回合读取
```
https://vercel.com/design/guidelines
```
。
```
geist-learning-lab
```
：仅将
```
https://www.skills.sh/vercel-labs/skill-geist-learning-labs/geist-learning-lab
```
用于交互式学习、教程、实验或培训产品。不得将学习循环、优先深色模式或教程特定规则应用于普通应用、仪表盘、网站或文档。
```
create-remotion-geist
```
：仅将
```
https://www.skills.sh/vercel-labs/skill-remotion-geist/create-remotion-geist
```
用于Remotion视频、动态图形或视频生成任务。不得将视频特定的深色主题、弹簧动画或Remotion入口规则应用于普通Web UI。

Foundation Gate

基础审核

For any task that creates or materially changes rendered UI, complete the Geist foundation layer before screen design or screen implementation. For tiny primitive-only fixes, verify the touched primitive still composes these foundations. Do not design or implement individual screens until these foundations are present, wired through the real app entrypoints, and used by shared primitives.

Fonts: install or use the host project's Geist asset setup. In Next.js, prefer the
```
geist
```
package and wire Geist Sans and Geist Mono variables in the root layout. Add Geist Pixel variables from
```
geist/font/pixel
```
only when a constrained display/brand accent is actually used. Apply Sans to the app root, reserve Mono for code, command text, shortcuts, technical identifiers, versions, environment variables, commit hashes, terminal/log output, and official mono classes, and keep Pixel out of ordinary product UI text. Numeric product data should use Sans label/copy utilities with tabular numeric treatment unless the consulted Typography page or existing Geist-mapped primitive maps that context to Mono.
Tokens: define a single semantic token layer for backgrounds, foregrounds, muted text, borders, rings, destructive, success, warning, link, and info states. Optional accent aliases must resolve to a specific official Geist role or scale for focus, selection, link, or status. Map these tokens to Geist Background 1/2, component backgrounds 1-3, borders 4-6, high-contrast backgrounds 7-8, and text/icons 9-10.
Typography: define or map reusable Geist typography utilities before writing screen copy styles:
```
text-heading-*
```
,
```
text-button-*
```
,
```
text-label-*
```
,
```
text-copy-*
```
, mono variants, and tabular numeric treatment. Screen files should not rely on ad hoc
```
text-sm
```
,
```
font-bold
```
, arbitrary line heights, or arbitrary tracking for primary hierarchy.
Materials and radii: define shared material utilities or variants for
```
material-base
```
,
```
material-small
```
,
```
material-medium
```
,
```
material-large
```
,
```
material-tooltip
```
,
```
material-menu
```
,
```
material-modal
```
, and
```
material-fullscreen
```
. Define radius tokens/utilities for the Geist scale: 6px, 12px, and 16px. Do not use arbitrary large radii or one-off
```
rounded-*
```
choices in screen files.
Focus rings: define one app-wide focus-visible treatment using the project semantic
```
ring
```
token mapped to a specific consulted Geist color role/scale. Treat the focus-ring behavior as an accessibility implementation rule verified separately through the Vercel Web Interface Guidelines, not as a Geist foundation token or source-of-truth rule. All interactive primitives must consume that treatment instead of inventing per-component outline, box-shadow, or ring styles.
App shell: create or verify a shared app shell before screen work: root background, content gutters, navigation/header/sidebar structure when needed, dividers, max-width behavior, mobile behavior, and one clear primary action zone per view.
Component primitives: create or verify the shared primitives needed by the work before composing screens. At minimum, route new UI through Geist-styled primitives for Button/IconButton, Input/Textarea, Select/Combobox when needed, Checkbox/Radio/Switch, Tabs, Modal/Sheet/Drawer, Menu/Tooltip, Toast/Feedback, Table/List, Empty/Error/Loading/Skeleton states, Surface/Material, and AppShell. Composition primitives are not official Geist components: IconButton must follow Button icon-only/svg-only guidance; List must map to Table, Entity, Description, Scroller, or Show More; Surface/Panel/AppShell must be built from Grid, Material, Menu/Tabs/Drawer/Sheet as applicable and pass the custom-pattern gate.
State system: create or verify shared state variants/primitives before screen work for hover, active/pressed, selected/current, disabled, loading, empty, error, validation, focus-visible, and reduced-motion behavior. Screen files must consume these shared state APIs/classes instead of defining state styles locally.
Screen composition rule: screens must compose the shared Geist tokens, typography, materials, focus rings, app shell, primitives, and state system. Do not create one-off screen-local visual systems unless the existing project architecture explicitly requires that location for the shared implementation.

对于任何创建或实质性更改渲染UI的任务，需在屏幕设计或实现之前完成Geist基础层工作。对于微小的仅原语修复，需验证所修改的原语仍能组合这些基础。除非这些基础已存在、通过实际应用入口连接并被共享原语使用，否则不得设计或实现单个屏幕。

字体：安装或使用宿主项目的Geist资产设置。在Next.js中，优先使用
```
geist
```
包，并在根布局中配置Geist Sans和Geist Mono变量。仅当实际使用受限显示/品牌强调时，才从
```
geist/font/pixel
```
添加Geist Pixel变量。将Sans应用于应用根目录，将Mono保留用于代码、命令文本、快捷键、技术标识符、版本、环境变量、提交哈希、终端/日志输出和官方mono类，且不得在普通产品UI文本中使用Pixel。数字产品数据应使用Sans标签/复制工具并采用表格数字处理，除非查阅的排版页面或现有Geist映射原语将该上下文映射到Mono。
令牌：为背景、前景、弱化文本、边框、环、破坏性、成功、警告、链接和信息状态定义单个语义令牌层。可选的强调别名必须解析为特定的官方Geist角色或缩放比例，用于焦点、选择、链接或状态。将这些令牌映射到Geist Background 1/2、组件背景1-3、边框4-6、高对比度背景7-8和文本/图标9-10。
排版：在编写屏幕复制样式之前，定义或映射可复用的Geist排版工具：
```
text-heading-*
```
,
```
text-button-*
```
,
```
text-label-*
```
,
```
text-copy-*
```
, mono变体和表格数字处理。屏幕文件不得依赖临时的
```
text-sm
```
、
```
font-bold
```
、任意行高或任意字间距来构建主要层级。
材质和圆角：为
```
material-base
```
、
```
material-small
```
、
```
material-medium
```
、
```
material-large
```
、
```
material-tooltip
```
、
```
material-menu
```
、
```
material-modal
```
和
```
material-fullscreen
```
定义共享材质工具或变体。为Geist缩放比例定义圆角令牌/工具：6px、12px和16px。屏幕文件中不得使用任意大的圆角或一次性
```
rounded-*
```
选择。
焦点环：使用项目语义
```
ring
```
令牌映射到特定查阅的Geist颜色角色/缩放比例，定义一个应用范围的focus-visible处理方式。将焦点环行为视为可访问性实现规则，需通过Vercel Web Interface Guidelines单独验证，而非Geist基础令牌或权威规则。所有交互式原语必须使用该处理方式，而非为每个组件自定义轮廓、框阴影或环样式。
应用外壳：在屏幕工作之前创建或验证共享应用外壳：根背景、内容边距、必要时的导航/页眉/侧边栏结构、分隔线、最大宽度行为、移动端行为，以及每个视图的一个明确的主要操作区域。
组件原语：在组合屏幕之前创建或验证工作所需的共享原语。至少需将新UI路由到Geist风格的原语，包括Button/IconButton、Input/Textarea、必要时的Select/Combobox、Checkbox/Radio/Switch、Tabs、Modal/Sheet/Drawer、Menu/Tooltip、Toast/Feedback、Table/List、Empty/Error/Loading/Skeleton状态、Surface/Material和AppShell。组合原语并非官方Geist组件：IconButton必须遵循Button仅图标/仅SVG指南；List必须映射到Table、Entity、Description、Scroller或Show More；Surface/Panel/AppShell必须根据情况基于Grid、Material、Menu/Tabs/Drawer/Sheet构建，并通过自定义模式审核。
状态系统：在屏幕工作之前创建或验证共享状态变体/原语，用于悬停、激活/按下、选中/当前、禁用、加载、空、错误、验证、focus-visible和减少动效行为。屏幕文件必须使用这些共享状态API/类，而非在本地定义状态样式。
屏幕组合规则：屏幕必须组合共享的Geist令牌、排版、材质、焦点环、应用外壳、原语和状态系统。除非现有项目架构明确要求在该位置进行共享实现，否则不得创建一次性屏幕本地视觉系统。

Geist Essence

Geist核心特质

The target feel is a restrained developer-tool interface:

Neutral-first, high-contrast, accessible surfaces.
Typography and spacing do most of the hierarchy work.
Color is functional: status, focus, selection, destructive state, success, warning, links, and sparse brand accents.
Layouts are orderly, dense where useful, and easy to scan repeatedly.
Borders are hairline structure, not decoration.
Motion is short, subtle, and state-driven.
Empty space is intentional, not a substitute for missing product thinking.
Copy is concrete and operational. Avoid marketing fluff inside product UI.

目标风格是克制的开发者工具界面：

优先中性色、高对比度、可访问的界面。
排版和间距是构建层级的主要方式。
颜色具有功能性：用于状态、焦点、选择、破坏性状态、成功、警告、链接和少量品牌强调。
布局有序，必要时紧凑，便于反复扫描。
边框是细线结构，而非装饰。
动效简短、微妙且由状态驱动。
空白是有意设计的，而非替代缺失的产品思考。
文案具体且可操作。产品UI中避免营销话术。

Official Reference Map

官方参考映射

Use the non-redirecting official Vercel pages below as source-of-truth references. Redirect-only resources are listed only for routing/drift awareness and do not satisfy

Docs Evidence

unless they become non-redirecting official pages in the current turn.

Main:
```
https://vercel.com/geist/introduction
```

Foundations:

https://vercel.com/font

https://vercel.com/geist/introduction

https://vercel.com/geist/colors

https://vercel.com/geist/typography

https://vercel.com/geist/materials

Guidelines:
```
https://vercel.com/design/guidelines
```

Resources: these current resource URLs redirect to

https://vercel.com/geist/introduction

and do not satisfy

Docs Evidence

unless they become non-redirecting official pages in the current turn:

https://vercel.com/geist/icons

https://vercel.com/geist/geistcn-upgrade-guide

https://vercel.com/geist/geistcn-assets-guide

https://vercel.com/geist/geistcn-icons

https://vercel.com/geist/geistcn-logos

https://vercel.com/geist/guidelines

https://vercel.com/geist/changelog

Brands:

https://vercel.com/geist/brands

https://vercel.com/geist/brands#vercel

https://vercel.com/geist/brands#next-js

https://vercel.com/geist/brands#next-js-spelling

https://vercel.com/geist/brands#turbo

https://vercel.com/geist/brands#turborepo

https://vercel.com/geist/brands#turbopack

https://vercel.com/geist/brands#v0

https://vercel.com/geist/brands#ai-sdk

https://vercel.com/geist/brands#usage

https://vercel.com/geist/brands#misuse

Legacy/resource caution: do not rely on

https://vercel.com/geist/icons

https://vercel.com/geist/geistcn-upgrade-guide

https://vercel.com/geist/geistcn-assets-guide

https://vercel.com/geist/geistcn-icons

https://vercel.com/geist/geistcn-logos

https://vercel.com/geist/guidelines

, or

https://vercel.com/geist/changelog

as source-of-truth pages unless they resolve to non-redirecting official pages during the current task.

Components:

Avatar:
```
https://vercel.com/geist/avatar
```
Badge:
```
https://vercel.com/geist/badge
```
Book:
```
https://vercel.com/geist/book
```
Browser:
```
https://vercel.com/geist/browser
```
Button:
```
https://vercel.com/geist/button
```
Calendar:
```
https://vercel.com/geist/calendar
```
Checkbox:
```
https://vercel.com/geist/checkbox
```
Choicebox:
```
https://vercel.com/geist/choicebox
```
Code Block:
```
https://vercel.com/geist/code-block
```
Collapse:
```
https://vercel.com/geist/collapse
```
Combobox:
```
https://vercel.com/geist/combobox
```
Command Menu:
```
https://vercel.com/geist/command-menu
```
Context Card:
```
https://vercel.com/geist/context-card
```
Context Menu:
```
https://vercel.com/geist/context-menu
```
Description:
```
https://vercel.com/geist/description
```

Destructive Action Modal:

https://vercel.com/geist/destructive-action-modal

Drawer:
```
https://vercel.com/geist/drawer
```
Empty State:
```
https://vercel.com/geist/empty-state
```
Entity:
```
https://vercel.com/geist/entity
```
Error:
```
https://vercel.com/geist/error
```
Feedback:
```
https://vercel.com/geist/feedback
```
Gauge:
```
https://vercel.com/geist/gauge
```
Grid:
```
https://vercel.com/geist/grid
```
Input:
```
https://vercel.com/geist/input
```
Keyboard Input:
```
https://vercel.com/geist/keyboard-input
```
Loading Dots:
```
https://vercel.com/geist/loading-dots
```
Material:
```
https://vercel.com/geist/material
```
Menu:
```
https://vercel.com/geist/menu
```

MiddleTruncate:

https://vercel.com/geist/middle-truncate

Modal:
```
https://vercel.com/geist/modal
```
Multi Select:
```
https://vercel.com/geist/multi-select
```
Note:
```
https://vercel.com/geist/note
```
Pagination:
```
https://vercel.com/geist/pagination
```
Phone:
```
https://vercel.com/geist/phone
```
Pill:
```
https://vercel.com/geist/badge#pill
```
Progress:
```
https://vercel.com/geist/progress
```
Project Banner:
```
https://vercel.com/geist/project-banner
```
Radio:
```
https://vercel.com/geist/radio
```

Relative Time Card:

https://vercel.com/geist/relative-time-card

Scroller:
```
https://vercel.com/geist/scroller
```
Select:
```
https://vercel.com/geist/select
```
Sheet:
```
https://vercel.com/geist/sheet
```
Show More:
```
https://vercel.com/geist/show-more
```
Skeleton:
```
https://vercel.com/geist/skeleton
```
Slider:
```
https://vercel.com/geist/slider
```
Snippet:
```
https://vercel.com/geist/snippet
```
Spinner:
```
https://vercel.com/geist/spinner
```
Split Button:
```
https://vercel.com/geist/split-button
```
Status Dot:
```
https://vercel.com/geist/status-dot
```
Switch:
```
https://vercel.com/geist/switch
```
Table:
```
https://vercel.com/geist/table
```
Tabs:
```
https://vercel.com/geist/tabs
```
Textarea:
```
https://vercel.com/geist/textarea
```
Theme Switcher:
```
https://vercel.com/geist/theme-switcher
```
Toast:
```
https://vercel.com/geist/toast
```
Toggle:
```
https://vercel.com/geist/toggle
```
Tooltip:
```
https://vercel.com/geist/tooltip
```

Components: open the concrete matching component URL from the map below, for example
```
https://vercel.com/geist/button
```
; never use a placeholder URL. Prefer the reference map or live nav URL for anchor/subcomponent entries such as Pill.

使用以下非重定向的官方Vercel页面作为权威参考。仅重定向的资源仅用于路由/漂移感知，除非在当前回合它们变为非重定向官方页面，否则无法满足

Docs Evidence

要求。

主页面：
```
https://vercel.com/geist/introduction
```

基础：

https://vercel.com/font

https://vercel.com/geist/introduction

https://vercel.com/geist/colors

https://vercel.com/geist/typography

https://vercel.com/geist/materials

指南：
```
https://vercel.com/design/guidelines
```

资源：以下当前资源URL重定向到

https://vercel.com/geist/introduction

，除非在当前回合它们变为非重定向官方页面，否则无法满足

Docs Evidence

要求：

https://vercel.com/geist/icons

https://vercel.com/geist/geistcn-upgrade-guide

https://vercel.com/geist/geistcn-assets-guide

https://vercel.com/geist/geistcn-icons

https://vercel.com/geist/geistcn-logos

https://vercel.com/geist/guidelines

https://vercel.com/geist/changelog

。

品牌：

https://vercel.com/geist/brands

https://vercel.com/geist/brands#vercel

https://vercel.com/geist/brands#next-js

https://vercel.com/geist/brands#next-js-spelling

https://vercel.com/geist/brands#turbo

https://vercel.com/geist/brands#turborepo

https://vercel.com/geist/brands#turbopack

https://vercel.com/geist/brands#v0

https://vercel.com/geist/brands#ai-sdk

https://vercel.com/geist/brands#usage

https://vercel.com/geist/brands#misuse

遗留/资源注意事项：除非在当前任务中它们解析为非重定向官方页面，否则不得依赖

https://vercel.com/geist/icons

https://vercel.com/geist/geistcn-upgrade-guide

https://vercel.com/geist/geistcn-assets-guide

https://vercel.com/geist/geistcn-icons

https://vercel.com/geist/geistcn-logos

https://vercel.com/geist/guidelines

或

https://vercel.com/geist/changelog

作为权威页面。

组件：

Avatar:
```
https://vercel.com/geist/avatar
```
Badge:
```
https://vercel.com/geist/badge
```
Book:
```
https://vercel.com/geist/book
```
Browser:
```
https://vercel.com/geist/browser
```
Button:
```
https://vercel.com/geist/button
```
Calendar:
```
https://vercel.com/geist/calendar
```
Checkbox:
```
https://vercel.com/geist/checkbox
```
Choicebox:
```
https://vercel.com/geist/choicebox
```
Code Block:
```
https://vercel.com/geist/code-block
```
Collapse:
```
https://vercel.com/geist/collapse
```
Combobox:
```
https://vercel.com/geist/combobox
```
Command Menu:
```
https://vercel.com/geist/command-menu
```
Context Card:
```
https://vercel.com/geist/context-card
```
Context Menu:
```
https://vercel.com/geist/context-menu
```
Description:
```
https://vercel.com/geist/description
```

Destructive Action Modal:

https://vercel.com/geist/destructive-action-modal

Drawer:
```
https://vercel.com/geist/drawer
```
Empty State:
```
https://vercel.com/geist/empty-state
```
Entity:
```
https://vercel.com/geist/entity
```
Error:
```
https://vercel.com/geist/error
```
Feedback:
```
https://vercel.com/geist/feedback
```
Gauge:
```
https://vercel.com/geist/gauge
```
Grid:
```
https://vercel.com/geist/grid
```
Input:
```
https://vercel.com/geist/input
```
Keyboard Input:
```
https://vercel.com/geist/keyboard-input
```
Loading Dots:
```
https://vercel.com/geist/loading-dots
```
Material:
```
https://vercel.com/geist/material
```
Menu:
```
https://vercel.com/geist/menu
```

MiddleTruncate:

https://vercel.com/geist/middle-truncate

Modal:
```
https://vercel.com/geist/modal
```
Multi Select:
```
https://vercel.com/geist/multi-select
```
Note:
```
https://vercel.com/geist/note
```
Pagination:
```
https://vercel.com/geist/pagination
```
Phone:
```
https://vercel.com/geist/phone
```
Pill:
```
https://vercel.com/geist/badge#pill
```
Progress:
```
https://vercel.com/geist/progress
```
Project Banner:
```
https://vercel.com/geist/project-banner
```
Radio:
```
https://vercel.com/geist/radio
```

Relative Time Card:

https://vercel.com/geist/relative-time-card

Scroller:
```
https://vercel.com/geist/scroller
```
Select:
```
https://vercel.com/geist/select
```
Sheet:
```
https://vercel.com/geist/sheet
```
Show More:
```
https://vercel.com/geist/show-more
```
Skeleton:
```
https://vercel.com/geist/skeleton
```
Slider:
```
https://vercel.com/geist/slider
```
Snippet:
```
https://vercel.com/geist/snippet
```
Spinner:
```
https://vercel.com/geist/spinner
```
Split Button:
```
https://vercel.com/geist/split-button
```
Status Dot:
```
https://vercel.com/geist/status-dot
```
Switch:
```
https://vercel.com/geist/switch
```
Table:
```
https://vercel.com/geist/table
```
Tabs:
```
https://vercel.com/geist/tabs
```
Textarea:
```
https://vercel.com/geist/textarea
```
Theme Switcher:
```
https://vercel.com/geist/theme-switcher
```
Toast:
```
https://vercel.com/geist/toast
```
Toggle:
```
https://vercel.com/geist/toggle
```
Tooltip:
```
https://vercel.com/geist/tooltip
```

组件：打开下方映射中的具体对应组件URL，例如
```
https://vercel.com/geist/button
```
；不得使用占位符URL。对于锚点/子组件条目（如Pill），优先使用参考映射或实时导航URL。

Layout Rules

布局规则

Product apps should open directly into the usable workspace, not a marketing landing page.
Dashboards should favor a clear primary workflow, quiet secondary controls, and compact information density.
Use full-width page bands or unframed layouts for sections. Do not put page sections inside decorative cards.
Cards are for repeated items, modals, individual panels, and genuine framed tools. Do not nest cards inside cards.
Use a predictable grid and stable dimensions for toolbars, boards, tables, counters, and repeated tiles.
Local implementation heuristic, not
```
Docs Evidence
```
: when the project lacks an official spacing token source, use a restrained 4px-compatible rhythm such as 8, 12, 16, 20, 24, 32, 48, and 64 to preserve compact Geist composition. If official or project Geist-mapped spacing tokens exist, use those instead.
Keep page gutters responsive: about 16px on mobile, 24px on tablet, 32px on desktop, with a sensible max-width for reading surfaces.
Do not let hover, loading, selected, or error states resize components or shift layout.
Tables and logs should use tight rows, clear column alignment, sticky headers when useful, and monospaced numerals/IDs.
Verify layout at mobile, laptop, desktop, and ultra-wide viewport widths. Zooming out may supplement visual review, but it is never a substitute for recorded ultra-wide viewport screenshot evidence when Browser or Playwright can set the viewport.
Respect safe-area insets with
```
env(safe-area-inset-*)
```
for fixed headers, bottom bars, drawers, sheets, and full-screen surfaces.
Test with scrollbars always visible when possible. Fix unwanted horizontal or nested scrollbars; only render scrollbars that serve an intentional workflow.
Prefer flex/grid/intrinsic CSS layout over JavaScript measurement. Avoid layout thrash by letting CSS handle flow, wrapping, and alignment.
Align deliberately to a grid, baseline, edge, or optical center. Allow deliberate +/-1px optical alignment when perception beats geometry, and balance text/icon lockups for contrast, weight, size, and spacing.

产品应用应直接打开到可用工作区，而非营销着陆页。
仪表盘应优先清晰的主要工作流、安静的次要控件和紧凑的信息密度。
对板块使用全宽页面栏或无框布局。不得将页面板块放在装饰性卡片内。
卡片用于重复项、模态框、单个面板和真正的框架工具。不得在卡片内嵌套卡片。
对工具栏、看板、表格、计数器和重复磁贴使用可预测的网格和稳定尺寸。
本地实现启发法，非
```
Docs Evidence
```
：当项目缺少官方间距令牌来源时，使用克制的4px兼容节奏，如8、12、16、20、24、32、48和64，以保持紧凑的Geist组合。如果存在官方或项目Geist映射的间距令牌，则使用这些令牌。
保持页面边距响应式：移动端约16px，平板端24px，桌面端32px，阅读界面设置合理的最大宽度。
不得让悬停、加载、选中或错误状态调整组件大小或改变布局。
表格和日志应使用紧凑行、清晰的列对齐、必要时的粘性表头，以及等宽数字/ID。
在移动端、笔记本电脑、桌面端和超宽视口宽度下验证布局。缩小视图可辅助视觉检查，但当Browser或Playwright可设置视口时，绝不能替代记录的超宽视口截图证据。
对固定页眉、底部栏、抽屉、面板和全屏界面使用
```
env(safe-area-inset-*)
```
尊重安全区域内边距。
尽可能在滚动条始终可见的情况下测试。修复不必要的水平或嵌套滚动条；仅渲染服务于有意工作流的滚动条。
优先使用flex/grid/固有CSS布局，而非JavaScript测量。避免布局抖动，让CSS处理流、换行和对齐。
有意对齐到网格、基线、边缘或视觉中心。当感知优于几何时，允许有意的±1px视觉对齐，并平衡文本/图标组合的对比度、粗细、大小和间距。

Color Rules

颜色规则

Follow the Geist color model:

Background 1: default page and component background.
Background 2: secondary background, used sparingly for subtle separation.
Colors 1-3: component backgrounds. Map Color 1/2/3 to default/hover/active only when the component owns a component background. If the rest state is Background 1, use Color 1 for hover and Color 2 for active. Small badges may use Color 2 or Color 3 as their background.
Colors 4-6: borders: default, hover, active.
Colors 7-8: high-contrast component backgrounds and hover states.
Colors 9-10: accessible secondary and primary text/icons.

Implementation guidance:

When defining custom CSS/Tailwind tokens, prefer raw Geist scale variables first: Background 1/2 plus the applicable official Color 1-10 steps for each used scale. If the project already exposes official Geist/Core tokens or generated CSS variables, map semantic aliases to those without duplicating the raw layer. Semantic names are local aliases, not Geist source tokens.
Use current Colors page values for Background 1/2, Colors 4-6 for borders, and Colors 9-10 for text/icons; do not choose arbitrary near-neutral values unless mapping an existing project token to those official roles.
In dark mode, map to the same official Geist roles rather than inventing a separate near-black palette.
Use alpha grays for subtle hover/focus layers when the project token system supports them.
Status colors are allowed only for status: red/destructive, amber/warning, green/success, blue/info/link, teal/purple/pink only when the product meaning requires them.
```
accent
```
must alias a specific official Geist role or scale for focus, selection, link, or status; default/primary actions must follow the consulted Button/component page rather than a broad accent token. Never create decorative accent colors.
For charts and status-heavy views, use redundant cues such as labels, shape, texture, icon, or position alongside color. Use color-blind-friendly palettes and verify contrast with APCA where available.
Hover, active, and focus states should increase contrast over the rest state instead of becoming softer or less legible.
Do not build a one-note purple/blue gradient interface.
Do not use decorative gradient orbs, bokeh blobs, glassy rainbow panels, or loud shadows.
Do not make color carry meaning alone; pair it with text, icon, shape, or state.

遵循Geist颜色模型：

Background 1：默认页面和组件背景。
Background 2：次要背景，仅用于微妙分隔。
Colors 1-3：组件背景。仅当组件拥有组件背景时，将Color 1/2/3映射到默认/悬停/激活状态。如果静止状态为Background 1，则使用Color 1作为悬停状态，Color 2作为激活状态。小型徽章可使用Color 2或Color 3作为背景。
Colors 4-6：边框：默认、悬停、激活。
Colors 7-8：高对比度组件背景和悬停状态。
Colors 9-10：可访问的次要和主要文本/图标。

实现指导：

定义自定义CSS/Tailwind令牌时，优先使用原始Geist缩放变量：Background 1/2加上每个使用的缩放比例对应的官方Color 1-10步骤。如果项目已公开官方Geist/Core令牌或生成的CSS变量，则将语义别名映射到这些变量，无需复制原始层。语义名称是本地别名，而非Geist源令牌。
使用当前颜色页面中的Background 1/2、Colors 4-6（边框）和Colors 9-10（文本/图标）的值；除非将现有项目令牌映射到这些官方角色，否则不得选择任意近中性值。
在深色模式下，映射到相同的官方Geist角色，而非发明单独的近黑色调色板。
当项目令牌系统支持时，使用透明度灰色作为微妙的悬停/焦点层。
状态颜色仅可用于状态：红色/破坏性、琥珀色/警告、绿色/成功、蓝色/信息/链接，仅当产品含义需要时才使用蓝绿色/紫色/粉色。
```
accent
```
必须别名特定的官方Geist角色或缩放比例，用于焦点、选择、链接或状态；默认/主要操作必须遵循查阅的Button/组件页面，而非宽泛的强调令牌。不得创建装饰性强调色。
对于图表和状态密集的视图，除颜色外，使用冗余提示，如标签、形状、纹理、图标或位置。使用色盲友好的调色板，并在可用时通过APCA验证对比度。
悬停、激活和焦点状态应比静止状态提高对比度，而非变得更柔和或更难辨认。
不得构建单一色调的紫色/蓝色渐变界面。
不得使用装饰性渐变球体、散景 blob、玻璃彩虹面板或夸张阴影。
不得仅让颜色承载含义；需将其与文本、图标、形状或状态配对。

Typography Rules

排版规则

Use the full Geist type family when available:

Geist Sans: headings, body text, navigation, buttons, forms, tables, dialogs.
Geist Mono: code, command text, shortcuts, IDs, versions, environment variables, commit hashes, terminal/log output, and inline technical tokens. Metrics, prices, timestamps, and numeric columns should use the official label/copy typography utility with tabular numeric treatment first; use Mono only when the consulted Typography page or an existing Geist-mapped primitive maps that context to a mono class.
Geist Pixel: local restraint, not Vercel Font source-of-truth usage guidance. Use it sparingly for one intentional display/brand moment such as a wordmark, small campaign lockup, highly constrained hero accent, banner accent, or constrained dashboard/product accent. Never use it for body copy, dense tables, forms, settings copy, navigation, long headings, metric grids, or ordinary dashboard/product text unless current official Pixel or Font guidance explicitly supports that exact use.

In Next.js with the

geist

package, import Pixel variants from

geist/font/pixel

GeistPixelSquare

GeistPixelGrid

GeistPixelCircle

GeistPixelTriangle

, and

GeistPixelLine

Use the official Geist type categories:

Headings introduce pages or sections.
Buttons use button-specific text styles only inside button components.
Labels are single-line UI text with generous enough line-height to align with icons.
Copy is for multiline text.

Use official Geist Tailwind typography classes first. If the project lacks these classes, add or map them through the project's Tailwind/theme/CSS token layer before building new UI. Raw font-size, line-height, letter-spacing, and font-weight values may appear only inside named Geist typography utility definitions, using installed Geist/Core CSS values or computed official class values gathered during the current docs pass.

The following typography names are implementation mappings only. They do not satisfy the docs gate and must not be used as proof unless the official Typography page was opened, read, and influenced the implementation in the current turn.

Headings:

text-heading-72

text-heading-64

text-heading-56

text-heading-48

text-heading-40

text-heading-32

text-heading-24

text-heading-20

text-heading-16

text-heading-14

Buttons:
```
text-button-16
```
,
```
text-button-14
```
,
```
text-button-12
```
. Use these only inside button components.

Labels:

text-label-20

text-label-18

text-label-16

text-label-14

text-label-14-mono

text-label-13

text-label-13-mono

text-label-12

text-label-12-mono

Copy:

text-copy-24

text-copy-20

text-copy-18

text-copy-16

text-copy-14

text-copy-13

text-copy-13-mono

Use descendant
```
<strong>
```
inside a Geist typography class for Strong treatment.
Use Subtle modifiers only through the project's official Geist class/token implementation. Do not fake subtle text by making it unreadably gray.
Use tabular numeric treatment for numeric label styles. If the project lacks it, add a named tabular utility to the relevant Geist label/copy utility; use Geist Mono only for official mono classes or technical/code-like content.

Official usage guidance:

```
text-heading-72
```
: marketing heroes.
```
text-heading-32
```
: marketing subheadings, paragraphs, and dashboard headings.
```
text-button-14
```
: default button text.
```
text-button-12
```
: tiny button inside an input field.
```
text-label-14
```
: most common label/menu text style.
```
text-label-13
```
: secondary line next to labels; use tabular alignment when conveying numbers.
```
text-label-12
```
: tertiary text in busy views, Show More, comments, and calendar capitals.
```
text-copy-16
```
: simpler larger views such as modals.
```
text-copy-14
```
: most common copy style.
```
text-copy-13
```
: secondary copy or dense views.
```
text-copy-13-mono
```
: inline code mentions.

Fallback when official classes are absent:

Define named
```
text-heading-*
```
,
```
text-button-*
```
,
```
text-label-*
```
, and
```
text-copy-*
```
mapped equivalents before writing screen styles.
The mapped equivalents must preserve the official category, size, line-height, letter-spacing, and weight relationships from the Typography page, installed Geist/Core CSS, or computed values from the current official docs pass.
Raw sizes are allowed only inside those shared typography utility definitions. Route, page, screen, and feature files must consume the named utilities and must not use broad ad hoc heading/body/button size ranges as proof of Geist typography.

Typography constraints:

Do not default an entire interface to
```
text-base
```
.
Do not make every heading bold. Prefer medium/semi-bold and hierarchy through size, spacing, and placement.
Do not use negative letter spacing globally. Apply tight tracking only to large display/headline text if the existing system does.
Keep long-form prose readable; do not use Geist Mono for paragraphs.
Use
```
tabular-nums
```
for metrics, timestamps, table numbers, and counters.

在可用时使用完整的Geist字体家族：

Geist Sans：标题、正文文本、导航、按钮、表单、表格、对话框。
Geist Mono：代码、命令文本、快捷键、ID、版本、环境变量、提交哈希、终端/日志输出和内联技术令牌。指标、价格、时间戳和数字列应首先使用官方标签/复制排版工具并采用表格数字处理；仅当查阅的排版页面或现有Geist映射原语将该上下文映射到mono类时，才使用Mono。
Geist Pixel：本地克制使用，而非Vercel Font权威使用指导。仅将其用于一个有意的显示/品牌时刻，如标志、小型活动组合、高度受限的首屏强调、横幅强调或受限的仪表盘/产品强调。不得将其用于正文文本、密集表格、表单、设置文案、导航、长标题、指标网格或普通仪表盘/产品文本，除非当前官方Pixel或Font指南明确支持该确切用途。

在使用

geist

包的Next.js中，从

geist/font/pixel

导入Pixel变体：

GeistPixelSquare

GeistPixelGrid

GeistPixelCircle

GeistPixelTriangle

, 和

GeistPixelLine

。

使用官方Geist类型类别：

标题用于介绍页面或板块。
按钮仅在按钮组件内使用特定的按钮文本样式。
标签是单行UI文本，行高足够与图标对齐。
复制用于多行文本。

优先使用官方Geist Tailwind排版类。如果项目缺少这些类，在构建新UI之前，通过项目的Tailwind/主题/CSS令牌层添加或映射它们。原始字体大小、行高、字间距和字体粗细值仅可出现在命名的Geist排版工具定义中，使用已安装的Geist/CSS值或在当前文档查阅期间收集的计算出的官方类值。

以下排版名称仅为实现映射。它们无法满足文档审核要求，除非在当前回合打开、阅读并影响了实现，否则不得作为证明。

标题：

text-heading-72

text-heading-64

text-heading-56

text-heading-48

text-heading-40

text-heading-32

text-heading-24

text-heading-20

text-heading-16

text-heading-14

。

按钮：
```
text-button-16
```
,
```
text-button-14
```
,
```
text-button-12
```
。仅在按钮组件内使用这些样式。

标签：

text-label-20

text-label-18

text-label-16

text-label-14

text-label-14-mono

text-label-13

text-label-13-mono

text-label-12

text-label-12-mono

。

复制：

text-copy-24

text-copy-20

text-copy-18

text-copy-16

text-copy-14

text-copy-13

text-copy-13-mono

。

在Geist排版类内使用后代
```
<strong>
```
标签实现加粗处理。
仅通过项目的官方Geist类/令牌实现使用弱化修饰符。不得通过将文本设置为难以辨认的灰色来伪造弱化文本。
对数字标签样式使用表格数字处理。如果项目缺少该功能，为相关的Geist标签/复制工具添加命名的表格工具；仅对官方mono类或技术/代码类内容使用Geist Mono。

官方使用指导：

```
text-heading-72
```
：营销首屏。
```
text-heading-32
```
：营销副标题、段落和仪表盘标题。
```
text-button-14
```
：默认按钮文本。
```
text-button-12
```
：输入字段内的小型按钮。
```
text-label-14
```
：最常见的标签/菜单文本样式。
```
text-label-13
```
：标签旁的次要行；传达数字时使用表格对齐。
```
text-label-12
```
：繁忙视图中的三级文本、Show More、评论和日历大写文本。
```
text-copy-16
```
：更简单的大型视图，如模态框。
```
text-copy-14
```
：最常见的复制样式。
```
text-copy-13
```
：次要复制或密集视图。
```
text-copy-13-mono
```
：内联代码提及。

官方类缺失时的回退方案：

在编写屏幕样式之前，定义命名的
```
text-heading-*
```
,
```
text-button-*
```
,
```
text-label-*
```
, 和
```
text-copy-*
```
映射等效项。
映射等效项必须保留排版页面、已安装的Geist/Core CSS或当前官方文档查阅期间计算出的值中的官方类别、大小、行高、字间距和粗细关系。
原始大小仅允许出现在这些共享排版工具定义中。路由、页面、屏幕和功能文件必须使用命名工具，不得使用宽泛的临时标题/正文/按钮大小范围作为Geist排版的证明。

排版约束：

不得将整个界面默认设置为
```
text-base
```
。
不得让所有标题都加粗。优先使用中等/半粗体，并通过大小、间距和位置构建层级。
不得全局使用负字间距。仅当现有系统已使用时，才对大型显示/标题文本应用紧凑字距。
保持长篇散文可读性；不得对段落使用Geist Mono。
对指标、时间戳、表格数字和计数器使用
```
tabular-nums
```
。

App-Wide Setup

应用范围设置

This section is an implementation checklist for the mandatory Foundation Gate; it cannot narrow, delay, or exempt any Foundation Gate requirement.

For any task that creates or materially changes rendered UI, create or verify the shared Geist foundation before styling individual screens, routes, pages, or feature components.

Fonts: use Geist Sans and Geist Mono through the host project's font setup. In Next.js, prefer the
```
geist
```
package with
```
geist/font/sans
```
and
```
geist/font/mono
```
; add
```
geist/font/pixel
```
only when a constrained display/brand accent is actually used.
Root layout: apply Geist Sans as the default UI font, expose Geist Mono for code, command text, shortcuts, technical identifiers, versions, environment variables, commit hashes, terminal/log output, and official mono classes, and expose Geist Pixel variables only for constrained display accents. Numeric product data should stay in Sans label/copy utilities with tabular numeric treatment unless the consulted Typography page or an existing Geist-mapped primitive maps that context to Mono.
Typography: define or map the official
```
text-heading-*
```
,
```
text-button-*
```
,
```
text-label-*
```
, and
```
text-copy-*
```
classes. New components and screens must use these classes or mapped equivalents; raw
```
text-sm
```
,
```
font-bold
```
, arbitrary line-height, and arbitrary tracking are allowed only inside shared token/utility definitions or inside third-party/generated code that cannot consume project utilities. The final response must name the file, constraint, and why a mapped utility was impossible.
Colors: define semantic tokens for
```
background
```
,
```
foreground
```
,
```
muted-foreground
```
,
```
border
```
,
```
ring
```
,
```
accent
```
,
```
link
```
,
```
info
```
,
```
destructive
```
,
```
success
```
, and
```
warning
```
, mapped to Background 1/2, component backgrounds 1-3, borders 4-6, high-contrast backgrounds 7-8, and text/icons 9-10. Components should consume semantic tokens, not hard-coded grays.
Materials: define or map
```
material-base
```
,
```
material-small
```
,
```
material-medium
```
,
```
material-large
```
,
```
material-tooltip
```
,
```
material-menu
```
,
```
material-modal
```
, and
```
material-fullscreen
```
when the project does not already have them. Also define radius tokens/utilities for 6px, 12px, and 16px, and require screen files to consume those tokens rather than one-off
```
rounded-*
```
classes.
Primitives: create or adapt shared primitives for Button/IconButton, Input/Textarea, Select/Combobox when needed, Checkbox/Radio/Switch, Tabs, Modal/Sheet/Drawer, Menu/Tooltip, Toast/Feedback, Table/List, Empty/Error/Loading/Skeleton states, Surface/Material, and AppShell before composing multiple screens. App shells, panels, and surfaces use CSS grid/flex plus Geist tokens/materials by default; consult Geist Grid only when a visible guide/cell layout is intentionally part of the design. Panels/surfaces still inherit Context Card, Relative Time Card, Project Banner, Entity, Description, or Table Best Practices as applicable to the content.
Borders and focus: define one shared focus-visible utility/variant using the project semantic
```
ring
```
token mapped to a specific consulted Geist color role/scale, then verify the focus behavior separately through the Vercel Web Interface Guidelines accessibility checks. Wire that utility into every interactive primitive and prohibit screen-local outline, box-shadow, or ring definitions.
App shell: use Geist foundations and Vercel Web Interface Guidelines for root background, content gutters, header/sidebar/navigation structure when needed, restrained dividers, predictable max-width behavior, mobile behavior, one obvious primary action zone per view, skip-to-content, valid heading hierarchy, and context-specific
```
<title>
```
.
State system: provide consistent hover, active/pressed, selected/current, disabled, loading, empty, error, validation, focus-visible, and reduced-motion states across the app.
Dark mode: support dark mode only when the app already has it or the user asks for it; if implemented, map the same Geist roles rather than inventing a second palette.
Existing projects: adapt to the existing architecture and component library, but route all new styling through Geist tokens and classes. This adaptation cannot bypass the Foundation Gate.

本节是强制性基础审核的实施清单；它不能缩小、延迟或豁免任何基础审核要求。

对于任何创建或实质性更改渲染UI的任务，在样式化单个屏幕、路由、页面或功能组件之前，需创建或验证共享的Geist基础。

字体：通过宿主项目的字体设置使用Geist Sans和Geist Mono。在Next.js中，优先使用
```
geist
```
包的
```
geist/font/sans
```
和
```
geist/font/mono
```
；仅当实际使用受限显示/品牌强调时，才添加
```
geist/font/pixel
```
。
根布局：将Geist Sans设置为默认UI字体，为代码、命令文本、快捷键、技术标识符、版本、环境变量、提交哈希、终端/日志输出和官方mono类提供Geist Mono，仅为受限显示强调提供Geist Pixel变量。数字产品数据应保留在Sans标签/复制工具中并采用表格数字处理，除非查阅的排版页面或现有Geist映射原语将该上下文映射到Mono。
排版：定义或映射官方
```
text-heading-*
```
,
```
text-button-*
```
,
```
text-label-*
```
, 和
```
text-copy-*
```
类。新组件和屏幕必须使用这些类或映射等效项；原始
```
text-sm
```
、
```
font-bold
```
、任意行高和任意字间距仅允许出现在共享令牌/工具定义中，或出现在无法使用项目工具的第三方/生成代码中。最终响应必须说明文件、约束以及无法使用映射工具的原因。
颜色：为
```
background
```
,
```
foreground
```
,
```
muted-foreground
```
,
```
border
```
,
```
ring
```
,
```
accent
```
,
```
link
```
,
```
info
```
,
```
destructive
```
,
```
success
```
, 和
```
warning
```
定义语义令牌，映射到Background 1/2、组件背景1-3、边框4-6、高对比度背景7-8和文本/图标9-10。组件应使用语义令牌，而非硬编码灰色。
材质：当项目尚未拥有时，定义或映射
```
material-base
```
,
```
material-small
```
,
```
material-medium
```
,
```
material-large
```
,
```
material-tooltip
```
,
```
material-menu
```
,
```
material-modal
```
, 和
```
material-fullscreen
```
。同时定义6px、12px和16px的圆角令牌/工具，并要求屏幕文件使用这些令牌，而非一次性
```
rounded-*
```
类。
原语：在组合多个屏幕之前，创建或适配共享原语，包括Button/IconButton、Input/Textarea、必要时的Select/Combobox、Checkbox/Radio/Switch、Tabs、Modal/Sheet/Drawer、Menu/Tooltip、Toast/Feedback、Table/List、Empty/Error/Loading/Skeleton状态、Surface/Material和AppShell。应用外壳、面板和界面默认使用CSS grid/flex加Geist令牌/材质；仅当有意将可见指南/单元格布局作为设计的一部分时，才查阅Geist Grid。面板/界面仍需根据内容继承Context Card、Relative Time Card、Project Banner、Entity、Description或Table最佳实践。
边框和焦点：使用项目语义
```
ring
```
令牌映射到特定查阅的Geist颜色角色/缩放比例，定义一个共享的focus-visible工具/变体，然后通过Vercel Web Interface Guidelines可访问性检查单独验证焦点行为。将该工具连接到每个交互式原语，并禁止屏幕本地定义轮廓、框阴影或环样式。
应用外壳：使用Geist基础和Vercel Web Interface Guidelines设置根背景、内容边距、必要时的页眉/侧边栏/导航结构、克制的分隔线、可预测的最大宽度行为、移动端行为、每个视图的一个明显主要操作区域、跳转到内容链接、有效的标题层级和上下文特定的
```
<title>
```
。
状态系统：在整个应用中提供一致的悬停、激活/按下、选中/当前、禁用、加载、空、错误、验证、focus-visible和减少动效状态。
深色模式：仅当应用已支持或用户要求时才支持深色模式；如果实现，映射相同的Geist角色，而非发明第二个调色板。
现有项目：适配现有架构和组件库，但所有新样式都需通过Geist令牌和类路由。这种适配无法绕过基础审核。

Materials Rules

材质规则

The following material names are implementation mappings only. They do not satisfy the docs gate and must not be used as proof unless the official Materials page was opened, read, and influenced the implementation in the current turn.

Use official Geist Material presets first when the project has them. Materials are presets for radii, fills, strokes, and shadows.

Surface materials sit on the page:

```
material-base
```
: everyday surface. Radius 6px.
```
material-small
```
: slightly raised surface. Radius 6px.
```
material-medium
```
: further raised surface. Radius 12px.
```
material-large
```
: further raised surface. Radius 12px.

Floating materials sit above the page:

```
material-tooltip
```
: lightest shadow. Corner 6px. Tooltips are the only floating element with a triangular stem.
```
material-menu
```
: lifted menu surface. Radius 12px.
```
material-modal
```
: further lifted modal surface. Radius 12px.
```
material-fullscreen
```
: biggest lift. Radius 16px.

Material constraints:

Do not invent larger radii for a softer look. Existing token names may differ only if their resolved values preserve the official 6px, 12px, and 16px material radii for the mapped preset; otherwise strict Geist compliance is blocked.
Do not use heavy decorative shadows. Elevation should clarify layering, not create a floating-card aesthetic.
Use the component-specific material level: menus get menu material, modals get modal material, and ordinary page cards/panels use base/small/medium/large surface materials.
Do not nest multiple elevated materials unless the interaction genuinely requires layered floating UI.

以下材质名称仅为实现映射。它们无法满足文档审核要求，除非在当前回合打开、阅读并影响了实现，否则不得作为证明。

当项目拥有官方Geist Material预设时，优先使用这些预设。材质是圆角、填充、描边和阴影的预设。

界面材质位于页面上：

```
material-base
```
：日常界面。圆角6px。
```
material-small
```
：略微凸起的界面。圆角6px。
```
material-medium
```
：进一步凸起的界面。圆角12px。
```
material-large
```
：进一步凸起的界面。圆角12px。

浮动材质位于页面上方：

```
material-tooltip
```
：最浅的阴影。圆角6px。工具提示是唯一带有三角形柄的浮动元素。
```
material-menu
```
：抬起的菜单界面。圆角12px。
```
material-modal
```
：进一步抬起的模态框界面。圆角12px。
```
material-fullscreen
```
：最大的抬起高度。圆角16px。

材质约束：

不得为了更柔和的外观而发明更大的圆角。仅当解析值保留了映射预设的官方6px、12px和16px材质圆角时，现有令牌名称才可不同；否则严格Geist合规性受阻。
不得使用厚重的装饰性阴影。高度应明确分层，而非创建浮动卡片美学。
使用组件特定的材质级别：菜单使用菜单材质，模态框使用模态框材质，普通页面卡片/面板使用基础/小型/中型/大型界面材质。
除非交互确实需要分层浮动UI，否则不得嵌套多个凸起材质。

Vercel Design Details

Vercel设计细节

Apply the Design section of

https://vercel.com/design/guidelines

when the UI uses shadows, borders, nested containers, non-neutral surfaces, text transforms, charts, masks, fades, or browser chrome:

If shadows are used, layer ambient and direct-light shadows and pair them with crisp borders for edge clarity.
Nested radii must be concentric: child radius is less than or equal to parent radius and curves align.
On non-neutral backgrounds, tint borders, shadows, and text toward the same hue instead of mixing arbitrary hues.
Avoid scaling text nodes directly; animate a wrapper instead, and use GPU promotion only when text anti-aliasing artifacts persist.
Avoid gradient banding in masks and fades, especially when fading content to dark colors.
Charts must use color-blind-friendly palettes, and contrast should be checked with APCA where available.

当UI使用阴影、边框、嵌套容器、非中性界面、文本转换、图表、遮罩、淡入淡出或浏览器界面时，应用

https://vercel.com/design/guidelines

的设计部分：

如果使用阴影，分层环境光和直射光阴影，并将其与清晰的边框配对以明确边缘。
嵌套圆角必须同心：子圆角小于或等于父圆角，且曲线对齐。
在非中性背景上，将边框、阴影和文本色调向相同色相，而非混合任意色相。
避免直接缩放文本节点；改为动画化包装器，仅当文本抗锯齿伪影持续存在时才使用GPU加速。
避免遮罩和淡入淡出中的渐变条带，尤其是在将内容淡入深色时。
图表必须使用色盲友好的调色板，并在可用时通过APCA验证对比度。

Geist Component Mapping

Geist组件映射

Before custom-building UI, check whether Geist already has the pattern. If it does, use the Geist reference as the behavioral and visual target, then implement it with the project's available primitives.

For every UI need, perform a docs-first mapping pass before designing or coding: identify the user intent, check the official Geist component list and the closest component page, then choose the official component, an official composition of multiple components, or a constrained custom composition. Do not start from generic SaaS, shadcn, Radix, Tailwind, or memory-derived patterns when a Geist component exists.

Identity and object display: Avatar, Entity, Badge, Pill, Status Dot, Description.
Actions and command surfaces: Button, Split Button, Toggle, Menu, Context Menu, Command Menu.
Forms and selection: Input, Textarea, Checkbox, Radio, Switch, Select, Multi Select, Combobox, Choicebox, Slider, Calendar.
Navigation, layout, and disclosure: Tabs, Pagination, Collapse, Drawer, Sheet, Modal, Grid, Show More, Scroller, Table.
Feedback, help, and status: Toast, Feedback, Error, Note, Empty State, Progress, Spinner, Loading Dots, Skeleton, Tooltip.
Developer and preview surfaces: Code Block, Snippet, Keyboard Input, Browser, Phone, MiddleTruncate, Relative Time Card, Context Card.
Product, brand, and specialized surfaces: Project Banner, Gauge, Material, Book, Theme Switcher, Destructive Action Modal.
Custom primitive aliases: IconButton -> Button; List -> Table, Entity, Description, Scroller, or Show More; Card/Panel/Surface -> Material, then Context Card, Relative Time Card, Project Banner, Entity, Description, or Table by content; AppShell -> CSS grid/flex plus Menu, Tabs, Drawer, Sheet, Button, Avatar, Badge, and Status Dot as used. Use Geist Grid only when visible cell/guide layout is intentionally part of the design. These aliases are not escape hatches; they inherit applicable Best Practices from every adjacent official component.
Common library-name aliases: Dialog -> Modal; AlertDialog/ConfirmDialog -> Destructive Action Modal only for high-stakes destructive flows requiring deliberate typed confirmation, otherwise Modal for routine confirmations, unsaved-change prompts, and low-stakes confirmations; DropdownMenu -> Menu; ContextMenu -> Context Menu; Command/CommandDialog -> Command Menu; Accordion/Collapsible -> Collapse; DataTable -> Table; ToggleGroup/SegmentedControl -> Switch for 2-3 mutually exclusive same-surface options, Toggle only for a single boolean setting, Tabs for sibling views when tab semantics are intended, and Select when option count or label length exceeds Switch guidance; Popover/HoverCard -> the closest checked Geist component such as Menu, Tooltip, Context Card, Sheet, or Modal. These aliases inherit Best Practices and require
```
Docs Evidence
```
rows for each selected or rejected Geist page.
If a needed pattern is not in Geist, first check adjacent official components that may cover the intent. Only then compose it from Geist foundations: color roles, typography classes, material presets, spacing, interaction rules, and accessible project primitives.
If the project uses shadcn, Radix, or another component library, treat it as behavior/accessibility infrastructure only. Restyle and compose it through Geist tokens and component references.
Do not add custom visual variants to Geist-mapped primitives unless the variant is a direct alias of an official Geist variant, state, or documented semantic status from the consulted component page. Project-specific visual variants such as
```
brand
```
,
```
premium
```
,
```
ghost
```
,
```
glass
```
,
```
soft
```
,
```
elevated
```
,
```
ai
```
,
```
accent
```
, or
```
marketing
```
are rejected or moved to composition unless the user explicitly confirms a non-Geist visual-system override. Any allowed alias must cite the component page Best Practices in
```
Docs Evidence
```
.
For official compositions and constrained custom patterns, open every checked adjacent Geist component page and apply all applicable Best Practices. Deviate only when a Best Practice is technically impossible; document the checked component, the impossible constraint, and the closest preserved Geist behavior. Explicit product requests should be satisfied through the closest official Geist component/composition rather than by replacing component-specific behavior.
Custom patterns must name the checked Geist alternatives, reuse existing project primitives, keep semantics and keyboard behavior equivalent to the closest native/ARIA pattern, use only Geist tokens/classes/materials, avoid new colors/radii/shadows/typography scales, and include loading, empty, error, disabled, focus-visible, and reduced-motion behavior when relevant.
Current component-index reconciliation: open
```
https://vercel.com/geist/introduction
```
, compare every Components nav item against the body reference map, frontmatter source list, and mapping buckets; if a live component is missing locally, use the official nav URL, map it to the closest bucket, and mention the skill drift in the final response.

在自定义构建UI之前，检查Geist是否已有该模式。如果有，将Geist参考作为行为和视觉目标，然后使用项目的可用原语实现它。

对于每个UI需求，在设计或编码之前执行文档优先映射步骤：识别用户意图，检查官方Geist组件列表和最接近的组件页面，然后选择官方组件、多个组件的官方组合或受限自定义组合。当Geist组件存在时，不得从通用SaaS、shadcn、Radix、Tailwind或记忆衍生模式开始。

身份和对象展示：Avatar、Entity、Badge、Pill、Status Dot、Description。
操作和命令界面：Button、Split Button、Toggle、Menu、Context Menu、Command Menu。
表单和选择：Input、Textarea、Checkbox、Radio、Switch、Select、Multi Select、Combobox、Choicebox、Slider、Calendar。
导航、布局和展示：Tabs、Pagination、Collapse、Drawer、Sheet、Modal、Grid、Show More、Scroller、Table。
反馈、帮助和状态：Toast、Feedback、Error、Note、Empty State、Progress、Spinner、Loading Dots、Skeleton、Tooltip。
开发者和预览界面：Code Block、Snippet、Keyboard Input、Browser、Phone、MiddleTruncate、Relative Time Card、Context Card。
产品、品牌和特殊界面：Project Banner、Gauge、Material、Book、Theme Switcher、Destructive Action Modal。
自定义原语别名：IconButton -> Button；List -> Table、Entity、Description、Scroller或Show More；Card/Panel/Surface -> Material，然后根据内容选择Context Card、Relative Time Card、Project Banner、Entity、Description或Table；AppShell -> CSS grid/flex加Menu、Tabs、Drawer、Sheet、Button、Avatar、Badge和Status Dot（如使用）。仅当有意将可见单元格/指南布局作为设计的一部分时，才使用Geist Grid。这些别名并非漏洞；它们继承每个相邻官方组件的适用最佳实践。
常见库名称别名：Dialog -> Modal；AlertDialog/ConfirmDialog -> Destructive Action Modal（仅用于需要故意输入确认的高风险破坏性流程，否则Modal用于常规确认、未保存更改提示和低风险确认）；DropdownMenu -> Menu；ContextMenu -> Context Menu；Command/CommandDialog -> Command Menu；Accordion/Collapsible -> Collapse；DataTable -> Table；ToggleGroup/SegmentedControl -> Switch（用于2-3个互斥的同界面选项）、Toggle（仅用于单个布尔设置）、Tabs（用于需要标签语义的同级视图）、Select（当选项数量或标签长度超过Switch指导时）；Popover/HoverCard -> 最接近的已检查Geist组件，如Menu、Tooltip、Context Card、Sheet或Modal。这些别名继承最佳实践，并要求为每个选中或拒绝的Geist页面添加
```
Docs Evidence
```
行。
如果所需模式不在Geist中，首先检查可能涵盖该意图的相邻官方组件。然后仅从Geist基础组合它：颜色角色、排版类、材质预设、间距、交互规则和可访问的项目原语。
如果项目使用shadcn、Radix或其他组件库，仅将其视为行为/可访问性基础设施。通过Geist令牌和组件参考重新设计和组合它。
不得向Geist映射的原语添加自定义视觉变体，除非该变体是官方Geist变体、状态或查阅组件页面中记录的语义状态的直接别名。项目特定的视觉变体（如
```
brand
```
、
```
premium
```
、
```
ghost
```
、
```
glass
```
、
```
soft
```
、
```
elevated
```
、
```
ai
```
、
```
accent
```
或
```
marketing
```
）被拒绝或移至组合，除非用户明确确认非Geist视觉系统覆盖。任何允许的别名必须在
```
Docs Evidence
```
中引用组件页面的最佳实践。
对于官方组合和受限自定义模式，打开每个已检查的相邻Geist组件页面并应用所有适用的最佳实践。仅当最佳实践在技术上不可行时才偏离；记录已检查的组件、不可行的约束以及最接近的保留Geist行为。明确的产品请求应通过最接近的官方Geist组件/组合满足，而非替换组件特定行为。
自定义模式必须命名已检查的Geist替代方案、重用现有项目原语、保持语义和键盘行为与最接近的原生/ARIA模式等效、仅使用Geist令牌/类/材质、避免新颜色/圆角/阴影/排版缩放，并在相关时包含加载、空、错误、禁用、focus-visible和减少动效行为。
当前组件索引协调：打开
```
https://vercel.com/geist/introduction
```
，将每个组件导航项与正文参考映射、前置元数据源列表和映射存储桶进行比较；如果本地缺少实时组件，使用官方导航URL，将其映射到最接近的存储桶，并在最终响应中提及技能漂移。

Component Documentation Contract

组件文档约定

For every UI component that maps to Geist, open and read its official component page in the current turn before designing or coding that component. A component page counts as consulted only when the agent records an exact section/anchor, a short official quote, all applicable Best Practices when the page provides them, and any relevant When to use, Behavior, Content, or Accessibility constraints. For components actually implemented or restyled, at least one page-specific quoted rule from the official component page must affect the implementation and appear in

Docs Evidence

. The

not applicable

path is allowed only for adjacent components that were checked and rejected during custom-pattern mapping, and the final evidence must name the rejected component and why it did not fit. Preserve component-specific rules such as button/link separation, destructive modal focus behavior, input label/id requirements, empty-state CTA limits, table semantics, and exact label/copy conventions. Generic component styling, matching class names, or memory of Geist patterns is insufficient when the official page gives a more specific rule.

对于每个映射到Geist的UI组件，在当前回合设计或编码该组件之前，需打开并阅读其官方组件页面。仅当代理记录了确切章节/锚点、简短官方引用、页面提供的所有适用最佳实践以及任何相关的使用场景、行为、内容或可访问性约束时，组件页面才视为已查阅。对于实际实现或重新设计的组件，至少有一个来自官方组件页面的页面特定引用规则必须影响实现并出现在

Docs Evidence

中。仅在自定义模式映射期间已检查并拒绝相邻组件时，才允许

不适用

路径，且最终证据必须命名被拒绝的组件及其不适用的原因。保留组件特定规则，如按钮/链接分离、破坏性模态框焦点行为、输入标签/ID要求、空状态CTA限制、表格语义和确切标签/复制约定。当官方页面给出更具体的规则时，通用组件样式、匹配类名或Geist模式的记忆是不够的。

Component Rules

组件规则

All components must have:

Default, hover, active/pressed, focus-visible, disabled, loading, and error states when relevant.
Keyboard accessibility for all interactive controls.
ARIA only when it improves semantic clarity; do not add redundant ARIA to native elements.
Use native semantics first: button for actions, a/Link for navigation, label for controls, table for tabular data. Do not substitute div/button for navigational links. App shells need a skip-to-content link, valid heading hierarchy, and a context-specific
```
<title>
```
. Name icon-only controls, provide accurate accessible names, give images meaningful
```
alt
```
, set decorative images to
```
alt=""
```
, set
```
aria-hidden="true"
```
on decorative SVG/icons/media, announce async updates with polite aria-live where appropriate, and verify names/states in the accessibility tree.
Visible focus rings that match the system and meet contrast needs. Use
```
:focus-visible
```
for focus rings and
```
:focus-within
```
for grouped/composite controls. On desktop screens with a single primary input, autofocus that input. Avoid mobile autofocus unless explicitly justified.
Stable sizing across content, loading, and state changes.
Icon alignment that does not distort row height or button height.

Component direction:

Buttons: clear hierarchy. One primary action per surface. Secondary and tertiary actions should stay quiet. Destructive actions require confirmation or Undo with a safe window; irreversible destructive actions require confirmation.
Inputs/Textareas: restrained borders, visible focus state, inline validation, associated labels, mobile input font-size >=16px, browser zoom left enabled, hydration-safe value/focus, paste allowed, no blocked typing, correct type/inputmode/name/autocomplete, selective spellcheck, explicit native select colors for Windows dark mode, and no oversized fields unless the task requires it.
Forms: Enter submits when a text input is the only control or the last relevant control in a multi-control form; in
```
<textarea>
```
, Cmd/Ctrl+Enter submits and Enter inserts a newline. Every control has an associated label, clicking a label activates the control, submit remains enabled until submission starts, in-flight submission disables the submit control, shows progress, and uses an idempotency key when a mutation can repeat. Do not pre-disable submit to hide validation; submit incomplete forms to reveal validation, show errors next to fields, focus the first error on submit, warn before navigation when unsaved data could be lost, and preserve password-manager, autofill, OTP, paste, and text-replacement compatibility. Placeholders should signal emptiness with an ellipsis and use example values or patterns. Avoid password-manager triggers on non-auth fields with appropriate
```
name
```
and
```
autocomplete
```
values. Trim text-replacement trailing whitespace before validation errors are shown.
Select/Combobox/Menus: keyboard-navigable, typeahead/search when data volume needs it, concise option labels.
Tabs: use for peer views. Do not use tabs as decoration.
Modals/Drawers/Sheets/Menus/Comboboxes: follow WAI-ARIA Authoring Patterns; set initial focus, trap or scope focus while open, restore focus to the trigger on close, support Escape, and verify the full flow by keyboard. Modal/drawer/sheet surfaces still need clear primary/secondary actions and escape/cancel behavior.
Toasts/Feedback: concise, state-specific, dismissible when appropriate, and never a replacement for inline validation.
Tables: compact, scannable, sortable/filterable when the workflow needs it, with empty/error/loading states.
Code Blocks/Snippets: use Geist Mono, copy affordance, language/file label when useful, and clear line wrapping/overflow.
Empty States: direct next action, no oversized illustration unless the product context needs it.
Scroller: use for overflowing peer items on one axis; pick
```
vertical
```
,
```
horizontal
```
, or
```
free
```
based on real content. Use virtualization or
```
content-visibility
```
for large lists when the Web Interface Guidelines audit/prompt flags the list size or when profiling shows rendering cost; otherwise document the performance justification. Keep horizontal widths/gaps consistent, expose edge affordances, and give scroll buttons specific
```
aria-label
```
s such as
```
Scroll customer logos left
```
.
Skeletons/Spinners/Loading Dots: use only while real data or work is pending; preserve final layout dimensions. Loading buttons keep the original label visible with a progress indicator. Local heuristic, not
```
Docs Evidence
```
: spinner/skeleton UI should avoid flicker with a short show delay and minimum visible duration unless the consulted component or project primitive defines exact timing.

所有组件必须具备：

相关时的默认、悬停、激活/按下、focus-visible、禁用、加载和错误状态。
所有交互式控件的键盘可访问性。
仅在提高语义清晰度时使用ARIA；不得向原生元素添加冗余ARIA。
优先使用原生语义：按钮用于操作，a/Link用于导航，label用于控件，table用于表格数据。不得用div/button替代导航链接。应用外壳需要跳转到内容链接、有效的标题层级和上下文特定的
```
<title>
```
。为仅图标控件命名、提供准确的可访问名称、为图像设置有意义的
```
alt
```
、将装饰性图像设置为
```
alt=""
```
、为装饰性SVG/图标/媒体设置
```
aria-hidden="true"
```
、在适当的地方用礼貌的aria-live宣布异步更新，并在可访问性树中验证名称/状态。
可见的焦点环，匹配系统并满足对比度需求。对焦点环使用
```
:focus-visible
```
，对分组/复合控件使用
```
:focus-within
```
。在具有单个主要输入的桌面屏幕上，自动聚焦该输入。除非明确合理，否则避免移动端自动聚焦。
跨内容、加载和状态变化的稳定大小。
图标对齐不会扭曲行高或按钮高度。

组件方向：

按钮：清晰的层级。每个界面一个主要操作。次要和三级操作应保持低调。破坏性操作需要确认或带有安全窗口的撤销；不可逆的破坏性操作需要确认。
Inputs/Textareas：克制的边框、可见的焦点状态、内联验证、关联标签、移动端输入字体大小>=16px、启用浏览器缩放、 hydration安全的值/焦点、允许粘贴、不阻止输入、正确的类型/inputmode/name/autocomplete、选择性拼写检查、Windows深色模式下的显式原生选择颜色，且除非任务需要，否则不得使用超大字段。
表单：当文本输入是唯一控件或多控件表单中的最后一个相关控件时，Enter提交；在
```
<textarea>
```
中，Cmd/Ctrl+Enter提交，Enter插入换行。每个控件都有关联标签，点击标签激活控件，提交在提交开始前保持启用，进行中的提交禁用提交控件、显示进度，并在突变可重复时使用幂等键。不得预先禁用提交以隐藏验证；提交不完整的表单以显示验证、在字段旁显示错误、提交时聚焦第一个错误、在未保存数据可能丢失时警告导航，并保留密码管理器、自动填充、OTP、粘贴和文本替换兼容性。占位符应使用省略号表示空值，并使用示例值或模式。通过适当的
```
name
```
和
```
autocomplete
```
值避免非认证字段触发密码管理器。在显示验证错误之前，修剪文本替换的尾随空格。
Select/Combobox/Menus：可键盘导航、数据量需要时支持输入搜索/预输入、简洁的选项标签。
Tabs：用于同级视图。不得将标签用作装饰。
Modals/Drawers/Sheets/Menus/Comboboxes：遵循WAI-ARIA创作模式；设置初始焦点、打开时捕获或限定焦点、关闭时将焦点恢复到触发器、支持Escape，并通过键盘验证完整流程。模态框/抽屉/面板界面仍需清晰的主要/次要操作和退出/取消行为。
Toasts/Feedback：简洁、特定状态、适当可关闭，且绝不能替代内联验证。
Tables：紧凑、可扫描、工作流需要时可排序/筛选，并具有空/错误/加载状态。
Code Blocks/Snippets：使用Geist Mono、复制功能、必要时的语言/文件标签，以及清晰的换行/溢出处理。
Empty States：直接的下一步操作，除非产品上下文需要，否则不得使用超大插图。
Scroller：用于单轴上的溢出同级项；根据实际内容选择
```
vertical
```
、
```
horizontal
```
或
```
free
```
。当Web Interface Guidelines审核/提示标记列表大小或分析显示渲染成本时，对大型列表使用虚拟化或
```
content-visibility
```
；否则记录性能理由。保持水平宽度/间距一致、显示边缘提示，并为滚动按钮设置特定的
```
aria-label
```
，如
```
Scroll customer logos left
```
。
Skeletons/Spinners/Loading Dots：仅在实际数据或工作待处理时使用；保留最终布局尺寸。加载按钮保持原始标签可见并带有进度指示器。本地启发法，非
```
Docs Evidence
```
：除非查阅的组件或项目原语定义了确切时间，否则 spinner/skeleton UI应通过短暂的显示延迟和最小可见持续时间避免闪烁。

Iconography

图标设计

Icon and asset decisions are source-gated: use Geist component pages for icon-bearing component behavior, Button for icon-only/svg-only button guidance, Brands for official marks, and Web Interface Guidelines for hit targets and accessible names. Do not claim official Geist icon compliance from an icon package name alone.

Use official logos only for truthful brand references after consulting Geist Brands. Do not imply Vercel, Next.js, Turbo, or v0 endorsement.
For generic UI symbols, use the project's existing icon library or installed assets unless a current non-redirecting official Geist icons source is consulted. While Geist resource/icon links redirect to Introduction, they do not authorize package-specific icon compliance claims. Size and align icons through the consulted Geist component, existing mapped primitive, or shared token. Do not introduce exact icon-size mandates unless a current official source or existing Geist-mapped primitive supplies them.
Buttons that perform common tool actions may use familiar icons only when the control still has an accessible name and follows the consulted Button/icon-only guidance.
Icon-only buttons and compact controls must satisfy Web Interface Guidelines hit-target rules: visual targets below 24px need expanded hit targets, and mobile targets are 44px.
Local heuristic, not
```
Docs Evidence
```
: do not use decorative icon clusters to fill space.

图标和资产决策受来源审核：使用Geist组件页面获取带图标组件的行为、使用Button获取仅图标/仅SVG按钮指导、使用Brands获取官方标志、使用Web Interface Guidelines获取点击目标和可访问名称。不得仅通过图标包名称声称符合官方Geist图标规范。

仅在查阅Geist Brands后，为真实品牌参考使用官方标志。不得暗示Vercel、Next.js、Turbo或v0的认可。
对于通用UI符号，使用项目的现有图标库或已安装资产，除非查阅了当前非重定向的官方Geist图标来源。虽然Geist资源/图标链接重定向到介绍页面，但它们不授权特定包的图标合规性声明。通过查阅的Geist组件、现有映射原语或共享令牌调整图标大小和对齐。除非当前官方来源或现有Geist映射原语提供，否则不得引入确切的图标大小要求。
执行常见工具操作的按钮仅在控件仍具有可访问名称并遵循查阅的Button/仅图标指导时，才可使用熟悉的图标。
仅图标按钮和紧凑控件必须满足Web Interface Guidelines点击目标规则：视觉目标小于24px时需要扩大点击目标，移动端目标为44px。
本地启发法，非
```
Docs Evidence
```
：不得使用装饰性图标集群填充空间。

Brand Assets And Trademark Gate

品牌资产和商标审核

Use official Vercel brand assets only for truthful references. Do not modify marks, make them more prominent than the app's own brand, use them in product/company names, or imply endorsement. Follow

https://vercel.com/geist/brands

for Vercel, Next.js, Turbo/Turborepo/Turbopack, v0, and AI SDK assets, logo imports, spacing, attribution, permitted usage, and misuse rules.

仅为真实参考使用官方Vercel品牌资产。不得修改标志、使其比应用自身品牌更突出、在产品/公司名称中使用，或暗示认可。遵循

https://vercel.com/geist/brands

中关于Vercel、Next.js、Turbo/Turborepo/Turbopack、v0和AI SDK资产、Logo导入、间距、归因、允许使用和误用规则的内容。

Motion And Interaction

动效和交互

Motion should clarify state changes: open/close, loading, selection, reordering, hover/focus, success/error.
Do not invent universal timing ranges. Use durations from consulted component docs when they exist; otherwise keep motion minimal, interruptible, and purpose-driven without claiming numeric timing as
```
Docs Evidence
```
.
Prefer CSS animations/transitions first, then Web Animations API, and avoid main-thread JavaScript-driven animation when possible.
Prefer opacity/transform transitions. Avoid layout-thrashing animations. Never use
```
transition: all
```
; explicitly list intended properties such as
```
opacity
```
and
```
transform
```
.
Choose easing based on what changes: size, distance, and trigger.
Respect reduced motion preferences.
Make animations cancelable/interruptible and input-driven. Set
```
transform-origin
```
to the perceived origin of the motion.
For SVG transforms or animations, apply transforms to
```
<g>
```
wrappers and set
```
transform-box: fill-box
```
plus
```
transform-origin
```
to avoid browser origin bugs.
Do not add scroll-triggered spectacle, parallax, bouncing, or decorative motion to product surfaces.

动效应明确状态变化：打开/关闭、加载、选择、重新排序、悬停/焦点、成功/错误。
不得发明通用时间范围。当查阅的组件文档存在时长时使用这些时长；否则保持动效最小化、可中断且有目的性，不得声称数字时长符合
```
Docs Evidence
```
。
优先使用CSS动画/过渡，然后是Web Animations API，尽可能避免主线程JavaScript驱动的动画。
优先使用透明度/变换过渡。避免布局抖动动画。不得使用
```
transition: all
```
；明确列出预期属性，如
```
opacity
```
和
```
transform
```
。
根据变化内容选择缓动：大小、距离和触发器。
尊重减少动效偏好。
使动画可取消/可中断且由输入驱动。将
```
transform-origin
```
设置为动效的感知原点。
对于SVG变换或动画，将变换应用于
```
<g>
```
包装器，并设置
```
transform-box: fill-box
```
加
```
transform-origin
```
以避免浏览器原点错误。
不得在产品界面添加滚动触发特效、视差、弹跳或装饰性动效。

Performance-Relevant UI Gate

性能相关UI审核

Apply performance rules when a task touches rendered UI, animations, data views, media, forms, or interaction-heavy surfaces:

Test or reason explicitly about iOS Low Power Mode and macOS Safari when those environments are available or the surface is user-facing.
Profile perf-sensitive flows with CPU and network throttling when local tooling makes that feasible. Disable browser extensions that can distort measurement when using a real browser profile.
Keep input loops cheap. Prefer uncontrolled inputs when appropriate, minimize re-renders, track re-renders with React DevTools or React Scan when available, and make controlled keystrokes fast enough for typing.
Minimize layout work: batch reads/writes, avoid unnecessary reflows/repaints, avoid render-time layout reads such as
```
getBoundingClientRect
```
,
```
offsetHeight
```
,
```
offsetWidth
```
, and
```
scrollTop
```
, and do not use main-thread JavaScript for layout that CSS can handle.
Treat mutation latency as product UI quality:
```
POST
```
,
```
PATCH
```
, and
```
DELETE
```
interactions should target completion under 500ms where the backend and network make that feasible, with optimistic UI, rollback, or Undo where appropriate.
Virtualize large lists instead of rendering every row/card into the main layout. When using the official Web Interface Guidelines agent prompt or manual fallback, treat lists over 50 rendered items as requiring virtualization unless the current fetched prompt says otherwise; use
```
content-visibility: auto
```
only as a measured supplement, not a replacement for required virtualization.
For images/media, set explicit dimensions or reserve space to avoid CLS. Preload only above-the-fold images and lazy-load the rest.
Preload critical fonts, subset fonts to the scripts/code points and axes actually used, and avoid font loading that shifts layout.
Use preconnect only for real external asset origins the project already needs.
Move long main-thread work to Web Workers or existing background processing so interaction remains responsive.

当任务涉及渲染UI、动画、数据视图、媒体、表单或交互密集界面时，应用性能规则：

当这些环境可用或界面面向用户时，明确测试或考虑iOS低电量模式和macOS Safari。
当本地工具可行时，使用CPU和网络节流分析性能敏感流程。使用真实浏览器配置文件时，禁用可能扭曲测量的浏览器扩展。
保持输入循环低成本。适当优先使用非受控输入、最小化重渲染、在可用时使用React DevTools或React Scan跟踪重渲染，并使受控按键输入足够快以满足打字需求。
最小化布局工作：批量读取/写入、避免不必要的回流/重绘、避免渲染时布局读取，如
```
getBoundingClientRect
```
、
```
offsetHeight
```
、
```
offsetWidth
```
和
```
scrollTop
```
，且不得使用主线程JavaScript处理CSS可处理的布局。
将突变延迟视为产品UI质量：
```
POST
```
、
```
PATCH
```
和
```
DELETE
```
交互应在后端和网络允许的情况下，目标在500ms内完成，并在适当的地方使用乐观UI、回滚或撤销。
虚拟化大型列表，而非将每一行/卡片渲染到主布局中。当使用官方Web Interface Guidelines代理提示或手动回退时，将超过50个渲染项的列表视为需要虚拟化，除非当前获取的提示另有说明；仅将
```
content-visibility: auto
```
作为测量补充，而非所需虚拟化的替代方案。
对于图像/媒体，设置明确尺寸或预留空间以避免CLS。仅预加载首屏图像，其余图像懒加载。
预加载关键字体、将字体子集化为实际使用的脚本/码点和轴，并避免导致布局偏移的字体加载。
仅对项目已需要的真实外部资产源使用preconnect。
将长时间主线程工作移至Web Workers或现有后台处理，以便交互保持响应。

Copy Rules

文案规则

Product UI headings and buttons use Title Case:
```
Create Project
```
,
```
Deploy
```
,
```
Copy
```
,
```
Invite
```
,
```
Upgrade
```
,
```
Cancel
```
,
```
Delete
```
. Marketing pages use sentence case.
Use active voice, second person, concise action-oriented language, consistent nouns, numerals for counts,
```
&
```
where it fits Vercel style, and the ellipsis character for follow-up/loading labels:
```
Rename…
```
,
```
Loading…
```
,
```
Saving…
```
.
Avoid technical jargon unless the audience is explicitly developer/operator and the term is useful.
Error messages should use positive, problem-solving language: say what failed, why when known, and what the user can do next. Buttons and links in error states must provide a clear exit or fix path.
Empty states should describe the current absence and offer the next action.
Use consistent placeholder and currency formats within a context. Format dates, times, numbers, delimiters, and currencies for the user's locale. Prefer curly quotes and use non-breaking spaces or word joiners for glued terms such as
```
10&nbsp;MB
```
,
```
⌘&nbsp;+&nbsp;K
```
, and
```
Vercel&nbsp;SDK
```
.
Detect language from explicit user/account settings, the
```
Accept-Language
```
header, or
```
navigator.languages
```
; never infer language from IP or GPS location alone. Tidy widows, orphans, rag, and line breaks where the text-rendering stack supports it.
Prefer inline help before tooltips. Tooltips are a last resort for supplemental explanation and must not hide required information.
Anchored headings need
```
scroll-margin-top
```
so deep links do not hide headings under sticky headers.
Mark brand names, product names, code tokens, and technical identifiers with
```
translate="no"
```
when browser translation could corrupt them.
Layouts must handle short, average, and very long user-generated content without clipping, overlap, or broken controls.
Local heuristic, not
```
Docs Evidence
```
: avoid redundant visible instructional text when labels and affordances already make a control clear.
No screen may dead-end: empty, sparse, dense, permission, offline, and error screens must include a clear next step, retry, back path, request-access path, or contact/support path as appropriate.

产品UI标题和按钮使用标题大小写：
```
Create Project
```
、
```
Deploy
```
、
```
Copy
```
、
```
Invite
```
、
```
Upgrade
```
、
```
Cancel
```
、
```
Delete
```
。营销页面使用句子大小写。
使用主动语态、第二人称、简洁的面向操作语言、一致的名词、数字表示计数、符合Vercel风格的
```
&
```
，以及省略号表示后续/加载标签：
```
Rename…
```
、
```
Loading…
```
、
```
Saving…
```
。
除非受众明确是开发者/操作员且术语有用，否则避免技术行话。
错误消息应使用积极的、解决问题的语言：说明失败内容、已知原因以及用户下一步可采取的操作。错误状态下的按钮和链接必须提供清晰的退出或修复路径。
空状态应描述当前缺失情况并提供下一步操作。
在上下文中使用一致的占位符和货币格式。根据用户区域设置格式化日期、时间、数字、分隔符和货币。优先使用弯引号，并对粘合术语使用非换行空格或单词连接符，如
```
10&nbsp;MB
```
、
```
⌘&nbsp;+&nbsp;K
```
和
```
Vercel&nbsp;SDK
```
。
从明确的用户/账户设置、
```
Accept-Language
```
标头或
```
navigator.languages
```
检测语言；不得仅从IP或GPS位置推断语言。在文本渲染栈支持的情况下整理孤行、孤儿文本、参差不齐的右边缘和换行符。
优先使用内联帮助，而非工具提示。工具提示是补充说明的最后手段，不得隐藏必要信息。
锚定标题需要
```
scroll-margin-top
```
，以便深度链接不会将标题隐藏在粘性页眉下方。
当浏览器翻译可能损坏品牌名称、产品名称、代码令牌和技术标识符时，使用
```
translate="no"
```
标记它们。
布局必须处理短、平均和非常长的用户生成内容，而不会出现裁剪、重叠或控件损坏。
本地启发法，非
```
Docs Evidence
```
：当标签和提示已明确控件时，避免冗余的可见说明文本。
任何屏幕都不得死胡同：空、稀疏、密集、权限、离线和错误屏幕必须根据情况包含清晰的下一步、重试、返回路径、请求访问路径或联系/支持路径。

Vercel Web Interface Guidelines Overlay

Vercel Web Interface Guidelines覆盖

Apply

https://vercel.com/design/guidelines

to every Geist-styled app:

Keyboard works everywhere; focus is visible and managed; visual targets below 24px need expanded hit targets and mobile targets are 44px; mobile inputs use at least 16px text; never disable browser zoom or add zoom-limiting viewport settings such as
```
user-scalable=no
```
; every screen has empty, sparse, dense, loading, and error states.
Persist view-affecting or workflow-affecting client state in the URL: search text, filters, sort, tabs, pagination, expanded panels, selected views, mode, drawer/detail selection, date ranges, comparison views, and any state stored in a client store that affects the visible view or workflow. Back/Forward and refresh must restore state and scroll position. Ephemeral focus, hover, in-flight request, and unsaved draft state may remain local.
Use optimistic updates when success is likely, reconcile on server response, and on failure show an error plus rollback or Undo.
Use tooltip timing that delays the first tooltip in a group and makes subsequent peer tooltips immediate.
Set
```
overscroll-behavior: contain
```
intentionally for modals, drawers, and similar contained scroll regions.
Clean drag interactions disable text selection and apply
```
inert
```
to prevent simultaneous hover/selection/interaction while dragging.
Keyboard shortcuts are locale-aware and show platform-specific symbols.
If any part of a control looks interactive, it must be interactive. Labels activate controls; checkbox/radio labels and controls share one generous target. Set
```
touch-action: manipulation
```
on controls and define
```
-webkit-tap-highlight-color
```
to match the design.
No screen dead-ends; headings and buttons in product UI use Title Case; labels are specific; counts use numerals; numbers and units use a space/non-breaking space.
Browser chrome is implementation work, not a final-only check. Official guideline: browser UI should match the page background, and the root should set the appropriate
```
color-scheme
```
for the active theme so browser/device UI keeps contrast. Geist implementation recommendation: align
```
<meta name="theme-color">
```
with the active Background 1 color; use media-specific meta tags when both light and dark OS themes are supported, and set
```
color-scheme
```
on the root according to the app's theme model.

将

https://vercel.com/design/guidelines

应用于每个Geist风格的应用：

键盘可在所有地方使用；焦点可见且可管理；视觉目标小于24px时需要扩大点击目标，移动端目标为44px；移动端输入使用至少16px文本；不得禁用浏览器缩放或添加限制缩放的视口设置，如
```
user-scalable=no
```
；每个屏幕都有空、稀疏、密集、加载和错误状态。
将影响视图或工作流的客户端状态持久化到URL中：搜索文本、筛选器、排序、标签、分页、展开面板、选中视图、模式、抽屉/详情选择、日期范围、比较视图，以及客户端存储中影响可见视图或工作流的任何状态。后退/前进和刷新必须恢复状态和滚动位置。临时焦点、悬停、进行中的请求和未保存的草稿状态可保留在本地。
当成功可能性高时使用乐观更新，在服务器响应时协调，失败时显示错误加回滚或撤销。
使用工具提示计时：延迟组中的第一个工具提示，使后续同级工具提示立即显示。
有意为模态框、抽屉和类似的包含滚动区域设置
```
overscroll-behavior: contain
```
。
流畅的拖拽交互禁用文本选择并应用
```
inert
```
，以防止拖拽时同时出现悬停/选择/交互。
键盘快捷键支持区域设置，并显示特定平台的符号。
如果控件的任何部分看起来可交互，则必须可交互。标签激活控件；复选框/单选按钮标签和控件共享一个宽大的目标。在控件上设置
```
touch-action: manipulation
```
，并定义
```
-webkit-tap-highlight-color
```
以匹配设计。
没有屏幕死胡同；产品UI中的标题和按钮使用标题大小写；标签具体；计数使用数字；数字和单位使用空格/非换行空格。
浏览器界面是实现工作，而非仅最终检查。官方指南：浏览器UI应匹配页面背景，根元素应根据活动主题设置适当的
```
color-scheme
```
，以便浏览器/设备UI保持对比度。Geist实现建议：将
```
<meta name="theme-color">
```
与活动Background 1颜色对齐；当支持浅色和深色OS主题时使用媒体特定元标签，并根据应用的主题模型在根元素上设置
```
color-scheme
```
。

Implementation Rules

实现规则

Use existing project tokens and primitives only after mapping or adapting them to the required Geist foundation roles. If they cannot express Geist fonts, tokens, typography utilities, materials/radii, focus rings, states, and app shell composition, establish those shared layers first.
If tokens are missing, define a small semantic token layer in CSS variables before styling components.
Keep component APIs explicit and small. Avoid boolean prop proliferation; use explicit variants or composition.
Do not add mock/sample data to make UI look filled. Use real data pathways or honest empty/loading states.

仅在将现有项目令牌和原语映射或适配到所需Geist基础角色后，才可使用它们。如果它们无法表达Geist字体、令牌、排版工具、材质/圆角、焦点环、状态和应用外壳组合，则首先建立这些共享层。
如果令牌缺失，在样式化组件之前，在CSS变量中定义一个小型语义令牌层。
保持组件API明确且精简。避免布尔属性激增；使用明确的变体或组合。
不得添加模拟/示例数据使UI看起来填充完整。使用真实数据路径或诚实的空/加载状态。

Tailwind Guidance

Tailwind指导

Use Tailwind through the host project's setup only.

When defining custom CSS/Tailwind variables, prefer raw Geist scale roles first, then derive semantic aliases such as
```
background
```
,
```
foreground
```
,
```
muted-foreground
```
,
```
border
```
,
```
ring
```
,
```
link
```
,
```
info
```
,
```
destructive
```
,
```
success
```
, and
```
warning
```
. If the project already exposes official Geist/Core tokens or generated CSS variables, map semantic aliases to those without duplicating the raw layer. If an
```
accent
```
alias exists, it must resolve to a specific official Geist role/scale for focus, selection, link, or status, never to a decorative palette.
Keep class lists readable and consistent with existing project conventions.
Prefer semantic component classes or variants for repeated patterns.
Arbitrary color, typography, radius, shadow, focus, ring, material, and state values may appear only inside shared token, utility, variant, or primitive definitions. Route, page, screen, and feature files must consume named tokens, utilities, variants, or primitives instead of one-off arbitrary values.

仅通过宿主项目的设置使用Tailwind。

定义自定义CSS/Tailwind变量时，优先使用原始Geist缩放角色，然后派生语义别名，如
```
background
```
,
```
foreground
```
,
```
muted-foreground
```
,
```
border
```
,
```
ring
```
,
```
link
```
,
```
info
```
,
```
destructive
```
,
```
success
```
, 和
```
warning
```
。如果项目已公开官方Geist/Core令牌或生成的CSS变量，则将语义别名映射到这些变量，无需复制原始层。如果存在
```
accent
```
别名，它必须解析为特定的官方Geist角色或缩放比例，用于焦点、选择、链接或状态，绝不能是装饰性调色板。
保持类列表可读并与现有项目约定一致。
优先使用语义组件类或变体处理重复模式。
任意颜色、排版、圆角、阴影、焦点、环、材质和状态值仅可出现在共享令牌、工具、变体或原语定义中。路由、页面、屏幕和功能文件必须使用命名令牌、工具、变体或原语，而非一次性任意值。

Anti-Patterns And Failure Modes

反模式和失败模式

Geist is a restraint-first production style. When this skill conflicts with generic

frontend-design

guidance, this section wins. Do not apply instructions to be bold, unforgettable, maximal, experimental, surprising, ornamental, or visually striking unless the user explicitly asks for that and confirms it should override Geist. For Vercel/Geist work, differentiation comes from product clarity, precise typography, consistent tokens, and real workflow polish.

This section separates official-source checks from local Vercel/Geist taste heuristics. Official-source checks are enforceable only through the cited Geist foundation/component/brand pages or Web Interface Guidelines and can support

Docs Evidence

. Local taste heuristics are red flags for generic SaaS or template output; they do not satisfy

Docs Evidence

by themselves and must lead back to official docs before making strict Geist claims.

Reject or revise these failure modes before finishing:

Local heuristic: generic AI SaaS visual language such as giant "accelerate/build/automate" heroes, gradient headlines, glowing blobs/orbs, glass panels, noise overlays, floating feature pills, and fake customer/logo bands.
Local heuristic: decorative gradients, purple-blue sweeps, rainbow meshes, radial glow backgrounds, bokeh, aurora effects, spotlight blobs, or background effects that are not required by product meaning. Official check: any retained color/motion/material treatment must be justified by Colors, Materials, Animations, or Content evidence.
Official-source check: arbitrary accent colors, multi-hue dashboards, invented dark-mode palettes, or colors chosen for mood rather than official color roles and semantic product meaning violate the consulted Colors evidence.
Local restraint, not
```
Docs Evidence
```
: non-Geist typography such as expressive display fonts, font pairing experiments, Inter/Roboto/Space Grotesk swaps, global system-font fallbacks used as a design choice, or Geist Pixel outside a constrained display accent.
Official-source check: reject radii that violate the consulted Materials or component page. Component-specific rounded/pill variants are allowed only when the relevant official component page documents them and the usage matches that context.
Official-source check: composition fails only when page sections, cards inside cards, metric/list/form blocks, or app shell panels violate consulted Material, component, layout, or guideline evidence. Local heuristic: card-first or card-in-card template composition is a red flag unless tied back to official docs and user scope before strict claims.
Local heuristic: fake product substance such as mock/sample data, fake charts, fake users, fake notifications, imaginary integrations, placeholder metrics, or seeded examples used to make the UI look busy. Use the real data path, honest empty/loading/error states, or clearly user-provided content.
Local heuristic: marketing instead of workflow, including landing pages where an app should start, oversized hero before the usable surface, vague value props in operational screens, or "AI-powered" copy that does not describe a concrete capability. Confirm through the user's scope and Content evidence before treating it as a strict failure.
Official-source check: animation must clarify cause/effect or add deliberate delight, respect reduced motion, avoid
```
transition: all
```
, stay interruptible/input-driven, and use CSS/compositor-friendly properties when possible. Local heuristic: avoid scroll reveals, parallax, bounce, animated gradients, cursor effects, celebratory effects, or hover surprises in ordinary product surfaces unless the user explicitly asks and official motion checks still pass.
Local heuristic: layout spectacle such as asymmetry, overlap, diagonals, broken grids, oversized negative space, or edge-to-edge compositions that reduce scan speed in product UI.
Local heuristic: control overload where toolbars and sidebars expose many actions before the primary workflow is obvious; group or defer advanced controls and verify with interaction/content evidence.
Official-source check: low-contrast softness such as gray-on-gray text, subtle borders that disappear, muted controls without visible affordance, or hierarchy that relies on opacity alone violates Colors, Design, or Accessibility evidence.
Official-source check: inconsistent primitives such as one-off colors, radii, typography classes, shadows, button sizes, focus rings, or state styles fail when they bypass consulted Geist foundations/components.
Official-source check: brand misuse, including Vercel/Next/Turbo/v0 logos or wording that implies endorsement, affiliation, or product identity when the app is not actually that brand, violates Geist Brands evidence.

Failure handling:

If a design starts to look like a generic AI startup template, stop and simplify: remove decorative background effects, collapse competing CTAs, reduce color to neutral plus semantic status, and put the real workflow in the first viewport.
If the result depends on fake data to look complete, do not ship it. Wire real data, show an honest empty state, or ask the user for real content.
If the existing project has a different visual system and the user has not made it the final visual authority, migrate or adapt the whole touched app or requested surface to Geist through shared tokens and primitives. State a blocker only when an explicit non-Geist authority or hard scope constraint makes coherent whole-surface Geist migration impossible.
If the user asks for "more creative" without explicitly overriding Geist, increase polish through alignment, density, copy, state coverage, and interaction clarity, not through gradients, ornamental assets, or random colors.

Geist是优先克制的生产风格。当本技能与通用

frontend-design

指导冲突时，本节优先。不得应用大胆、令人难忘、最大化、实验性、惊喜、装饰性或视觉突出的指令，除非用户明确要求并确认应覆盖Geist。对于Vercel/Geist工作，差异化来自产品清晰度、精准排版、一致令牌和真实工作流优化。

本节将官方来源检查与本地Vercel/Geist品味启发法分开。官方来源检查仅可通过引用的Geist基础/组件/品牌页面或Web Interface Guidelines强制执行，并可支持

Docs Evidence

。本地品味启发法是通用SaaS或模板输出的危险信号；它们本身无法满足

Docs Evidence

要求，必须在做出严格Geist声明前回归官方文档。

在完成前拒绝或修改这些失败模式：

本地启发法：通用AI SaaS视觉语言，如巨大的“加速/构建/自动化”首屏、渐变标题、发光 blob/球体、玻璃面板、噪点叠加、浮动功能药丸和虚假客户/Logo带。
本地启发法：装饰性渐变、紫蓝色渐变、彩虹网格、径向发光背景、散景、极光效果、聚光灯 blob，或并非产品含义所需的背景效果。官方检查：任何保留的颜色/动效/材质处理必须通过颜色、材质、动画或内容证据证明合理。
官方来源检查：任意强调色、多色调仪表盘、自创深色模式调色板，或为情绪而非官方颜色角色和语义产品含义选择的颜色，违反了查阅的颜色证据。
本地克制，非
```
Docs Evidence
```
：非Geist排版，如富有表现力的显示字体、字体配对实验、Inter/Roboto/Space Grotesk替换、作为设计选择使用的全局系统字体回退，或在受限显示强调之外使用Geist Pixel。
官方来源检查：拒绝违反查阅的材质或组件页面的圆角。仅当相关官方组件页面记录了组件特定的圆角/药丸变体且使用符合该上下文时，才允许使用。
官方来源检查：仅当页面板块、卡片内嵌套卡片、指标/列表/表单块或应用外壳面板违反查阅的材质、组件、布局或指南证据时，组合才失败。本地启发法：卡片优先或卡片内嵌套卡片的模板组合是危险信号，除非在做出严格声明前与官方文档和用户范围关联。
本地启发法：虚假产品内容，如模拟/示例数据、虚假图表、虚假用户、虚假通知、虚构集成、占位符指标或种子示例，用于使UI看起来繁忙。使用真实数据路径、诚实的空/加载/错误状态，或明确的用户提供内容。
本地启发法：营销而非工作流，包括应用应启动的着陆页、可用界面之前的超大首屏、操作屏幕中的模糊价值主张，或未描述具体功能的“AI驱动”文案。在将其视为严格失败之前，通过用户范围和内容证据确认。
官方来源检查：动画必须明确因果关系或添加有意的愉悦感、尊重减少动效、避免
```
transition: all
```
、保持可中断/输入驱动，并尽可能使用CSS/合成器友好的属性。本地启发法：在普通产品界面中避免滚动显示、视差、弹跳、动画渐变、光标效果、庆祝效果或悬停惊喜，除非用户明确要求且官方动效检查仍通过。
本地启发法：布局特效，如不对称、重叠、对角线、破碎网格、超大负空间或边缘到边缘组合，降低产品UI的扫描速度。
本地启发法：控件过载，工具栏和侧边栏在主要工作流明确之前暴露许多操作；分组或推迟高级控件，并通过交互/内容证据验证。
官方来源检查：低对比度柔和效果，如灰底灰字、消失的微妙边框、无可见提示的弱化控件，或仅依赖透明度构建层级，违反了颜色、设计或可访问性证据。
官方来源检查：不一致的原语，如一次性颜色、圆角、排版类、阴影、按钮大小、焦点环或状态样式，当它们绕过查阅的Geist基础/组件时失败。
官方来源检查：品牌误用，包括Vercel/Next/Turbo/v0标志或措辞暗示认可、关联或产品身份，而应用实际上并非该品牌，违反了Geist Brands证据。

失败处理：

如果设计开始看起来像通用AI初创公司模板，停止并简化：移除装饰性背景效果、合并竞争CTA、将颜色减少到中性加语义状态，并将真实工作流放在第一个视口中。
如果结果依赖虚假数据看起来完整，不得交付。连接真实数据、显示诚实的空状态，或向用户请求真实内容。
如果现有项目具有不同的视觉系统且用户未将其指定为最终视觉权威，则通过共享令牌和原语将整个受影响的应用或请求界面迁移或适配到Geist。仅当明确的非Geist权威或硬范围约束使连贯的全界面Geist迁移不可能时，才声明受阻。
如果用户要求“更具创意”但未明确覆盖Geist，则通过对齐、密度、文案、状态覆盖和交互清晰度提高优化，而非通过渐变、装饰性资产或随机颜色。

Vercel Taste Gate

Vercel品味审核

This is a mandatory visual quality gate for any frontend task using this skill. The work is not done until evidence shows the app or verified scope passes a Vercel/Geist audit. Do not finish from code inspection alone when a local app can run.

Required audit loop when the app/code can be exercised; capture screenshots whenever a local page can run:

Run the local app or page through the project's normal development command and record the command plus URL.
Perform Scope Discovery before screenshots: inspect framework route files/config, navigation/link usage, sitemap or build route output when available, and real app entrypoints. Include Storybook/examples only when they are real app surfaces. Record inaccessible, auth-gated, environment-gated, or dynamic routes with concrete blocker reasons. Create a route/surface/state inventory before screenshots:
```
route/surface | discovery source | required states | mobile screenshot | laptop screenshot | desktop screenshot | ultra-wide screenshot | interaction audit | status
```
. For greenfield/full redesign/broad polish work, every discovered routable surface and required shared state must appear in the inventory; whole-app claims fail if any row is missing or incomplete.
If the app runs, attempt Browser or Playwright mobile, laptop, desktop, and ultra-wide screenshots for each inventory row. Include the first viewport and any changed states such as menus, dialogs, empty states, loading states, errors, or dense data views. Record the command, URL, viewport sizes, screenshot paths, and state. Valid screenshot blockers are limited to app cannot build/run, missing auth or environment values, browser/screenshot tool unavailable after a named attempt, or route unreachable after the discovery source was checked. If screenshots are possible and not captured, do not claim the Vercel Taste Gate passed.
Run an interaction audit for every changed flow using an applicability matrix:
```
check | pass/fail/N/A | reason/evidence
```
. Cover keyboard-only operation, visible
```
:focus-visible
```
/
```
:focus-within
```
, overlay initial/trapped/restored focus, Escape/Enter/Cmd/Ctrl+Enter behavior, label activation, desktop >=24px and mobile >=44px targets, URL state plus Back/Forward/refresh/scroll restoration, optimistic update rollback/Undo, tooltip timing, intentional
```
overscroll-behavior
```
, clean drag behavior, locale-aware shortcuts, browser
```
theme-color
```
/
```
color-scheme
```
, and accessibility tree names/states/hidden decoration. Applicability triggers are mandatory: overlays require focus checks; mutations require optimistic/rollback or explicit non-applicability; tooltips require timing checks when present; filters, tabs, search, pagination, expanded panels, selected views, and any visible workflow state require URL-state checks; drag/reorder features require drag checks; icon-only controls require accessibility-tree verification. Conditional checks may be
```
N/A
```
only with a specific reason tied to absent UI/behavior. Revise failures before judging screenshots.
Compare the rendered UI against Geist foundations and relevant Geist components from the official reference map.
Deterministically check for the official Web Interface Guidelines review path. In Codex, use an installed repo command or slash command only if the current agent actually supports it and a concrete command, file, or documented invocation is present. Otherwise, if network access allows, fetch and use the raw command prompt from
```
https://raw.githubusercontent.com/vercel-labs/web-interface-guidelines/main/command.md
```
for a manual audit. Record the exact command/file/path or raw URL used. Run the installer only with explicit user or project opt-in and record the reason. Skills.sh and raw GitHub prompts may only route or run an audit helper; they cannot supply design-system authority, cannot satisfy
```
Docs Evidence
```
, and cannot replace reading
```
https://vercel.com/design/guidelines
```
in the current turn. If none can be run, record the exact blocker and continue with the manual guidelines audit.
Identify every place where the UI fails the evidence-backed pass criteria or trips local generic-SaaS heuristics.
Revise the implementation, then inspect fresh screenshots and rerun the interaction audit.
Repeat until the screenshots and interaction audit pass every rule below.

Pass criteria:

Route/surface/state inventory is complete for the verified scope, with discovery source plus mobile, laptop, desktop, and ultra-wide screenshot evidence or valid recorded blockers for every row.
Foundation evidence is visible in implementation: Geist Sans/Mono usage, Geist Pixel only when a constrained display accent is intentionally used and otherwise verified absent, Colors roles, Typography utilities, Materials/radii, focus rings, app shell, and shared state primitives are mapped in real files and used by changed screens.
Component evidence is visible in implementation: every UI pattern that maps to Geist has a matching component page, exact section/quote evidence, applicable Best Practices when present, and changed code that follows the documented behavior/content/accessibility rule.
Web Interface Guidelines evidence is complete: interaction applicability matrix has pass/fail/N/A plus reasons, and failures were revised or explicitly blocked.
Screenshots show the real product/workflow in the first viewport for every verified route/surface, not a generic landing page unless the user explicitly requested marketing.
Screenshots and code show one coherent system: shared tokens/classes/materials/primitives are reused, and there are no isolated Geist-looking components inside unrelated styling.
Typography uses the mapped Geist categories/utilities and does not rely on giant generic headlines, all-bold headings, or default
```
text-base
```
everywhere.
Color uses official roles or mapped project tokens; accents appear only for brand, links, selection, status, or focus.
Materials and radii follow consulted Materials/component evidence; depth is structural and does not rely on loud shadows, glass panels, or decorative background effects.
Mobile, laptop, desktop, and ultra-wide screenshots preserve layout integrity: no clipped text, overlapping controls, broken grids, unwanted scrollbars, or oversized card stacks.
Generic SaaS heuristic diff is recorded: any template-like, ornamental, overly soft, overly colorful, or disconnected areas were identified and revised, or explicitly tied to both official docs and user scope before any strict/Vercel Taste Gate claim.

Official claim blockers:

Final answer lacks page-specific
```
Docs Evidence
```
for every official Geist/Vercel page required for the task, or cites only memory, class names, token names, screenshots, or generic Geist adjectives.
A final answer claims visual polish or Vercel Taste Gate passage without screenshot inspection and interaction audit when those checks were possible.
Any required applied foundation, guideline, component, or brand row is missing, blocked, lacks an exact section/anchor, or lacks a page-specific short quote that affected a concrete decision.
Any Web Interface Guidelines interaction failure remains unrevised without a concrete blocker.

Local anti-template heuristics:

These require revision or explicit user-scope plus official-doc justification before strict claims, but they are not official Geist violations by themselves and do not satisfy

Docs Evidence

Purple-blue gradient SaaS aesthetic.
Decorative orbs, bokeh blobs, aurora backgrounds, or ornamental SVG filler.
Oversized rounded cards used as page sections.
Card-in-card layouts.
Heavy drop shadows or glassy panels.
Fake sample data added only to make the UI look populated.
Marketing copy inside product workflows.
Dozens of visible controls before the primary task is clear.
Mixed visual systems where only isolated buttons or cards look Geist-like.

If the app cannot be run, screenshots cannot be captured, or interaction checks cannot be performed, say that explicitly in the final response and do not claim the Vercel Taste Gate passed. If screenshots and interaction checks are possible, the final response must include the audit evidence: dev command, URL, mobile/laptop/desktop/ultra-wide viewport sizes, screenshot paths, changed states inspected, interaction applicability matrix summary, blockers, and revision decisions made because of the audits. Use an inspection method instead of screenshot paths only when screenshot capture is blocked, and then do not claim the Vercel Taste Gate passed.

Failure response:

If any pass criterion fails and the file is editable, make another revision.
If the failure cannot be fixed without user input or external access, explain the exact blocker and the closest safe fallback.
In the final response, briefly state which checks ran and whether any visual verification was blocked.

这是使用本技能的任何前端任务的强制性视觉质量审核。在证据表明应用或验证范围通过Vercel/Geist审核之前，工作未完成。当本地应用可运行时，不得仅通过代码检查完成工作。

当应用/代码可运行时的必要审核循环；每当本地页面可运行时捕获截图：

通过项目的常规开发命令运行本地应用或页面，并记录命令和URL。
在截图之前执行范围发现：检查框架路由文件/配置、导航/链接使用情况、站点地图或构建路由输出（如果可用），以及真实应用入口。仅当Storybook/示例是真实应用界面时才包含它们。记录无法访问、需要认证、环境受限或动态路由的具体受阻原因。在截图之前创建路由/界面/状态清单：
```
路由/界面 | 发现来源 | 必要状态 | 移动端截图 | 笔记本电脑截图 | 桌面端截图 | 超宽截图 | 交互审核 | 状态
```
。对于全新应用/全面重设计/大范围优化工作，每个发现的可路由界面和必要共享状态必须出现在清单中；如果任何行缺失或不完整，全应用声明失败。
如果应用运行，尝试为清单中的每一行获取Browser或Playwright移动端、笔记本电脑、桌面端和超宽截图。包含第一个视口和任何变化状态，如菜单、对话框、空状态、加载状态、错误或密集数据视图。记录命令、URL、视口大小、截图路径和状态。有效的截图受阻原因仅限于应用无法构建/运行、缺少认证或环境值、浏览器/截图工具尝试后不可用，或检查发现来源后路由无法访问。如果截图可行但未捕获，不得声称通过Vercel品味审核。
使用适用性矩阵对每个更改的流程执行交互审核：
```
检查项 | 通过/失败/不适用 | 原因/证据
```
。涵盖仅键盘操作、可见的
```
:focus-visible
```
/
```
:focus-within
```
、覆盖初始/捕获/恢复焦点、Escape/Enter/Cmd/Ctrl+Enter行为、标签激活、桌面端>=24px和移动端>=44px目标、URL状态加后退/前进/刷新/滚动恢复、乐观更新回退/撤销、工具提示计时、有意的
```
overscroll-behavior
```
、流畅的拖拽行为、支持区域设置的快捷键、浏览器
```
theme-color
```
/
```
color-scheme
```
，以及可访问性树名称/状态/隐藏装饰。适用性触发是强制性的：覆盖需要焦点检查；突变需要乐观/回滚或明确不适用；存在工具提示时需要计时检查；筛选器、标签、搜索、分页、展开面板、选中视图和任何可见工作流状态需要URL状态检查；拖拽/重新排序功能需要拖拽检查；仅图标控件需要可访问性树验证。条件检查仅在有特定原因关联缺失的UI/行为时才可标记为
```
不适用
```
。在判断截图之前修改失败项。
将渲染的UI与Geist基础和官方参考映射中的相关Geist组件进行比较。
确定性检查官方Web Interface Guidelines审查路径。在Codex中，仅当当前代理实际支持且存在具体命令、文件或文档化调用时，才使用已安装的仓库命令或斜杠命令。否则，如果网络允许，获取并使用
```
https://raw.githubusercontent.com/vercel-labs/web-interface-guidelines/main/command.md
```
的原始命令提示进行手动审核。记录使用的确切命令/文件/路径或原始URL。仅在用户或项目明确选择加入时运行安装程序，并记录原因。Skills.sh和原始GitHub提示仅可路由或运行审核辅助工具；它们无法提供设计系统权威，无法满足
```
Docs Evidence
```
要求，也无法替代在当前回合读取
```
https://vercel.com/design/guidelines
```
。如果无法运行任何审核，记录确切受阻原因并继续手动指南审核。
识别UI不符合证据支持的通过标准或触发本地通用SaaS启发法的每个地方。
修改实现，然后检查新截图并重新运行交互审核。
重复直到截图和交互审核通过以下所有规则。

通过标准：

验证范围的路由/界面/状态清单完整，每个行都有发现来源加移动端、笔记本电脑、桌面端和超宽截图证据，或有效的记录受阻原因。
基础证据在实现中可见：Geist Sans/Mono使用、仅在有意使用受限显示强调时使用Geist Pixel且否则验证不存在、颜色角色、排版工具、材质/圆角、焦点环、应用外壳和共享状态原语在真实文件中映射并被更改的屏幕使用。
组件证据在实现中可见：每个映射到Geist的UI模式都有匹配的组件页面、确切章节/引用证据、适用的最佳实践（如果存在），以及遵循文档化行为/内容/可访问性规则的更改代码。
Web Interface Guidelines证据完整：交互适用性矩阵有通过/失败/不适用加原因，且失败项已修改或明确受阻。
截图显示每个验证路由/界面的第一个视口中是真实产品/工作流，而非通用着陆页，除非用户明确要求营销。
截图和代码显示一个连贯的系统：共享令牌/类/材质/原语被重用，且无关样式中没有孤立的类Geist组件。
排版使用映射的Geist类别/工具，不依赖巨大的通用标题、全粗体标题或全局
```
text-base
```
。
颜色使用官方角色或映射的项目令牌；强调仅用于品牌、链接、选择、状态或焦点。
材质和圆角遵循查阅的材质/组件证据；深度是结构性的，不依赖夸张阴影、玻璃面板或装饰性背景效果。
移动端、笔记本电脑、桌面端和超宽截图保持布局完整性：无文本裁剪、控件重叠、破碎网格、不必要的滚动条或超大卡片堆叠。
记录通用SaaS启发法差异：任何类模板、装饰性、过于柔和、过于多彩或不连贯的区域已被识别和修改，或在做出任何严格/Vercel品味审核声明之前明确关联到官方文档和用户范围。

官方声明受阻原因：

最终答案缺少任务所需的每个官方Geist/Vercel页面的页面特定
```
Docs Evidence
```
，或仅引用记忆、类名、令牌名、截图或通用Geist形容词。
当截图检查和交互审核可行时，最终答案声称视觉优化或通过Vercel品味审核，但未进行截图检查和交互审核。
任何已应用的必要基础、指南、组件或品牌行缺失、受阻、缺少确切章节/锚点，或缺少影响具体决策的页面特定简短引用。
任何Web Interface Guidelines交互失败未修改且无具体受阻原因。

本地反模板启发法：

在做出严格声明之前，这些需要修改或明确用户范围加官方文档证明，但它们本身并非官方Geist违规，也无法满足

Docs Evidence

要求。

紫蓝色渐变SaaS美学。
装饰性球体、散景 blob、极光背景或装饰性SVG填充。
用作页面板块的超大圆角卡片。
卡片内嵌套卡片布局。
厚重的投影或玻璃面板。
仅为使UI看起来填充而添加的虚假示例数据。
产品工作流中的营销文案。
在主要任务明确之前显示数十个可见控件。
混合视觉系统，仅孤立的按钮或卡片看起来像Geist风格。

如果应用无法运行、无法捕获截图或无法执行交互检查，需在最终响应中明确说明，不得声称通过Vercel品味审核。如果截图和交互检查可行，最终响应必须包含审核证据：开发命令、URL、移动端/笔记本电脑/桌面端/超宽视口大小、截图路径、检查的变化状态、交互适用性矩阵摘要、受阻原因，以及因审核做出的修改决策。仅当截图捕获受阻时，才可使用检查方法替代截图路径，且不得声称通过Vercel品味审核。

失败响应：

如果任何通过标准失败且文件可编辑，进行另一次修改。
如果无法在无用户输入或外部访问的情况下修复失败，说明确切受阻原因和最接近的安全回退方案。
在最终响应中简要说明运行了哪些检查以及是否有任何视觉验证受阻。

Final Verification Checklist

最终验证清单

Before finishing any task using this skill that creates, changes, critiques, specifies, or materially directs rendered UI, verify:

The first viewport shows the real product/workflow, not a generic landing page unless explicitly requested.
Verification scope is explicit: greenfield/full redesign/broad polish covers all routable app surfaces; narrow existing-project work covers the requested workflow and touched shared primitives, and the final response says
```
whole app not verified
```
unless every route/surface was audited.
The Geist foundation gate was completed before screen design: fonts, tokens, typography utilities, material/radius utilities, focus rings, app shell, required component primitives, shared state system, and screen composition rules are wired through real app entrypoints, theme/Tailwind/CSS files, shared primitives, and app shell, and consumed by changed screens.
Screen-level styles compose shared Geist foundations, primitives, and state APIs/classes; they do not introduce one-off colors, font stacks, radii, focus rings, shadows, state styles, or component behavior.
Strict Geist work uses local Geist Sans and Geist Mono. Non-Geist font replacements are allowed only after an explicit non-Geist visual-system override, and those surfaces cannot be claimed as strict/docs-verified Geist. Geist Pixel is installed/loaded only if a display accent uses it, and it is absent from ordinary product UI text.
Typography uses official Geist classes or mapped equivalents for headings, buttons, labels, copy, mono, and tabular numeric text.
Color roles use official Geist/Core tokens or custom raw Geist scale variables before semantic aliases such as
```
background
```
,
```
foreground
```
,
```
muted-foreground
```
,
```
border
```
,
```
ring
```
,
```
link
```
,
```
info
```
,
```
destructive
```
,
```
success
```
, and
```
warning
```
. Any
```
accent
```
alias resolves to a specific official Geist role/scale for focus, selection, link, or status; default/primary actions follow the consulted Button/component page.
Chart/status palettes use redundant cues and color-blind-friendly choices, APCA contrast is checked where available, and hover/active/focus states increase contrast over rest state.
Materials use the official 6px, 12px, and 16px radius scale or mapped project tokens.
Every UI pattern that exists in Geist was checked against its Geist reference before custom implementation.
Official Geist/Vercel pages required for the task are listed in a page-specific
```
Docs Evidence
```
table in the final response in all cases: consulted rows when read, blocked rows with exact tool failures when docs access fails, and the fallback label
```
local Geist fallback, not docs-verified
```
for affected surfaces.
Relevant component pages' Best Practices were followed, not just visual styling.
Vercel Web Interface Guidelines were applied for keyboard behavior, focus, hit targets, URL state, optimistic updates, tooltip timing, overscroll containment, clean drag behavior, locale-aware shortcuts, mobile inputs, states, copy, numerals/units, performance-relevant UI,
```
theme-color
```
, and
```
color-scheme
```
.
The app shell, navigation, forms, tables/lists, dialogs, menus, toasts, loading, empty, error, and no-dead-end recovery paths all share the same audited Geist tokens, typography utilities, materials, primitives, state rules, root background, gutters, header/sidebar/nav structure, dividers, max-width behavior, mobile behavior, one primary action zone, skip-to-content, valid heading hierarchy, and context-specific
```
<title>
```
.
Interactive controls have hover, active/pressed, selected/current, disabled, loading, validation, error, focus-visible, and reduced-motion states as relevant.
Tables, lists, forms, and screens have loading, empty, error, no-results, validation, and recovery states as relevant.
Desktop, mobile, laptop, and ultra-wide views were inspected when a local app can run; layouts do not overlap, clip text, shift unpredictably, create unwanted scrollbars, or break safe-area insets.
Local anti-template heuristics such as generic SaaS gradients, decorative orbs, card-in-card sections, fake sample data, and unrelated visual styles are absent or revised; retained exceptions are tied to both explicit user scope and official docs, otherwise no strict/Vercel Taste Gate claim is made.

在完成使用本技能创建、更改、评判、指定或实质性指导渲染UI的任何任务之前，验证：

第一个视口显示真实产品/工作流，而非通用着陆页，除非明确要求。
验证范围明确：全新应用/全面重设计/大范围优化覆盖所有可路由应用界面；现有项目窄范围工作覆盖请求的工作流和受影响的共享原语，且除非审核了每个路由/界面，否则最终响应需注明
```
whole app not verified
```
。
在屏幕设计之前完成了Geist基础审核：字体、令牌、排版工具、材质/圆角工具、焦点环、应用外壳、必要组件原语、共享状态系统和屏幕组合规则已通过真实应用入口、主题/Tailwind/CSS文件、共享原语和应用外壳连接，并被更改的屏幕使用。
屏幕级样式组合共享的Geist基础、原语和状态API/类；未引入一次性颜色、字体栈、圆角、焦点环、阴影、状态样式或组件行为。
严格Geist工作使用本地Geist Sans和Geist Mono。仅在明确非Geist视觉系统覆盖后，才允许非Geist字体替换，且这些界面不得声称符合严格/文档验证的Geist。仅当显示强调使用Geist Pixel时才安装/加载它，且普通产品UI文本中不得使用。
排版使用官方Geist类或映射等效项处理标题、按钮、标签、复制、mono和表格数字文本。
颜色角色在语义别名（如
```
background
```
,
```
foreground
```
,
```
muted-foreground
```
,
```
border
```
,
```
ring
```
,
```
link
```
,
```
info
```
,
```
destructive
```
,
```
success
```
, 和
```
warning
```
）之前使用官方Geist/Core令牌或自定义原始Geist缩放变量。任何
```
accent
```
别名解析为特定的官方Geist角色/缩放比例，用于焦点、选择、链接或状态；默认/主要操作遵循查阅的Button/组件页面。
图表/状态调色板使用冗余提示和色盲友好选择，在可用时检查APCA对比度，且悬停/激活/焦点状态比静止状态提高对比度。
材质使用官方6px、12px和16px圆角缩放比例或映射的项目令牌。
在自定义实现之前，检查了Geist中存在的每个UI模式与其Geist参考。
任务所需的官方Geist/Vercel页面在所有情况下都列在最终响应的页面特定
```
Docs Evidence
```
表格中：已查阅的行（已读取）、受阻的行（文档访问失败时注明确切工具失败），以及受影响界面的回退标签
```
local Geist fallback, not docs-verified
```
。
遵循了相关组件页面的最佳实践，而非仅视觉样式。
应用了Vercel Web Interface Guidelines的键盘行为、焦点、点击目标、URL状态、乐观更新、工具提示计时、滚动包含、流畅拖拽行为、支持区域设置的快捷键、移动端输入、状态、文案、数字/单位、性能相关UI、
```
theme-color
```
和
```
color-scheme
```
。
应用外壳、导航、表单、表格/列表、对话框、菜单、提示框、加载、空、错误和无死胡同恢复路径都共享相同的审核Geist令牌、排版工具、材质、原语、状态规则、根背景、边距、页眉/侧边栏/导航结构、分隔线、最大宽度行为、移动端行为、一个主要操作区域、跳转到内容链接、有效的标题层级和上下文特定的
```
<title>
```
。
交互式控件在相关时具有悬停、激活/按下、选中/当前、禁用、加载、验证、错误、focus-visible和减少动效状态。
表格、列表、表单和屏幕在相关时具有加载、空、错误、无结果、验证和恢复状态。
当本地应用可运行时，检查了桌面端、移动端、笔记本电脑和超宽视图；布局无重叠、文本裁剪、不可预测的偏移、不必要的滚动条或安全区域内边距损坏。
本地反模板启发法（如通用SaaS渐变、装饰性球体、卡片内嵌套卡片板块、虚假示例数据和无关视觉样式）不存在或已修改；保留的例外情况关联到明确的用户范围和官方文档，否则不得做出严格/Vercel品味审核声明。