Back to Details

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
选定鲜明的美学方向：
  • 用途：这个界面解决什么问题？面向什么用户？
  • 调性：选择极端化的风格：极致简约、极繁混乱、复古未来、有机自然、奢华精致、 playful/玩具感、编辑/杂志风、粗野主义/原生、装饰艺术/几何、柔和/马卡龙、工业/实用主义等等。可选风格非常丰富，你可以以此为灵感，但要设计出符合选定美学方向的独特方案。
  • 约束：技术要求（框架、性能、可访问性）。
  • 差异化：这个界面的什么特质让人过目不忘？用户能记住的一个核心亮点是什么？
重要提示：选择清晰的概念方向并精准落地。鲜明的极繁主义和精致的极简主义都可行，核心是设计的意图性，而非视觉强度。
随后实现的运行代码需要满足：
  • 生产级质量、功能完备
  • 视觉冲击力强、令人印象深刻
  • 风格统一，具备清晰的美学主张
  • 每个细节都经过精心打磨

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>
拒绝所有出现在
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> 主题（浅色vs深色）应该从受众和使用场景推导得出，而不是选择默认值。阅读需求并思考：这个产品的使用时间、使用人群、物理场景是什么？
  • 快速交易场景下的perp DEX → 深色
  • 焦虑的患者深夜在手机上使用的医院门户 → 浅色
  • 儿童阅读应用 → 浅色
  • 用户晚上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间距比例，搭配语义化token名称（
    --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))
    是卡片类内容无需断点的响应式网格方案。
  • 容器查询适用于组件，视口查询适用于页面布局。侧边栏里的卡片应该适配侧边栏的宽度，而非视口宽度。 </spatial_principles>
<spatial_rules> ✅ 通过变化的间距创建视觉节奏：紧凑的内容分组、宽松的区块分隔。 ✅ 使用clamp()实现流体间距，在大屏上有更舒展的效果。 ✅ 使用不对称和出人意料的构图，为了强调内容可以故意打破网格。
❌ 不要把所有内容都包在卡片里，不是所有内容都需要容器。 ❌ 不要嵌套卡片，会产生视觉噪音，拉平层级。 ❌ 不要使用千篇一律的卡片网格（相同尺寸的卡片，搭配图标+标题+文本，无限重复）。 ❌ 不要使用英雄数据布局模板（大数字、小标签、辅助统计、渐变点缀）。 ❌ 不要把所有内容都居中，左对齐文本搭配不对称布局的设计感更强。 ❌ 不要所有地方都用相同的间距，没有节奏的布局会显得单调。 ❌ 不要让正文每行超过~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
→ 请查阅动效设计参考了解 timing、缓动和减少动效的相关内容。
聚焦高影响力的时刻：一个编排精良的交错展示页面加载效果，比零散的微交互能带来更多愉悦感。
✅ 用动效传递状态变化：进入、退出、反馈 ✅ 使用指数缓动（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、已定义的色值
  • 设计token/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?
  • 对视觉方向有没有强烈偏好？（简约、大胆、优雅、 playful、技术感、有机等）
  • 浅色模式、深色模式还是都要？
  • 有没有必须使用或必须避免的颜色？

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`中，如果是，在该文件中也追加或更新对应章节。

确认流程完成，总结将指导未来所有工作的核心设计原则。