Back to Details

i-impeccable

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese
This skill guides creation of distinctive, production-grade frontend interfaces that avoid generic "AI slop" aesthetics. Implement real working code with exceptional attention to aesthetic details and creative choices.
本技能可指导你创建独具特色、生产级别的前端界面，规避千篇一律的「AI劣质同质化」审美。输出可实际运行的代码，同时对美学细节和创意选择保持极高的关注度。

Context Gathering Protocol

上下文收集协议

Design skills produce generic output without project context. You MUST have confirmed design context before doing any design work.
Required context (every design skill needs at minimum):
  • Target audience: Who uses this product and in what context?
  • Use cases: What jobs are they trying to get done?
  • Brand personality/tone: How should the interface feel?
Individual skills may require additional context. Check the skill's preparation section for specifics.
CRITICAL: You cannot infer this context by reading the codebase. Code tells you what was built, not who it's for or what it should feel like. Only the creator can provide this context.
Gathering order:
  1. Check current instructions (instant): If your loaded instructions already contain a Design Context section, proceed immediately.
  2. Check .impeccable.md (fast): If not in instructions, read 
    .impeccable.md
    from the project root. If it exists and contains the required context, proceed.
  3. Run impeccable teach (REQUIRED): If neither source has context, you MUST run /impeccable teach NOW before doing anything else. Do NOT skip this step. Do NOT attempt to infer context from the codebase instead.
没有项目上下文的话，设计技能只会输出通用化内容。在开展任何设计工作前，你必须先确认已获取设计上下文。
必填上下文（所有设计技能最低要求）：
  • 目标受众：该产品的使用者是谁？使用场景是什么？
  • 使用场景：用户需要用该产品完成什么任务？
  • 品牌个性/调性：界面应该传递什么样的感受？
单独的技能可能需要额外的上下文，请查看对应技能的准备章节了解具体要求。
重要提示：你不能通过读取代码库来推断这些上下文。代码只会告诉你已经构建了什么，不会告诉你受众是谁，也不会告诉你产品应该传递什么感受，只有产品创建者才能提供这些信息。
收集顺序：
  1. 检查当前指令（即时）：如果你加载的指令中已经包含「设计上下文」章节，可直接继续工作。
  2. 检查.impeccable.md（快速）：如果指令中没有相关内容，读取项目根目录下的
    .impeccable.md
    文件。如果该文件存在且包含所需上下文，可直接继续工作。
  3. 运行impeccable teach（必填）：如果上述两个来源都没有上下文，你必须现在就运行
    /impeccable teach
    ，再开展其他工作。请勿跳过该步骤，也不要尝试从代码库推断上下文。

Design Direction

设计方向

Commit to a BOLD aesthetic direction:
  • Purpose: What problem does this interface solve? Who uses it?
  • Tone: Pick an extreme: brutally minimal, maximalist chaos, retro-futuristic, organic/natural, luxury/refined, playful/toy-like, editorial/magazine, brutalist/raw, art deco/geometric, soft/pastel, industrial/utilitarian, etc. There are so many flavors to choose from. Use these for inspiration but design one that is true to the aesthetic direction.
  • Constraints: Technical requirements (framework, performance, accessibility).
  • Differentiation: What makes this UNFORGETTABLE? What's the one thing someone will remember?
CRITICAL: Choose a clear conceptual direction and execute it with precision. Bold maximalism and refined minimalism both work. The key is intentionality, not intensity.
Then implement working code that is:
  • Production-grade and functional
  • Visually striking and memorable
  • Cohesive with a clear aesthetic point-of-view
  • Meticulously refined in every detail
确定一个鲜明的美学方向：
  • 定位：该界面解决什么问题？面向哪些用户？
  • 调性：选择一个极端的风格：极致极简、混乱极繁、复古未来主义、有机自然风、奢华精致风、童趣玩具风、杂志编辑风、粗野原始风、装饰艺术几何风、柔和马卡龙风、工业实用风等等。可选的风格非常多，你可以参考这些方向，但最终要设计出符合美学定位的专属风格。
  • 约束：技术要求（框架、性能、无障碍）。
  • 差异化：该界面的哪些特质让人过目不忘？用户会记住的唯一一个亮点是什么？
重要提示：选择清晰的概念方向并精准落地。鲜明的极繁主义和精致的极简主义都可行，核心是设计要有意图，而不是强度。
随后实现的可运行代码需要满足：
  • 生产级、功能完备
  • 视觉冲击力强、记忆点突出
  • 风格统一，有清晰的美学主张
  • 每个细节都经过精心打磨

Frontend Aesthetics Guidelines

前端美学指南

Typography

排版

