Frontend Design Principles 是一套面向前端界面构建与评审的设计原则技能，目标是让界面带有工艺感与明确意图，而不是落入通用模板化输出。
用途与适用范围 该技能用于构建或评审前端 UI，包括仪表盘、管理后台、落地页、营销站点和 Web 应用。它会在加载后根据上下文路由到更具体的指南：app.md 面向仪表盘、管理与设置面板、内部工具、SaaS 产品、数据密集型界面（表格、表单、列表）以及用户反复使用的界面；marketing.md 面向落地页、营销站点、公告、创意产物等第一印象最重要的场景。若无法判断，技能建议询问用户。混合型项目需要同时使用两者：SaaS 的营销站点用 marketing.md，其产品仪表盘用 app.md。
核心理念 技能指出，模型默认倾向于产出通用结果，因为训练模式中仪表盘和落地页的套路很强。流程本身不等于工艺，需要主动察觉并纠正默认倾向。默认往往伪装成“基础设施”——那些看起来只需能用、无需设计的部分。技能强调：没有结构性决策，一切都是设计。排版不是容器，它本身就是设计；导航不是产品周边，它本身就是产品；数据不是展示，而是意义；令牌命名也是设计决策，例如 --ink、--parchment 比 --gray-700、--surface-2 更能体现产品世界。
生成前的必需步骤 在写代码前必须完成：第一，回答意图问题——具体是谁（不是“用户”，而是真实的人，他在哪、在想什么、前后五分钟在做什么）、必须完成什么（动词：批改提交、找到故障部署、批准付款）、应该是什么感觉（有意义的词，如像笔记本一样温暖、像终端一样冷峻、像交易大厅一样密集）。第二，产出四项必需输出：领域（产品世界中的概念、隐喻、词汇，至少 5 个）、色彩世界（该领域自然存在的颜色，至少 5 个）、签名（一个只属于该产品的视觉、结构或交互元素）、需拒绝的默认（该界面类型 3 个显而易见的视觉与结构选择）。第三，提出方向并确认，引用领域概念、色彩、签名以及每个被拒绝默认的替代方案，并等待确认后再生成代码。测试方法是：从提案中移除产品名，别人还能识别它是做什么的吗？
展示前的必需步骤 首次输出很可能通用，工作在于在用户指出前自己发现。技能建议问“如果他们说这缺乏工艺，会指什么”，并运行四项检查：替换测试（换掉字体或布局，有人会注意到吗？换掉无所谓的地方就是默认之处）、眯眼测试（模糊视线后层级是否仍可读，是否有刺眼元素）、签名测试（指出签名出现的具体组件，“整体感觉”不算）、令牌测试（朗读 CSS 变量，它们属于这个产品还是任何项目）。
原则 每个选择都必须是选择：布局、色温、字体、间距尺度、层级，都能说出为什么；“常见/干净/能用”是默认而非选择。相同即失败：如果另一个 AI 在相似提示下产出基本相同的结果，就是失败。意图必须系统化：说“温暖”就不能出现冷色，表面、文字、边框、强调色、语义色、字体都要一致。无限表达：指标可以是主数字、迷你趋势图、仪表、增量、趋势徽章或新形式，不要每次都输出同样的侧边栏宽度加卡片网格加左图标大数字。
工艺基础 无论方向如何，质量底线包括：微妙分层——表面差异极小但可区分，是轻声细语般的层级变化而非戏剧性跳跃（可参考 Vercel、Supabase、Linear）；边框要轻到不刻意寻找就消失，如果边框是第一眼注意到的，就太强了。色彩有出处——先花时间在产品物理世界中（材料、光线、物体），让颜色感觉来自某处，而非被贴上去；灰色构建结构，色彩承载意义；一个有意的强调色胜过五个随意的强调色。
通用反模式 无论上下文都算错误：夸张的投影（如 box-shadow: 0 25px 50px … 显得廉价）、随意的不对称内边距、厚重的装饰性边框（2px 以上）、多个强调色、混用深度策略（边框或阴影，不要随机混用）、间距不一致（没有系统的最明显标志）。
沟通方式 保持隐形：不要宣布模式或叙述过程（如“让我探索领域……”“正在运行检查……”），直接进入工作，用理由陈述建议。
深入资料 references/principles.md 涵盖间距、深度、排版、色彩实现、深色模式（含具体数值和 CSS）；app.md 面向仪表盘、管理面板、SaaS 产品；marketing.md 面向落地页、营销站点、创意产物。
限制与暂未提供 该技能未提供具体安装命令、收费方式、平台支持或效果数据，这些信息暂未提供。