Back to Details

ce-frontend-design

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Frontend Design

前端设计

Guide creation of distinctive, production-grade frontend interfaces that avoid generic AI aesthetics. This skill covers the full lifecycle: detect what exists, plan the design, build with intention, and verify visually.
指导打造独具特色、可投入生产的前端界面，避免通用AI美学风格。本Skill覆盖完整生命周期：检测现有内容、规划设计、针对性构建、视觉验证。

Authority Hierarchy

权限优先级

Every rule in this skill is a default, not a mandate.
  1. Existing design system / codebase patterns -- highest priority, always respected
  2. User's explicit instructions -- override skill defaults
  3. Skill defaults -- apply in greenfield work or when the user asks for design guidance
When working in an existing codebase with established patterns, follow those patterns. When the user specifies a direction that contradicts a default, follow the user.
本Skill中的所有规则均为默认规则，而非强制要求。
  1. 现有设计系统/代码库模式 —— 优先级最高，始终遵循
  2. 用户明确指令 —— 覆盖Skill默认规则
  3. Skill默认规则 —— 适用于Greenfield项目或用户请求设计指导的场景
在已有既定模式的代码库中工作时，需遵循这些模式。当用户指定的方向与默认规则冲突时，以用户指令为准。

Workflow

工作流程

Detect context -> Plan the design -> Build -> Verify visually
Detect context -> Plan the design -> Build -> Verify visually

Layer 0: Context Detection

第0层：上下文检测

Before any design work, examine the codebase for existing design signals. This determines how much of the skill's opinionated guidance applies.
开展任何设计工作前，需检查代码库中的现有设计信号。这将决定本Skill的指导性建议适用程度。

What to Look For

检测内容

  • Design tokens / CSS variables: 
    --color-*
    , 
    --spacing-*
    , 
    --font-*
    custom properties, theme files
  • Component libraries: shadcn/ui, Material UI, Chakra, Ant Design, Radix, or project-specific component directories
  • CSS frameworks: 
    tailwind.config.*
    , 
    styled-components
    theme, Bootstrap imports, CSS modules with consistent naming
  • Typography: Font imports in HTML/CSS, 
    @font-face
    declarations, Google Fonts links
  • Color palette: Defined color scales, brand color files, design token exports
  • Animation libraries: Framer Motion, GSAP, anime.js, Motion One, Vue Transition imports
  • Spacing / layout patterns: Consistent spacing scale usage, grid systems, layout components
Use the platform's native file-search and content-search tools (e.g., Glob/Grep in Claude Code) to scan for these signals. Do not use shell commands for routine file exploration.
  • 设计令牌/CSS变量：
    --color-*
    、
    --spacing-*
    、
    --font-*
    自定义属性、主题文件
  • 组件库：shadcn/ui、Material UI、Chakra、Ant Design、Radix，或项目特定的组件目录
  • CSS框架：
    tailwind.config.*
    、
    styled-components
    主题、Bootstrap 导入、命名规范一致的CSS模块
  • 排版：HTML/CSS中的字体导入、
    @font-face
    声明、Google Fonts 链接
  • 调色板：已定义的色彩层级、品牌色彩文件、设计令牌导出
  • 动画库：Framer Motion、GSAP、anime.js、Motion One、Vue Transition 导入
  • 间距/布局模式：一致的间距层级使用、网格系统、布局组件
使用平台原生的文件搜索和内容搜索工具（如Claude Code中的Glob/Grep）扫描这些信号。日常文件探索请勿使用shell命令。

Mode Classification

模式分类

Based on detected signals, choose a mode:
  • Existing system (4+ signals across multiple categories): Defer to it. The skill's aesthetic opinions (typography, color, motion) yield to the established system. Structural guidance (composition, copy, accessibility, verification) still applies.
  • Partial system (1-3 signals): Follow what exists; apply skill defaults only for areas where no convention was detected. For example, if Tailwind is configured but no component library exists, follow the Tailwind tokens and apply skill guidance for component structure.
  • Greenfield (no signals detected): Full skill guidance applies.
  • Ambiguous (signals are contradictory or unclear): Ask the user before proceeding.