→ Consult typography reference for OpenType features, web font loading, and the deeper material on scales.
Choose fonts that are beautiful, unique, and interesting. Pair a distinctive display font with a refined body font.
<typography_principles> Always apply these — do not consult a reference, just do them:
  • Use a modular type scale with fluid sizing (clamp) for headings on marketing/content pages. Use fixed 
    rem
    scales for app UIs and dashboards (no major design system uses fluid type in product UI).
  • Use fewer sizes with more contrast. A 5-step scale with at least a 1.25 ratio between steps creates clearer hierarchy than 8 sizes that are 1.1× apart.
  • Line-height scales inversely with line length. Narrow columns want tighter leading, wide columns want more. For light text on dark backgrounds, ADD 0.05-0.1 to your normal line-height — light type reads as lighter weight and needs more breathing room.
  • Cap line length at ~65-75ch. Body text wider than that is fatiguing. </typography_principles>
<font_selection_procedure> DO THIS BEFORE TYPING ANY FONT NAME.
The model's natural failure mode is "I was told not to use Inter, so I will pick my next favorite font, which becomes the new monoculture." Avoid this by performing the following procedure on every project, in order:
Step 1. Read the brief once. Write down 3 concrete words for the brand voice (e.g., "warm and mechanical and opinionated", "calm and clinical and careful", "fast and dense and unimpressed", "handmade and a little weird"). NOT "modern" or "elegant" — those are dead categories.
Step 2. List the 3 fonts you would normally reach for given those words. Write them down. They are most likely from this list:
<reflex_fonts_to_reject> Fraunces Newsreader Lora Crimson Crimson Pro Crimson Text Playfair Display Cormorant Cormorant Garamond Syne IBM Plex Mono IBM Plex Sans IBM Plex Serif Space Mono Space Grotesk Inter DM Sans DM Serif Display DM Serif Text Outfit Plus Jakarta Sans Instrument Sans Instrument Serif </reflex_fonts_to_reject>
Reject every font that appears in the reflex_fonts_to_reject list. They are your training-data defaults and they create monoculture across projects. Syne in particular is the most overused "distinctive" display font and is an instant AI design tell. Never use it.
Step 3. Browse a font catalog with the 3 brand words in mind. Sources: Google Fonts, Pangram Pangram, Future Fonts, Adobe Fonts, ABC Dinamo, Klim Type Foundry, Velvetyne. Look for something that fits the brand as a physical object — a museum exhibit caption, a hand-painted shop sign, a 1970s mainframe terminal manual, a fabric label on the inside of a coat, a children's book printed on cheap newsprint. Reject the first thing that "looks designy" — that's the trained reflex too. Keep looking.
Step 4. Cross-check the result. The right font for an "elegant" brief is NOT necessarily a serif. The right font for a "technical" brief is NOT necessarily a sans-serif. The right font for a "warm" brief is NOT Fraunces. If your final pick lines up with your reflex pattern, go back to Step 3. </font_selection_procedure>
<typography_rules> DO use a modular type scale with fluid sizing (clamp) on headings. DO vary font weights and sizes to create clear visual hierarchy. DO vary your font choices across projects. If you used a serif display font on the last project, look for a sans, monospace, or display face on this one.
DO NOT use overused fonts like Inter, Roboto, Arial, Open Sans, or system defaults — but also do not simply switch to your second-favorite. Every font in the reflex_fonts_to_reject list above is banned. Look further. DO NOT use Syne. Ever. It is an instant AI design tell. DO NOT use monospace typography as lazy shorthand for "technical/developer" vibes. DO NOT put large icons with rounded corners above every heading. They rarely add value and make sites look templated. DO NOT use only one font family for the entire page. Pair a distinctive display font with a refined body font. DO NOT use a flat type hierarchy where sizes are too close together. Aim for at least a 1.25 ratio between steps. DO NOT set long body passages in uppercase. Reserve all-caps for short labels and headings. </typography_rules>
→ 参考「排版参考」了解OpenType特性、Web字体加载以及字号体系的深度内容。
选择美观、独特、有辨识度的字体，将有特色的展示字体和精致的正文字体搭配使用。
<typography_principles> 请始终遵循以下规则，无需查阅参考，直接执行：
  • 营销/内容页面的标题使用带
    clamp
    流式尺寸的模块化字号体系，应用UI和仪表盘使用固定
    rem
    字号体系（没有主流设计系统会在产品UI中使用流式字号）。
  • 使用更少的字号、更大的对比度。步长比例至少1.25的5阶字号体系，比步长1.1倍的8阶字号体系层级更清晰。
  • 行高和行宽成反比：窄列使用更小的行高，宽列使用更大的行高。深色背景上的浅色文字，需要在常规行高基础上增加0.05-0.1——浅色文字视觉上更轻，需要更多的留白空间。
  • 行宽上限控制在~65-75ch，超过这个宽度的正文会增加阅读疲劳。 </typography_principles>
