Back to Details

impeccable

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese
<post-update-cleanup> BEFORE doing any design work, run this one-time maintenance step. Tell the user:
Impeccable was updated. A few skills were renamed or merged in this version (e.g. 
/arrange
is now 
/layout
, 
/normalize
was folded into 
/polish
). I'll clean up the old skill files so they don't clutter your project. This only runs once after an update.
Then run:
bash
node .agents/skills/impeccable/scripts/cleanup-deprecated.mjs
If the script removed files, briefly confirm what was cleaned up. If it found nothing, skip any output and move on.
After running the script, delete this entire section (from 
<post-update-cleanup>
through 
</post-update-cleanup>
inclusive) from THIS file so it does not run again until the next update. Save the file. </post-update-cleanup>
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.
<post-update-cleanup> 在进行任何设计工作之前，请运行这个一次性维护步骤。告知用户：
Impeccable已更新。此版本中部分技能已重命名或合并（例如
/arrange
现已更名为
/layout
，
/normalize
已并入
/polish
）。我将清理旧的技能文件，避免它们占用项目空间。此操作仅在更新后运行一次。
然后运行：
bash
node .agents/skills/impeccable/scripts/cleanup-deprecated.mjs
如果脚本删除了文件，请简要告知用户清理了哪些内容。如果未找到任何可清理的内容，则无需输出，直接继续。
运行脚本后，请从此文件中删除整个此部分（包括
<post-update-cleanup>
和
</post-update-cleanup>
标签及其间的所有内容），以便下次更新前不会再次运行此步骤。保存文件。 </post-update-cleanup>
此技能可指导创建特色鲜明的生产级前端界面，避免千篇一律的“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.
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 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级尺寸层级，比8级仅1.1倍比例的层级更清晰。
  • 行高与行长成反比。窄列需要更紧凑的行高，宽列需要更大的行高。在深色背景上使用浅色文本时，需将常规行高增加0.05-0.1——浅色文本视觉上更轻，需要更多呼吸空间。
  • 行宽上限约为65-75ch。超过此宽度的正文会让用户阅读疲劳。 </typography_principles>
<font_selection_procedure> 在输入任何字体名称前，请执行以下步骤。
模型的常见失误模式是：“我被告知不要使用Inter，所以我会选择第二喜欢的字体，这会形成新的单一化字体趋势。”为避免这种情况，请在每个项目中按顺序执行以下步骤：
步骤1. 通读需求文档，写下3个能体现品牌调性的具体词汇（例如：“温暖、机械、有态度”、“平静、严谨、细致”、“快速、密集、冷漠”、“手工感、略带怪异”）。切勿使用“现代”或“优雅”这类空泛的词汇——这些类别已过时。
步骤2. 列出根据这3个词汇你通常会首选的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
列表中的字体。这些是训练数据中的默认选择，会导致项目风格单一化。
步骤3. 结合3个品牌词汇，浏览字体库。可选来源：Google Fonts、Pangram Pangram、Future Fonts、Adobe Fonts、ABC Dinamo、Klim Type Foundry、Velvetyne。寻找能让品牌呈现出实体质感的字体——比如博物馆展品说明、手绘店铺招牌、70年代大型机终端手册、外套内侧的布标、廉价新闻纸印刷的儿童读物。拒绝第一眼看起来“有设计感”的字体——这也是训练出的惯性反应，请继续寻找。
步骤4. 交叉验证结果。适合“优雅”需求的字体不一定是衬线体；适合“技术感”需求的字体不一定是无衬线体；适合“温暖”需求的字体绝对不是Fraunces。如果你的最终选择符合惯性偏好，请回到步骤3重新选择。 </font_selection_procedure>
<typography_rules> 请遵循以下规则：
  • 标题使用模块化排版比例和自适应尺寸（clamp函数）
  • 通过改变字重和尺寸创建清晰的视觉层级
  • 不同项目使用不同的字体组合。如果上一个项目使用了衬线标题字体，当前项目请尝试无衬线、等宽或其他风格的标题字体。
请勿使用以下做法：
  • 避免使用过度流行的字体，如Inter、Roboto、Arial、Open Sans或系统默认字体——也不要仅仅切换到你第二喜欢的字体。
    reflex_fonts_to_reject
    列表中的所有字体均被禁止，请扩大选择范围。
  • 不要将等宽字体作为“技术/开发者”风格的偷懒表达。
  • 不要在每个标题上方都添加带圆角的大图标。它们几乎没有实际价值，会让网站看起来像模板化产物。
  • 不要在整个页面中只使用一种字体。请将特色标题字体与精致正文字体搭配使用。
  • 不要使用扁平化的排版层级，即字体尺寸过于接近。不同层级之间的比例至少要达到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> 主题（亮色/暗色）应根据受众和使用场景确定，而非默认选择。阅读需求文档并思考：该产品何时、由谁、在什么物理环境中使用？
  • 用于高频交易的去中心化交易所 → 暗色主题
  • 供焦虑患者在深夜使用手机访问的医院门户 → 亮色主题
  • 儿童阅读应用 → 亮色主题
  • 用户在车库深夜浏览的复古摩托车论坛 → 暗色主题
  • 供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
    属性而非外边距设置同级元素间距。这可以消除外边距折叠问题及相关的修复技巧。
  • 通过调整间距建立层级。标题上方增加额外间距会让它看起来更重要——请充分利用这一点。不要给所有元素设置相同的内边距。
  • 自适应网格模式：
    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的左侧或右侧彩色强调条纹。请查看上方<absolute_bans>中的严格CSS模式定义。
  • 不要过度使用毛玻璃效果（模糊效果、玻璃卡片、发光边框），除非有明确的用途，而非仅作为装饰。
  • 不要将迷你折线图作为装饰。这些小图表看起来很精致，但无法传达任何有意义的信息。
  • 不要使用带通用阴影的圆角矩形。这种设计安全但令人难忘，可能是任何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：立即更新界面，稍后再同步数据。
请遵循：
  • 使用渐进式披露。从简单开始，通过交互逐步展示复杂功能（先显示基础选项，高级选项放在可展开区域内；悬停状态显示次要操作）
  • 设计能引导用户了解界面的空状态，而非仅显示“暂无内容”
  • 让每个可交互区域都显得有明确目的且响应迅速
请勿使用：
  • 不要重复相同的信息（冗余标题、重复标题内容的介绍文本）
  • 不要将所有按钮都设置为主按钮样式。请使用幽灵按钮、文本链接、次要按钮样式；层级结构很重要

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、网站图标、颜色值
  • 设计令牌/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?
  • 对视觉方向有明确偏好吗？（极简、大胆、优雅、趣味、技术感、有机等）
  • 亮色主题、暗色主题，还是两者都需要？
  • 必须使用或避免哪些颜色？

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

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

---

Extract Mode

Extract模式

If this skill is invoked with the argument "extract" (e.g., 
/impeccable extract [target]
), follow the extract flow. Pass any additional arguments as the extraction target.
如果该技能通过参数“extract”调用（例如：
/impeccable extract [目标]
），请遵循extract流程。将所有额外参数作为提取目标传递。