根据检测到的信号，选择对应模式：
  • 现有系统（多类别下检测到4个及以上信号）：遵循现有系统。Skill的美学建议（排版、色彩、动效）需让位于已建立的系统。结构指导（布局、文案、无障碍、验证）仍适用。
  • 部分系统（检测到1-3个信号）：遵循现有内容；仅在未检测到规范的领域应用Skill默认规则。例如，若已配置Tailwind但无组件库，则遵循Tailwind令牌并应用Skill的组件结构指导。
  • Greenfield（未检测到任何信号）：完全适用Skill指导。
  • 模糊场景（信号矛盾或不清晰）：继续操作前需询问用户。

Asking the User

询问用户

When context is ambiguous, use the platform's blocking question tool: 
AskUserQuestion
in Claude Code (call 
ToolSearch
with 
select:AskUserQuestion
first if its schema isn't loaded), 
request_user_input
in Codex, 
ask_user
in Gemini. Fall back to presenting options in chat only when no blocking tool exists in the harness or the call errors (e.g., Codex edit modes) — not because a schema load is required. Never silently skip. If the user declines to pick, assume "partial" mode and proceed conservatively.
Example question: "I found [detected signals]. Should I follow your existing design patterns or create something distinctive?"
当上下文模糊时，使用平台的阻塞式提问工具：Claude Code中的
AskUserQuestion
（若未加载其schema，先调用
ToolSearch
并指定
select:AskUserQuestion
）、Codex中的
request_user_input
、Gemini中的
ask_user
。仅当工具集中无阻塞式工具或调用出错（如Codex编辑模式）时，才退化为在聊天中提供选项——而非因需要加载schema而跳过。切勿静默跳过。若用户拒绝选择，则假设为“部分系统”模式并谨慎推进。
示例问题：“我检测到[已发现的信号]。我应遵循您现有的设计模式，还是打造独具特色的设计？”

Layer 1: Pre-Build Planning

第1层：构建前规划

Before writing code, write three short statements. These create coherence and give the user a checkpoint to redirect before code is written.
  1. Visual thesis -- one sentence describing the mood, material, and energy
    • Greenfield examples: "Clean editorial feel, lots of whitespace, serif headlines, muted earth tones" or "Dense data-forward dashboard, monospace accents, dark surface hierarchy"
    • Existing codebase: Describe the existing aesthetic and how the new work will extend it
  2. Content plan -- what goes on the page and in what order
    • Landing page: hero, support, detail, CTA
    • App: primary workspace, nav, secondary context
    • Component: what states it has, what it communicates
  3. Interaction plan -- 2-3 specific motion ideas that change the feel
    • Not "add animations" but "staggered fade-in on hero load, parallax on scroll between sections, scale-up on card hover"
    • In an existing codebase, describe only the interactions being added, using the existing motion library
编写代码前，需撰写三段简短陈述。这些陈述将确保设计连贯性，并为用户提供代码编写前的重定向检查点。
  1. 视觉主旨 —— 一句话描述风格基调、质感与活力
    • Greenfield示例：“简洁的编辑风格，大量留白，衬线标题，柔和大地色系”或“密集的数据导向型仪表盘，等宽字体点缀，深色层级背景”
    • 现有代码库：描述现有美学风格及新工作将如何延伸该风格
  2. 内容规划 —— 页面内容及排列顺序
    • 着陆页： hero区、支持区、详情区、CTA区
    • 应用：主工作区、导航栏、次要上下文/检查器
    • 组件：包含的状态、传达的信息
  3. 交互规划 —— 2-3个能改变风格质感的具体动效想法
    • 不要写“添加动画”，而是“hero区加载时的渐入 stagger 效果、段落间滚动视差效果、卡片 hover 时的缩放效果”
    • 在现有代码库中，仅描述新增的交互，并使用现有动效库

Layer 2: Design Guidance Core

第2层：核心设计指导

These principles apply across all context types. Each yields to existing design systems and user instructions per the authority hierarchy.
这些原则适用于所有上下文类型。根据权限优先级，所有原则需让位于现有设计系统和用户指令。

Typography

排版

  • Choose distinctive, characterful fonts. Avoid the usual suspects (Inter, Roboto, Arial, system defaults) unless the existing codebase uses them.
  • Two typefaces maximum without a clear reason for more. Pair a display/headline font with a body font.
  • Yields to existing font choices when detected in Layer 0.
  • 选择独具特色、富有个性的字体。除非现有代码库使用，否则避免常用字体（Inter、Roboto、Arial、系统默认字体）。
  • 无明确理由时，最多使用两种字体。将展示/标题字体与正文字体搭配使用。
  • 第0层检测到现有字体选择时，需遵循现有选择。

Color & Theme

色彩与主题

  • Commit to a cohesive palette using CSS variables. A dominant color with sharp accents outperforms timid, evenly-distributed palettes.
  • No purple-on-white bias, no dark-mode bias. Vary between light and dark based on context.
  • One accent color by default unless the product already has a multi-color system.
  • Yields to existing color tokens when detected.
  • 使用CSS变量打造连贯的调色板。主色调搭配鲜明强调色的效果优于平淡、均匀分布的调色板。
  • 不偏向紫白配色，不偏向深色模式。根据上下文在浅色与深色模式间切换。
  • 默认使用一种强调色，除非产品已有多色系统。
  • 第0层检测到现有色彩令牌时，需遵循现有令牌。

Composition

布局

  • Start with composition, not components. Treat the first viewport as a poster, not a document.
  • Use whitespace, alignment, scale, cropping, and contrast before adding chrome (borders, shadows, cards).
  • Default to cardless layouts. Cards are allowed when they serve as the container for a user interaction (clickable item, draggable unit, selectable option). If removing the card styling would not hurt comprehension, it should not be a card.
  • All composition rules are defaults. The user can override them.
  • 从布局开始，而非组件。将首屏视为海报，而非文档。
  • 在添加边框、阴影、卡片等装饰元素前，先使用留白、对齐、缩放、裁剪与对比。
  • 默认采用无卡片布局。仅当卡片作为用户交互容器（可点击项、可拖动单元、可选选项）时，才使用卡片。若移除卡片样式不影响理解，则不应使用卡片。
  • 所有布局规则均为默认规则，用户可覆盖。

Motion

动效

  • Ship 2-3 intentional motions for visually-led work: one entrance sequence, one scroll-linked or depth effect, one hover/reveal transition.
  • Use the project's existing animation library if one is present.
  • When no existing library is found, use framework-conditional defaults:
    • CSS animations as the universal baseline
    • Framer Motion for React projects
    • Vue Transition / Motion One for Vue projects
    • Svelte transitions for Svelte projects
  • Motion should be noticeable in a quick recording, smooth on mobile, and consistent across the page. Remove if purely ornamental.
  • 视觉导向型工作需实现2-3个有目的性的动效：一个入场序列、一个滚动关联或深度效果、一个hover/展示过渡效果。
  • 若项目已有动效库，使用该库。
  • 未发现现有库时，使用框架相关的默认选项：
    • CSS动画作为通用基准
    • React项目使用Framer Motion
    • Vue项目使用Vue Transition / Motion One
    • Svelte项目使用Svelte transitions
  • 动效应在快速录屏中可见，在移动端流畅，且在页面中保持一致。若仅为装饰性动效，需移除。

Accessibility

无障碍

  • Semantic HTML by default: 
    nav
    , 
    main
    , 
    section
    , 
    article
    , 
    button
    -- not divs for everything.
  • Color contrast meeting WCAG AA minimum.
  • Focus states on all interactive elements.
  • Accessibility and aesthetics are not in tension when done well.
  • 默认使用语义化HTML：
    nav
    、
    main
    、
    section
    、
    article
    、
    button
    —— 不要全部用div。
  • 色彩对比度符合WCAG AA最低标准。
  • 所有交互元素需有焦点状态。
  • 做好无障碍设计与美学设计并不冲突。

Imagery

图像

  • When images are needed, prefer real or realistic photography over abstract gradients or fake 3D objects.
  • Choose or generate images with a stable tonal area for text overlay.
  • If image generation tools are available in the environment, use them to create contextually appropriate visuals rather than placeholder stock.
  • 需要图像时，优先使用真实或写实照片，而非抽象渐变或伪3D对象。
  • 选择或生成带有稳定色调区域的图像，以便叠加文字。
  • 若环境中提供图像生成工具，使用其创建符合上下文的视觉内容，而非占位图库图片。

Context Modules

上下文模块

Select the module that fits what is being built. When working inside an existing application, default to Module C regardless of what the feature is.
选择与构建内容匹配的模块。在现有应用中工作时，无论功能类型如何，默认使用模块C。

Module A: Landing Pages & Marketing (Greenfield)

模块A：着陆页与营销（Greenfield）

Default section sequence:
  1. Hero -- brand/product, promise, CTA, one dominant visual
  2. Support -- one concrete feature, offer, or proof point
  3. Detail -- atmosphere, workflow, product depth, or story
  4. Final CTA -- convert, start, visit, or contact
Hero rules (defaults):
  • One composition, not a dashboard. Full-bleed image or dominant visual plane.
  • Brand first, headline second, body third, CTA fourth.
  • Keep the text column narrow and anchored to a calm area of the image.
  • No more than 6 sections total without a clear reason.
  • One H1 headline. One primary CTA above the fold.
Copy:
  • Let the headline carry the meaning. Supporting copy is usually one short sentence.
  • Write in product language, not design commentary. No prompt language or AI commentary in the UI.
  • Each section gets one job: explain, prove, deepen, or convert.
  • Every sentence should earn its place. Default to less copy, not more.
默认段落顺序：
  1. Hero区 —— 品牌/产品、价值主张、CTA、一个主视觉元素
  2. 支持区 —— 一个具体功能、优惠或证明点
  3. 详情区 —— 氛围、工作流程、产品深度或故事
  4. 最终CTA区 —— 转化、启动、访问或联系
Hero区规则（默认）：
  • 单一布局，而非仪表盘。全屏图像或主视觉平面。
  • 品牌优先，标题次之，正文第三，CTA第四。
  • 文本列保持窄幅，并锚定在图像的简洁区域。
  • 无明确理由时，总段落数不超过6个。
  • 一个H1标题。首屏上方一个主CTA。
文案：
  • 让标题承载核心含义。辅助文案通常为一句短句。
  • 使用产品语言，而非设计评论。UI中不得出现提示语或AI评论。
  • 每个段落承担一项任务：解释、证明、深化或转化。
  • 每句话都要有存在的意义。默认使用更少的文案，而非更多。

Module B: Apps & Dashboards (Greenfield)

模块B：应用与仪表盘（Greenfield）

Default patterns:
  • Calm surface hierarchy, strong typography and spacing, few colors, dense but readable information, minimal chrome.
  • Organize around: primary workspace, navigation, secondary context/inspector, one clear accent for action or state.
  • Cards only when the card is the interaction (clickable item, draggable unit, selectable option). If a panel can become plain layout without losing meaning, remove the card treatment.
Copy (utility, not marketing):
  • Prioritize orientation, status, and action over promise, mood, or brand voice.
  • Section headings should say what the area is or what the user can do there. Good: "Plan status", "Search metrics". Bad: "Unlock Your Potential".
  • If a sentence could appear in a homepage hero, rewrite it until it sounds like product UI.
  • Litmus: if an operator scans only headings, labels, and numbers, can they understand the page immediately?
默认模式：
  • 简洁的层级背景、清晰的排版与间距、少量色彩、密集但可读的信息、极少装饰元素。
  • 围绕以下内容组织：主工作区、导航栏、次要上下文/检查器、一个用于操作或状态的清晰强调色。
  • 仅当卡片作为交互载体（可点击项、可拖动单元、可选选项）时使用卡片。若面板移除卡片样式后不影响含义理解，则需移除卡片样式。
文案（实用型，非营销型）：
  • 优先考虑定位、状态与操作，而非价值主张、基调或品牌语音。
  • 段落标题应说明该区域是什么或用户可在此执行什么操作。示例：“计划状态”、“搜索指标”。反例：“释放你的潜能”。
  • 若一句话可出现在首页Hero区，则重写至其听起来像产品UI文案。
  • 测试标准：若操作员仅扫描标题、标签与数字，能否立即理解页面内容？

Module C: Components & Features (Default in Existing Apps)

模块C：组件与功能（现有应用默认）

For adding to an existing application:
  • Match the existing visual language. This module is about making something that belongs, not something that stands out.
  • Inherit spacing scale, border radius, color tokens, and typography from surrounding code.
  • Focus on interaction quality: clear states (default, hover, active, disabled, loading, error), smooth transitions between states, obvious affordances.
  • One new component should not introduce a new design system. If the existing app uses 4px border radius, do not add a component with 8px.
在现有应用中添加内容时：
  • 匹配现有视觉语言。本模块旨在打造融入现有系统的内容，而非突出的内容。
  • 从周边代码继承间距层级、边框圆角、色彩令牌与排版。
  • 关注交互质量：清晰的状态（默认、hover、激活、禁用、加载、错误）、状态间的平滑过渡、明显的交互提示。
  • 新增组件不得引入新的设计系统。若现有应用使用4px边框圆角，不得添加使用8px边框圆角的组件。

Hard Rules & Anti-Patterns

硬性规则与反模式

Default Against (Overridable)

默认避免（可覆盖）

These are the skill being opinionated. The user can override any of them.
  • Generic SaaS card grid as the first impression
  • Purple-on-white color schemes, dark-mode bias
  • Overused fonts (Inter, Roboto, Arial, Space Grotesk, system defaults) in greenfield work
  • Hero sections cluttered with stats, schedules, pill clusters, logo clouds
  • Sections that repeat the same mood statement in different words
  • Carousel with no narrative purpose
  • Multiple competing accent colors
  • Decorative gradients or abstract backgrounds standing in for real visual content
  • Copy that sounds like design commentary ("Experience the seamless integration")
  • Split-screen heroes where text sits on the busy side of an image
这些是Skill的倾向性规则，用户可覆盖任意规则。
  • 将通用SaaS卡片网格作为第一印象
  • 紫白配色方案、深色模式偏向
  • Greenfield项目中使用过度泛滥的字体（Inter、Roboto、Arial、Space Grotesk、系统默认字体）
  • Hero区充斥统计数据、日程安排、标签组、Logo云
  • 重复相同基调陈述的段落
  • 无叙事目的的轮播图
  • 多种相互竞争的强调色
  • 替代真实视觉内容的装饰性渐变或抽象背景
  • 听起来像设计评论的文案（如“体验无缝集成”）
  • 文本位于图像繁忙区域的分屏Hero区

Always Avoid (Quality Floor)

始终避免（质量底线）

These are genuine quality failures no user would want.
  • Prompt language or AI commentary leaking into the UI
  • Broken contrast -- text unreadable over images or backgrounds
  • Interactive elements without visible focus states
  • Semantic div soup when proper HTML elements exist
这些是用户绝不会想要的真正质量问题。
  • 提示语或AI评论泄露至UI中
  • 对比度失效——图像或背景上的文本不可读
  • 无可见焦点状态的交互元素
  • 存在合适HTML元素时仍使用语义化缺失的div堆砌

Litmus Checks

测试检查

Quick self-review before moving to visual verification. Not all checks apply in every context -- apply judgment about which are relevant.
  • Is the brand or product unmistakable in the first screen?
  • Is there one strong visual anchor?
  • Can the page be understood by scanning headlines only?
  • Does each section have one job?
  • Are cards actually necessary where they are used?
  • Does motion improve hierarchy or atmosphere, or is it just there?
  • Would the design feel premium if all decorative shadows were removed?
  • Does the copy sound like the product, not like a prompt?
  • Does the new work match the existing design system? (Module C)
进入视觉验证前的快速自我审查。并非所有检查都适用于所有上下文——需判断哪些检查相关。
  • 首屏能否清晰识别品牌或产品？
  • 是否有一个强视觉锚点？
  • 仅扫描标题能否理解页面内容？
  • 每个段落是否承担一项任务？
  • 使用卡片的地方是否真的需要卡片？
  • 动效是否提升了层级或氛围，还是仅仅存在？
  • 移除所有装饰性阴影后，设计是否仍显高端？
  • 文案听起来像产品语言，而非提示语？
  • 新工作是否匹配现有设计系统？（模块C）

Visual Verification

视觉验证

After implementing, verify visually. This is a sanity check, not a pixel-perfect review. One pass. If there is a glaring issue, fix it. If it looks solid, move on.
实现后，进行视觉验证。这是合理性检查，而非像素级审查。仅一轮检查。若存在明显问题，修复问题。若看起来没问题，则继续推进。

Tool Preference Cascade

工具优先级

Use the first available option:
  1. Existing project browser tooling -- if Playwright, Puppeteer, Cypress, or similar is already in the project's dependencies, use it. Do not introduce new dependencies just for verification.
  2. Browser MCP tools -- if browser automation tools (e.g., claude-in-chrome) are available in the agent's environment, use them.
  3. agent-browser CLI -- if nothing else is available and 
    agent-browser
    is installed, use it. If not installed, inform the user: "
    agent-browser
    is not installed. Run 
    /ce-setup
    to install required dependencies." Then skip to the next option.
  4. Mental review -- if no browser access is possible (headless CI, no permissions to install), apply the litmus checks as a self-review and note that visual verification was skipped.
使用第一个可用选项：
  1. 现有项目浏览器工具 —— 若项目依赖中已有Playwright、Puppeteer、Cypress等工具，使用这些工具。不得仅为验证引入新依赖。
  2. 浏览器MCP工具 —— 若代理环境中提供浏览器自动化工具（如claude-in-chrome），使用这些工具。
  3. agent-browser CLI —— 若无其他可用工具且已安装
    agent-browser
    ，使用该工具。若未安装，告知用户：“
    agent-browser
    未安装。运行
    /ce-setup
    安装所需依赖。” 然后跳至下一选项。
  4. 心理审查 —— 若无法访问浏览器（无头CI、无安装权限），应用测试检查进行自我审查，并注明已跳过视觉验证。

What to Assess

评估内容

  • Does the output match the visual thesis from the pre-build plan?
  • Are there obvious visual problems (broken layout, unreadable text, missing images)?
  • Does it look like the context module intended (landing page feels like a landing page, dashboard feels like a dashboard, component fits its surroundings)?
  • 输出是否符合构建前规划中的视觉主旨？
  • 是否存在明显视觉问题（布局错乱、文本不可读、图像缺失）？
  • 是否符合上下文模块的预期（着陆页看起来像着陆页、仪表盘看起来像仪表盘、组件融入周边环境）？

Scope Control

范围控制

One iteration. Take a screenshot, assess against the litmus checks, fix any glaring issues, and move on. Include the screenshot in the deliverable (PR description, conversation output, etc.).
For iterative refinement beyond a single pass (multiple rounds of screenshot-assess-fix), see the 
ce-design-iterator
agent.
仅一轮迭代。截图，对照测试检查评估，修复明显问题，然后推进。将截图包含在交付物中（PR描述、对话输出等）。
如需多轮迭代优化（多轮截图-评估-修复），请使用
ce-design-iterator
agent。

Creative Energy

创意活力

This skill provides structure, but the goal is distinctive work that avoids AI slop -- not formulaic output.
For greenfield work, commit to a bold aesthetic direction. Consider the tone: brutally minimal, maximalist, retro-futuristic, organic/natural, luxury/refined, playful, editorial, brutalist, art deco, soft/pastel, industrial -- or invent something that fits the context. There are endless flavors. Use these for inspiration but design one that is true to the project.
Ask: what makes this unforgettable? What is the one thing someone will remember?
Match implementation complexity to the aesthetic vision. Maximalist designs need elaborate code with extensive animations and effects. Minimalist designs need restraint, precision, and careful attention to spacing, typography, and subtle details. Elegance comes from executing the vision well, not from intensity.
本Skill提供结构，但目标是打造独具特色的作品，避免AI生成的粗糙产物——而非公式化输出。
对于Greenfield项目，需致力于大胆的美学方向。考虑风格基调：极简主义、极繁主义、复古未来主义、有机/自然风、奢华/精致风、趣味风、编辑风、粗野主义、装饰艺术风、柔和/马卡龙风、工业风——或创造符合上下文的风格。风格种类繁多。可将这些作为灵感，但需设计出符合项目需求的独特风格。
思考：什么让这个设计令人难忘？人们会记住哪一点？
实现复杂度需与美学愿景匹配。极繁主义设计需要包含大量动画与效果的复杂代码。极简主义设计需要克制、精准，并关注间距、排版与细节。优雅源于对愿景的出色执行，而非强度。