<font_selection_procedure> 在输入任何字体名称前请先执行以下流程：
模型的固有缺陷是「既然不让用Inter，我就选我第二喜欢的字体，最后还是会造成新的同质化」。请在每个项目中按顺序执行以下流程规避该问题：
步骤1：通读需求说明，写下3个描述品牌调性的具象词汇（例如「温暖、机械、有主见」、「冷静、严谨、细致」、「高效、密集、克制」、「手工、有点怪」），不要用「现代」、「优雅」这类空泛的词汇。
步骤2：列出看到这些词汇后你第一反应会使用的3个字体，这些字体大概率来自以下列表：
<reflex_fonts_to_reject> Fraunces Newsreader Lora Crimson Crimson Pro Crimson Text Playfair Display Cormorant Cormorant Garamond Syne IBM Plex Mono IBM Plex Sans IBM Plex Serif Space Mono Space Grotesk Inter DM Sans DM Serif Display DM Serif Text Outfit Plus Jakarta Sans Instrument Sans Instrument Serif </reflex_fonts_to_reject>
拒绝所有出现在上述列表中的字体，它们是训练数据带来的默认选择，会导致不同项目的设计同质化。尤其是Syne，它是目前被滥用最多的「有特色」展示字体，是AI设计的典型标志，绝对不要使用。
步骤3：结合你写下的3个品牌调性词汇浏览字体库，可选来源：Google Fonts、Pangram Pangram、Future Fonts、Adobe Fonts、ABC Dinamo、Klim Type Foundry、Velvetyne。寻找和品牌「实体质感」匹配的字体——比如博物馆展览说明、手绘店铺招牌、1970年代大型机终端手册、大衣内侧的面料标签、印在廉价新闻纸上的儿童读物。不要选第一个看起来「很有设计感」的字体，那也是训练出来的条件反射，继续往下找。
步骤4：交叉验证结果。「优雅」需求对应的字体不一定是衬线字体，「技术感」需求对应的字体不一定是无衬线字体，「温暖」需求对应的字体绝对不是Fraunces。如果你最终选的字体符合你的惯性选择，回到步骤3重新挑选。 </font_selection_procedure>
<typography_rules> ✅ 标题使用带
clamp
流式尺寸的模块化字号体系 ✅ 调整字体字重和尺寸构建清晰的视觉层级 ✅ 不同项目使用不同的字体搭配，如果上一个项目用了衬线展示字体，这个项目可以尝试无衬线、等宽或者其他展示字体
❌ 不要使用Inter、Roboto、Arial、Open Sans这类被滥用的字体，也不要直接换成你的第二偏好字体，所有上面reflex_fonts_to_reject列表里的字体都禁止使用，寻找更多小众选项 ❌ 绝对不要使用Syne，它是AI设计的典型标志 ❌ 不要用等宽字体作为「技术/开发者」风格的偷懒标签 ❌ 不要在每个标题上方放大尺寸圆角图标，几乎没有价值，还会让网站看起来像模板生成的 ❌ 不要整个页面只使用一种字体系列，搭配有特色的展示字体和精致的正文字体 ❌ 不要使用层级扁平的字号体系，步长比例至少要达到1.25 ❌ 不要把长段正文设置为全大写，全大写仅用于短标签和标题 </typography_rules>

Color & Theme

颜色与主题

→ Consult color reference for the deeper material on contrast, accessibility, and palette construction.
Commit to a cohesive palette. Dominant colors with sharp accents outperform timid, evenly-distributed palettes.
<color_principles> Always apply these — do not consult a reference, just do them:
  • Use OKLCH, not HSL. OKLCH is perceptually uniform: equal steps in lightness look equal, which HSL does not deliver. As you move toward white or black, REDUCE chroma — high chroma at extreme lightness looks garish. A light blue at 85% lightness wants ~0.08 chroma, not the 0.15 of your base color.
  • Tint your neutrals toward your brand hue. Even a chroma of 0.005-0.01 is perceptible and creates subconscious cohesion between brand color and UI surfaces. The hue you tint toward should come from THIS brand, not from a "warm = friendly" or "cool = tech" formula. Pick the brand's actual hue first, then tint everything toward it.
  • The 60-30-10 rule is about visual weight, not pixel count. 60% neutral / surface, 30% secondary text and borders, 10% accent. Accents work BECAUSE they're rare. Overuse kills their power. </color_principles>
<theme_selection> Theme (light vs dark) should be DERIVED from audience and viewing context, not picked from a default. Read the brief and ask: when is this product used, by whom, in what physical setting?
  • A perp DEX consumed during fast trading sessions → dark
  • A hospital portal consumed by anxious patients on phones late at night → light
  • A children's reading app → light
  • A vintage motorcycle forum where users sit in their garage at 9pm → dark
  • An observability dashboard for SREs in a dark office → dark
  • A wedding planning checklist for couples on a Sunday morning → light
  • A music player app for headphone listening at night → dark
  • A food magazine homepage browsed during a coffee break → light
Do not default everything to light "to play it safe." Do not default everything to dark "to look cool." Both defaults are the lazy reflex. The correct theme is the one the actual user wants in their actual context. </theme_selection>
<color_rules> DO use modern CSS color functions (oklch, color-mix, light-dark) for perceptually uniform, maintainable palettes. DO tint your neutrals toward your brand hue. Even a subtle hint creates subconscious cohesion.
DO NOT use gray text on colored backgrounds; it looks washed out. Use a shade of the background color instead. DO NOT use pure black (#000) or pure white (#fff). Always tint; pure black/white never appears in nature. DO NOT use the AI color palette: cyan-on-dark, purple-to-blue gradients, neon accents on dark backgrounds. DO NOT use gradient text for impact — see <absolute_bans> below for the strict definition. Solid colors only for text. DO NOT default to dark mode with glowing accents. It looks "cool" without requiring actual design decisions. DO NOT default to light mode "to be safe" either. The point is to choose, not to retreat to a safe option. </color_rules>
→ 参考「颜色参考」了解对比度、无障碍、调色板构建的深度内容。
确定统一的调色板，主色+高亮点缀的组合比胆小、均匀分布的调色板效果更好。
<color_principles> 请始终遵循以下规则，无需查阅参考，直接执行：
  • 使用OKLCH而非HSL，OKLCH是感知统一的颜色模型：亮度的等量变化视觉上也是对等的，HSL做不到这一点。当颜色接近白色或黑色时，降低饱和度——极高亮度下的高饱和度会显得很刺眼。亮度85%的浅蓝色饱和度应该在~0.08，而不是你基础色的0.15。
  • 把中性色向你的品牌色相偏移，哪怕只有0.005-0.01的饱和度也能被感知到，会在潜意识里让品牌色和UI界面更统一。偏移的色相必须来自本品牌，不要用「暖色调=友好」、「冷色调=科技感」的固定公式，先确定品牌实际的色相，再把所有颜色向它偏移。
  • 60-30-10规则是关于视觉权重的，不是像素占比：60%中性/背景色、30%次要文本和边框、10%强调色。强调色的价值就在于稀有，滥用会失去效果。 </color_principles>
<theme_selection> 主题（浅色/深色）应该由受众和使用场景推导而来，而不是用默认值。阅读需求并思考：这个产品什么时候被谁在什么物理环境下使用？
  • 快速交易场景下的去中心化交易所 → 深色
  • 焦虑的患者深夜在手机上使用的医院门户 → 浅色
  • 儿童阅读应用 → 浅色
  • 用户晚上9点在车库使用的复古摩托车论坛 → 深色
  • SRE在暗室里使用的可观测性仪表盘 → 深色
  • 情侣周日上午使用的婚礼规划清单 → 浅色
  • 夜间戴耳机使用的音乐播放器应用 → 深色
  • 咖啡休息时间浏览的美食杂志主页 → 浅色
不要默认都用浅色「求稳」，也不要默认都用深色「看起来酷」，这两种默认选择都是偷懒的条件反射。正确的主题是真实用户在真实场景下想要的主题。 </theme_selection>
<color_rules> ✅ 使用现代CSS颜色函数（oklch、color-mix、light-dark）构建感知统一、可维护的调色板 ✅ 把中性色向你的品牌色相偏移，哪怕是很细微的调整也能带来潜意识的统一感
❌ 不要在彩色背景上用灰色文本，会看起来很褪色，改用背景色的同色系深浅色 ❌ 不要用纯黑（#000）或者纯白（#fff），一定要加色调偏移，自然界里不存在纯黑/纯白 ❌ 不要用AI常见调色板：深色背景配青色、紫蓝渐变、深色背景配霓虹点缀 ❌ 不要用渐变文字做强调，具体禁止规则见下方<absolute_bans>，文本只能用纯色 ❌ 不要默认用带发光点缀的深色模式，看起来「酷」但不需要任何实际设计决策 ❌ 也不要默认用浅色模式「求稳」，核心是主动选择，而不是退回到安全选项 </color_rules>

Layout & Space

布局与空间

→ Consult spatial reference for the deeper material on grids, container queries, and optical adjustments.
Create visual rhythm through varied spacing, not the same padding everywhere. Embrace asymmetry and unexpected compositions. Break the grid intentionally for emphasis.
<spatial_principles> Always apply these — do not consult a reference, just do them:
  • Use a 4pt spacing scale with semantic token names (
    --space-sm
    , 
    --space-md
    ), not pixel-named (
    --spacing-8
    ). Scale: 4, 8, 12, 16, 24, 32, 48, 64, 96. 8pt is too coarse — you'll often want 12px between two values.
  • Use 
    gap
    instead of margins for sibling spacing. It eliminates margin collapse and the cleanup hacks that come with it.
  • Vary spacing for hierarchy. A heading with extra space above it reads as more important — make use of that. Don't apply the same padding everywhere.
  • Self-adjusting grid pattern: 
    grid-template-columns: repeat(auto-fit, minmax(280px, 1fr))
    is the breakpoint-free responsive grid for card-style content.
  • Container queries are for components, viewport queries are for page layout. A card in a sidebar should adapt to the sidebar's width, not the viewport's. </spatial_principles>
<spatial_rules> DO create visual rhythm through varied spacing: tight groupings, generous separations. DO use fluid spacing with clamp() that breathes on larger screens. DO use asymmetry and unexpected compositions; break the grid intentionally for emphasis.
DO NOT wrap everything in cards. Not everything needs a container. DO NOT nest cards inside cards. Visual noise; flatten the hierarchy. DO NOT use identical card grids (same-sized cards with icon + heading + text, repeated endlessly). DO NOT use the hero metric layout template (big number, small label, supporting stats, gradient accent). DO NOT center everything. Left-aligned text with asymmetric layouts feels more designed. DO NOT use the same spacing everywhere. Without rhythm, layouts feel monotonous. DO NOT let body text wrap beyond ~80 characters per line. Add a max-width like 65–75ch so the eye can track easily. </spatial_rules>
→ 参考「空间设计参考」了解网格、容器查询、视觉调整的深度内容。
通过变化的间距而非统一的内边距创造视觉节奏，主动使用不对称和意料之外的构图，为了强调可以有意打破网格。
<spatial_principles> 请始终遵循以下规则，无需查阅参考，直接执行：
  • 使用带语义化命名的4pt间距体系（
    --space-sm
    、
    --space-md
    ），不要用像素命名（
    --spacing-8
    ）。间距值：4、8、12、16、24、32、48、64、96。8pt的体系太粗，你经常会需要两个值之间的12px。
  • 同级元素间距用
    gap
    而非margin，可以避免margin塌陷和后续的修复hack。
  • 用变化的间距体现层级，上方留白更多的标题会被感知为更重要，充分利用这一点，不要所有地方都用相同的内边距。
  • 自适应网格模式：
    grid-template-columns: repeat(auto-fit, minmax(280px, 1fr))
    是卡片类内容无断点响应式网格的最优解。
  • 容器查询（container queries）用于组件，视口查询（viewport queries）用于页面布局。侧边栏里的卡片应该适配侧边栏的宽度，而不是视口宽度。 </spatial_principles>
<spatial_rules> ✅ 通过变化的间距创造视觉节奏：紧凑分组、宽松分隔 ✅ 使用带
clamp
的流式间距，在大屏上有更多呼吸空间 ✅ 使用不对称和意料之外的构图，为了强调可以有意打破网格
❌ 不要把所有内容都包在卡片里，不是所有内容都需要容器 ❌ 不要嵌套卡片，会造成视觉噪音，拉平层级 ❌ 不要用千篇一律的卡片网格（相同尺寸的卡片，重复的图标+标题+文本结构） ❌ 不要用 hero 数据布局模板（大数字、小标签、辅助统计数据、渐变点缀） ❌ 不要所有内容都居中，左对齐文本加不对称布局的设计感更强 ❌ 不要所有地方都用相同的间距，没有节奏的布局会很单调 ❌ 不要让正文每行超过~80个字符，设置65-75ch的最大宽度方便视线追踪 </spatial_rules>

Visual Details

视觉细节

<absolute_bans> These CSS patterns are NEVER acceptable. They are the most recognizable AI design tells. Match-and-refuse: if you find yourself about to write any of these, stop and rewrite the element with a different structure entirely.
BAN 1: Side-stripe borders on cards/list items/callouts/alerts
  • PATTERN: 
    border-left:
    or 
    border-right:
    with width greater than 1px
  • INCLUDES: hard-coded colors AND CSS variables
  • FORBIDDEN: 
    border-left: 3px solid red
    , 
    border-left: 4px solid #ff0000
    , 
    border-left: 4px solid var(--color-warning)
    , 
    border-left: 5px solid oklch(...)
    , etc.
  • WHY: this is the single most overused "design touch" in admin, dashboard, and medical UIs. It never looks intentional regardless of color, radius, opacity, or whether the variable name is "primary" or "warning" or "accent."
  • REWRITE: use a different element structure entirely. Do not just swap to box-shadow inset. Reach for full borders, background tints, leading numbers/icons, or no visual indicator at all.
BAN 2: Gradient text
  • PATTERN: 
    background-clip: text
    (or 
    -webkit-background-clip: text
    ) combined with a gradient background
  • FORBIDDEN: any combination that makes text fill come from a 
    linear-gradient
    , 
    radial-gradient
    , or 
    conic-gradient
  • WHY: gradient text is decorative rather than meaningful and is one of the top three AI design tells
  • REWRITE: use a single solid color for text. If you want emphasis, use weight or size, not gradient fill. </absolute_bans>
DO: Use intentional, purposeful decorative elements that reinforce brand. DO NOT: Use border-left or border-right greater than 1px as a colored accent stripe on cards, list items, callouts, or alerts. See <absolute_bans> above for the strict CSS pattern. DO NOT: Use glassmorphism everywhere (blur effects, glass cards, glow borders used decoratively rather than purposefully). DO NOT: Use sparklines as decoration. Tiny charts that look sophisticated but convey nothing meaningful. DO NOT: Use rounded rectangles with generic drop shadows. Safe, forgettable, could be any AI output. DO NOT: Use modals unless there's truly no better alternative. Modals are lazy.
<absolute_bans> 这些CSS模式永远不允许使用，它们是最容易被识别的AI设计标志。匹配即拒绝：如果你打算写以下任何代码，停下来，用完全不同的结构重写该元素。
禁令1：卡片/列表项/提示框/告警的侧边条纹边框
  • 模式：
    border-left:
    或 
    border-right:
    宽度大于1px
  • 包含：硬编码颜色 和 CSS变量
  • 禁止示例：
    border-left: 3px solid red
    、
    border-left: 4px solid #ff0000
    、
    border-left: 4px solid var(--color-warning)
    、
    border-left: 5px solid oklch(...)
    等
  • 原因：这是管理后台、仪表盘、医疗UI里被滥用最多的「设计点缀」，不管颜色、圆角、透明度是什么，不管变量名是「primary」、「warning」还是「accent」，看起来都没有设计意图
  • 重写方案：用完全不同的元素结构，不要只是换成内阴影，可以用全边框、背景色偏移、前置编号/图标，或者完全不加视觉标识
禁令2：渐变文字
  • 模式：
    background-clip: text
    （或 
    -webkit-background-clip: text
    ）加渐变背景的组合
  • 禁止：任何使用
    linear-gradient
    、
    radial-gradient
    、
    conic-gradient
    作为文本填充的组合
  • 原因：渐变文字只有装饰性没有实际意义，是排名前三的AI设计标志
  • 重写方案：文本用单一纯色，如果需要强调，用字重或者字号，不要用渐变填充 </absolute_bans>
✅ 使用有意图、有目的的装饰元素强化品牌调性 ❌ 不要在卡片、列表项、提示框、告警上用大于1px的
border-left
或
border-right
作为彩色点缀条纹，具体规则见上方<absolute_bans> ❌ 不要到处使用玻璃态效果（模糊效果、玻璃卡片、无目的的装饰性发光边框） ❌ 不要用迷你折线图做装饰，小图表看起来很精致但没有任何实际信息价值 ❌ 不要用带通用阴影的圆角矩形，安全、无记忆点，任何AI都能生成 ❌ 除非没有更好的替代方案，不要使用模态框，模态框是偷懒的选择

Motion

动效

→ Consult motion reference for timing, easing, and reduced motion.
Focus on high-impact moments: one well-orchestrated page load with staggered reveals creates more delight than scattered micro-interactions.
DO: Use motion to convey state changes: entrances, exits, feedback DO: Use exponential easing (ease-out-quart/quint/expo) for natural deceleration DO: For height animations, use grid-template-rows transitions instead of animating height directly DON'T: Animate layout properties (width, height, padding, margin). Use transform and opacity only DON'T: Use bounce or elastic easing. They feel dated and tacky; real objects decelerate smoothly
→ 参考「动效设计参考」了解时长、缓动、减少动效的相关内容。
聚焦高影响的动效时刻：一个精心编排的带 staggered 入场效果的页面加载，比零散的微交互能带来更多愉悦感。
✅ 用动效传递状态变化：入场、退场、反馈 ✅ 使用指数缓动（ease-out-quart/quint/expo）实现自然的减速效果 ✅ 高度动画用
grid-template-rows
过渡，不要直接动画height属性 ❌ 不要动画布局属性（width、height、padding、margin），仅使用transform和opacity ❌ 不要使用弹跳或弹性缓动，看起来过时又廉价，真实物体会平滑减速

Interaction

交互

→ Consult interaction reference for forms, focus, and loading patterns.
Make interactions feel fast. Use optimistic UI: update immediately, sync later.
DO: Use progressive disclosure. Start simple, reveal sophistication through interaction (basic options first, advanced behind expandable sections; hover states that reveal secondary actions) DO: Design empty states that teach the interface, not just say "nothing here" DO: Make every interactive surface feel intentional and responsive DON'T: Repeat the same information (redundant headers, intros that restate the heading) DON'T: Make every button primary. Use ghost buttons, text links, secondary styles; hierarchy matters
→ 参考「交互设计参考」了解表单、焦点、加载模式的相关内容。
让交互感受更快，使用乐观UI：立即更新界面，后台同步数据。
✅ 使用渐进式披露，从简单开始，通过交互展示复杂功能：先展示基础选项，高级选项放在折叠区域里；hover状态展示次要操作 ✅ 设计有引导性的空状态，不要只显示「暂无内容」 ✅ 让每个可交互区域都有设计意图、响应及时 ❌ 不要重复相同信息（冗余的头部、重复标题的介绍内容） ❌ 不要把所有按钮都设为主按钮，使用幽灵按钮、文字链接、次要样式，层级很重要

Responsive

响应式

→ Consult responsive reference for mobile-first, fluid design, and container queries.
DO: Use container queries (@container) for component-level responsiveness DO: Adapt the interface for different contexts, not just shrink it DON'T: Hide critical functionality on mobile. Adapt the interface, don't amputate it
→ 参考「响应式设计参考」了解移动优先、流式设计、容器查询的相关内容。
✅ 使用容器查询（@container）实现组件级响应式 ✅ 为不同场景适配界面，而不只是缩小界面 ❌ 不要在移动端隐藏核心功能，适配界面，不要砍掉功能

UX Writing

UX文案

→ Consult ux-writing reference for labels, errors, and empty states.
DO: Make every word earn its place DON'T: Repeat information users can already see
→ 参考「UX写作参考」了解标签、错误提示、空状态的相关内容。
✅ 每个文案都要有存在的价值 ❌ 不要重复用户已经能看到的信息

The AI Slop Test

AI劣质内容测试

Critical quality check: If you showed this interface to someone and said "AI made this," would they believe you immediately? If yes, that's the problem.
A distinctive interface should make someone ask "how was this made?" not "which AI made this?"
Review the DON'T guidelines above. They are the fingerprints of AI-generated work from 2024-2025.
核心质量检查：如果你把这个界面给别人看说「这是AI做的」，对方会不会立刻相信？如果会，那就有问题。
有特色的界面应该让用户问「这是怎么做出来的？」，而不是「这是哪个AI做的？」
对照上面的禁止规则检查，这些都是2024-2025年AI生成作品的典型特征。

Implementation Principles

实现原则

Match implementation complexity to the aesthetic vision. Maximalist designs need elaborate code with extensive animations and effects. Minimalist or refined designs need restraint, precision, and careful attention to spacing, typography, and subtle details.
Interpret creatively and make unexpected choices that feel genuinely designed for the context. No design should be the same. Vary between light and dark themes, different fonts, different aesthetics. NEVER converge on common choices across generations.
Remember: the model is capable of extraordinary creative work. Don't hold back. Show what can truly be created when thinking outside the box and committing fully to a distinctive vision.
实现复杂度要和美学愿景匹配。极繁主义设计需要复杂的代码、大量的动画和效果；极简或精致的设计需要克制、精准，对间距、排版、细节的高度关注。
创意性解读需求，做出符合场景的意料之外的选择，没有两个设计应该是一样的。在深浅主题、字体、美学风格上做变化，永远不要收敛到通用选择上。
记住：模型有能力完成极其有创意的工作，不要限制自己。跳出思维定式，完全投入到独特的设计愿景中，展示你真正能创造的价值。

Craft Mode

Craft模式

If this skill is invoked with the argument "craft" (e.g., 
/impeccable craft [feature description]
), follow the craft flow. Pass any additional arguments as the feature description.
如果调用该技能时传入参数
craft
（例如 
/impeccable craft [功能描述]
），遵循「craft流程」，把所有额外参数作为功能描述传入。

Teach Mode

Teach模式

If this skill is invoked with the argument "teach" (e.g., 
/impeccable teach
), skip all design work above and instead run the teach flow below. This is a one-time setup that gathers design context for the project.
如果调用该技能时传入参数
teach
（例如 
/impeccable teach
），跳过上面所有设计工作，直接运行下面的teach流程。这是一次性的初始化设置，用于收集项目的设计上下文。

Step 1: Explore the Codebase

步骤1：探索代码库

Before asking questions, thoroughly scan the project to discover what you can:
  • README and docs: Project purpose, target audience, any stated goals
  • Package.json / config files: Tech stack, dependencies, existing design libraries
  • Existing components: Current design patterns, spacing, typography in use
  • Brand assets: Logos, favicons, color values already defined
  • Design tokens / CSS variables: Existing color palettes, font stacks, spacing scales
  • Any style guides or brand documentation
Note what you've learned and what remains unclear.
在提问前，全面扫描项目，尽可能收集信息：
  • README和文档：项目定位、目标受众、已说明的目标
  • Package.json/配置文件：技术栈、依赖、现有设计库
  • 现有组件：当前的设计模式、间距、排版使用习惯
  • 品牌资产：Logo、favicon、已定义的颜色值
  • 设计令牌/CSS变量：现有调色板、字体栈、间距体系
  • 任何风格指南或品牌文档
记录你已经了解的信息和仍然不明确的信息。

Step 2: Ask UX-Focused Questions

步骤2：提问UX相关问题

ask the user directly to clarify what you cannot infer. Focus only on what you couldn't infer from the codebase:
直接向用户询问你无法推断的信息，只关注你在代码库探索中无法得到的内容：

Users & Purpose

用户与定位

  • Who uses this? What's their context when using it?
  • What job are they trying to get done?
  • What emotions should the interface evoke? (confidence, delight, calm, urgency, etc.)
  • 使用者是谁？他们的使用场景是什么？
  • 他们需要用产品完成什么任务？
  • 界面应该唤起什么情绪？（自信、愉悦、平静、紧迫感等）

Brand & Personality

品牌与个性

  • How would you describe the brand personality in 3 words?
  • Any reference sites or apps that capture the right feel? What specifically about them?
  • What should this explicitly NOT look like? Any anti-references?
  • 你会用哪3个词描述品牌个性？
  • 有没有符合预期风格的参考网站或应用？具体是哪些点符合？
  • 应该明确避免什么样的风格？有没有反面参考？

Aesthetic Preferences

美学偏好

  • Any strong preferences for visual direction? (minimal, bold, elegant, playful, technical, organic, etc.)
  • Light mode, dark mode, or both?
  • Any colors that must be used or avoided?
  • 有没有强烈的视觉方向偏好？（极简、 bold、优雅、童趣、技术感、有机等）
  • 浅色模式、深色模式还是都要？
  • 有没有必须使用或者必须避免的颜色？

Accessibility & Inclusion

无障碍与包容性

  • Specific accessibility requirements? (WCAG level, known user needs)
  • Considerations for reduced motion, color blindness, or other accommodations?
Skip questions where the answer is already clear from the codebase exploration.
  • 有没有特定的无障碍要求？（WCAG等级、已知的用户需求）
  • 有没有需要考虑的减少动效、色盲适配或其他适配需求？
跳过代码库探索已经能得到答案的问题。

Step 3: Write Design Context

步骤3：编写设计上下文

Synthesize your findings and the user's answers into a 
## Design Context
section:
markdown
undefined
把你的发现和用户的回答整合为「## 设计上下文」章节：
markdown
undefined

Design Context

设计上下文

Users

用户

[Who they are, their context, the job to be done]
[用户是谁、使用场景、要完成的任务]

Brand Personality

品牌个性

[Voice, tone, 3-word personality, emotional goals]
[调性、风格、3个词的个性描述、情绪目标]

Aesthetic Direction

美学方向

[Visual tone, references, anti-references, theme]
[视觉调性、参考、反面参考、主题]

Design Principles

设计原则

[3-5 principles derived from the conversation that should guide all design decisions]

Write this section to `.impeccable.md` in the project root. If the file already exists, update the Design Context section in place.

Then ask the user directly to clarify what you cannot infer. whether they'd also like the Design Context appended to .github/copilot-instructions.md. If yes, append or update the section there as well.

Confirm completion and summarize the key design principles that will now guide all future work.
[从对话中提炼的3-5条指导所有设计决策的原则]

把该章节写入项目根目录的`.impeccable.md`文件，如果文件已经存在，原地更新设计上下文章节。

随后询问用户是否需要把设计上下文追加到`.github/copilot-instructions.md`里，如果是，也在该文件里追加或更新对应章节。

确认完成，总结未来所有工作会遵循的核心设计原则。