@bovinphang/frontend-craft 2.7.0 → 2.8.0

package/skills/fec-ui-design/SKILL.md

@@ -1,108 +1,108 @@
 ---
 name: fec-ui-design
-description: Use when building, reviewing, or improving frontend UI that needs product-specific design direction, design-system generation, Master/Page overrides, distinctive visual identity, anti-generic interface choices, first-screen hierarchy, UI polish, chart UX, interaction states, responsive behavior, or visual QA. When an external design file is authoritative, implement from that source instead of inventing direction; Chinese triggers include UI 设计, 设计系统, 视觉风格, 不要模板化, 高级感, 界面打磨, 交互状态.
+description: Use when building, reviewing, or improving frontend UI that needs product-specific design direction, design-system generation, Master/Page overrides, distinctive visual identity, anti-generic interface choices, first-screen hierarchy, UI polish, chart UX, interaction states, responsive behavior, or visual QA. Interface polishing, interactive state.
 ---
 
-# UI 设计
+#UI design
 
-适用于需要把前端界面推进到“符合产品语境、可扫描、可信赖、有辨识度，并且细节稳定”的 UI 任务。需要系统化设计建议时，加载 [design-intelligence.md](references/design-intelligence.md)；需要长期沉淀设计系统时，加载 [master-page-overrides.md](references/master-page-overrides.md)；上线前做 UI/UX QA 时，加载 [pre-delivery-checklist.md](references/pre-delivery-checklist.md)。
+Suitable for UI tasks that require advancing the front-end interface to be "in line with the product context, scannable, trustworthy, recognizable, and stable in details". When systematic design suggestions are needed, load [design-intelligence.md](references/design-intelligence.md); when long-term precipitation of the design system is required, load [master-page-overrides.md](references/master-page-overrides.md); when doing UI/UX QA before going online, load [pre-delivery-checklist.md](references/pre-delivery-checklist.md).
 
-可执行设计系统生成器位于 [design-system.mjs](scripts/design-system.mjs)，其原创知识包包括 [product-rules.json](data/product-rules.json)、[style-archetypes.json](data/style-archetypes.json)、[ux-quality-rules.json](data/ux-quality-rules.json) 和 [stack-ui-rules.json](data/stack-ui-rules.json)。
+The executable design system generator is located at [design-system.mjs](scripts/design-system.mjs), and its original knowledge package includes [product-rules.json](data/product-rules.json), [style-archetypes.json](data/style-archetypes.json), [ux-quality-rules.json](data/ux-quality-rules.json) and [stack-ui-rules.json](data/stack-ui-rules.json).
 
 ## Purpose
 
-为页面、组件、仪表盘和工具界面建立设计方向，并完成可落地的视觉与交互 polish。
+Establish design direction for pages, components, dashboards and tool interfaces, and complete implementable visual and interactive polish.
 
 ## Procedure
 
-1. 明确界面的工作
-   - 先说清它帮助用户完成什么任务，而不是先选颜色或布局。
-   - 判断这是日常高频工具、营销展示、内容阅读、可视化探索、游戏，还是配置/管理后台。
-   - 如果已有 Figma、Sketch、MasterGo、Pixso、墨刀、摹客或截图是事实来源，优先还原设计上下文，不自行发明方向。
-
-2. 读取设计语境
-   - 在决定布局、色彩、字体或动效前，先写出一行设计读取：页面类型、目标受众、主要任务、品牌约束和可信赖感来源。
-   - 判断当前界面是视觉型网站、作品/品牌展示、产品营销、工具工作区、数据密集界面、移动原生流程，还是设计稿还原任务。
-   - 如果 brief 有明显分歧，例如“极简但强烈实验性”，只问一个会改变方向的问题；否则基于上下文做出明确选择。
-   - 受监管、公共服务、医疗、金融、儿童或强可访问性场景优先稳定、清晰和可恢复，不为审美冒险牺牲可用性。
-
-3. 定义审美主张
-   - 写出目标用户、使用场景、可信赖感来源和一个可被记住的视觉锚点。
-   - 视觉锚点可以来自信息结构、真实媒体、数据形态、行业材质、字体性格、交互节奏或空间组织，而不是空泛装饰。
-   - 表现力必须服务业务语境：工具型界面重效率和稳定，展示型页面重主体识别和记忆点。
-   - 为页面类型设定设计拨盘：视觉张力、动效强度、信息密度、媒体真实性和内容说服力；这些拨盘必须随任务变化，而不是沿用同一套模板。
-   - 工具型和数据型界面默认提高信息密度、降低装饰动效；营销、作品集和品牌页可以提高视觉张力，但仍要保证首屏任务、主体和 CTA 可见。
-   - 设计拨盘用于约束实现选择：高视觉张力不等于混乱排版，高动效强度不等于滚动劫持，高媒体真实性不等于堆 stock 氛围图。
-
-4. 生成或读取设计系统
-   - 若项目还没有设计系统，可运行 `node skills/fec-ui-design/scripts/design-system.mjs "<product audience tone>" --project "<name>"` 生成建议。
-   - 若需要跨会话复用，使用 `--persist` 生成 `design-system/<project>/MASTER.md`；页面差异用 `--page <page>` 写入 `pages/<page>.md`。
-   - 构建具体页面时先读页面 override，再读 Master；页面规则只覆盖差异，不复制全量设计系统。
-
-5. 建立首屏与视觉层级
-   - 工具型界面：首屏直接呈现核心工作区、列表、表格、画布或编辑器。
-   - 落地页：H1 使用品牌、产品、地点、人名或明确品类，价值说明放在辅助文案。
-   - 产品/对象页：首屏必须可见真实产品、对象、状态或可检查媒体。
-   - 首屏应留下一个明确记忆点，但不能遮挡核心任务、导航和状态反馈。
-   - 营销和产品页需要先写清受众、痛点、承诺、证据和行动入口；文案结构服务转化，但不使用夸张、空泛或不可验证的声明。
-   - 视觉型页面的首屏不能只是文字、渐变和装饰物；需要真实产品、人物、空间、品牌应用、数据状态或可检查的生成资产承担主体信息。
-   - 导航在桌面端应保持单行且高度克制；CTA 文案保持短而清楚，桌面端不应换成多行按钮。
-
-6. 组织视觉语言
-   - 字体：优先沿用项目字体体系；若任务允许建立新方向，选择能表达产品性格的标题/正文字体组合，并保证可读性。
-   - 色彩：明确主色、功能色、中性色和强调色的角色，避免所有元素平均用力。
-   - 空间：根据任务选择高密度、留白、非对称、分栏、画布式或编辑器式布局，不套用固定卡片模板。
-   - 动效：只为页面入场、层级展开、状态确认、错误反馈和重点引导建立节奏，并尊重 `prefers-reduced-motion`。
-   - 媒体：优先使用真实产品、真实状态、真实图表、可检查截图或本地生成资产；不要用模糊氛围图、占位 URL 或无关插画替代主体信息。
-   - 图表：先判断数据任务是趋势、比较、构成、分布还是流程，再选择图表，不把所有数据都做成卡片或饼图。
-   - 视觉参考：没有权威设计稿且页面视觉质量是核心目标时，可先生成或收集分区级参考图，再从图中提取布局、层级、色彩和媒体策略；不要把整站压成一个不可读长图。
-
-7. 对齐设计系统、组件与 token
-   - 先复用项目已有组件、token、图标库、路由和布局约定。
-   - 缺少 token 时集中补齐或明确记录，不要在多个组件里散落硬编码。
-   - 复杂 UI 在实现前写出复用组件、新建组件、响应式策略和状态覆盖。
-   - 设计系统先定义语义 token、组件 API、状态矩阵和使用边界，再落到 Tailwind、CSS Modules、组件库或 CSS 变量实现。
-   - Tailwind 专项 token、variant、dark mode 和 class 治理分流到 Tailwind 设计系统工作流；跨设备布局、容器查询和触摸目标分流到响应式布局工作流。
-   - 组件 API 应区分基础组件、业务组件和页面私有组件；避免让单个 `variant` 同时承担语义、尺寸、密度和权限含义。
-
-8. 打磨几何、文本和状态
-   - 嵌套圆角遵循“外层圆角约等于内层圆角 + 间距”的光学关系。
-   - 非对称图标、播放三角、箭头、星标等需要按视觉中心微调。
-   - 标题和短文本可使用 `text-wrap: balance` 或 `text-wrap: pretty`。
-   - 表格、价格、计数器、计时器使用 `font-variant-numeric: tabular-nums`。
-   - 小控件点击区域至少 40x40px，空间允许时优先 44x44px。
-   - focus ring 用于键盘定位，hover/active 用于鼠标反馈，disabled 不只靠透明度表达。
-   - 不在连续多个区块重复同一种三卡片、左右交错或大标题加右侧说明段落；每个区块的布局服务该区块的具体信息任务。
-   - Bento 和 feature grid 的格子数量必须由真实内容决定，不用空格子补构图；多格网格至少有明确主次、媒体或状态差异。
-   - 小型 uppercase eyebrow 要克制使用，不能成为每个区块的节奏拐杖。
-
-9. 验证设计结果
-   - 检查 loading、empty、error、disabled、hover、focus、selected 状态。
-   - 在 mobile(375px)、tablet(768px)、desktop(1440px) 检查文案是否溢出或遮挡。
-   - 对依赖图片、图表、画布或 3D 的界面，确认资源真实渲染且承担主体信息。
-   - 复核是否存在默认紫色渐变、空泛 hero、卡片堆叠、单一色相或无语境字体等模板化痕迹。
-   - 检查首屏是否同时具备任务入口、主体识别、可信证据和下一屏内容线索；若只剩装饰，应回到信息架构重做。
-   - 对生产级控件补齐 hover、active、focus-visible、disabled、loading、selected、invalid 和 skeleton 状态。
-   - 对仪表盘、表格、编辑器和配置台检查扫描路径、密度、固定尺寸和重复使用时的疲劳感。
-   - 对营销页、作品集和品牌页检查首屏是否适配常见小笔记本高度，导航是否单行，CTA 是否对比合格且不换行。
-   - 复核是否存在连续三段以上相同 section 结构、重复 zigzag、重复三卡片、卡片套卡片、假截图或没有主体信息的视觉资产。
+1. Clarify the work of the interface
+   - Start by saying what task it helps the user accomplish, rather than choosing a color or layout first.
+   - Determine whether this is a daily high-frequency tool, marketing display, content reading, visual exploration, game, or configuration/management backend.
+   - If Figma, Sketch, MasterGo, Pixso, Ink Knife, Mockup or screenshots are the source of truth, give priority to restoring the design context and do not invent your own direction.
+
+2. Read the design context
+   - Before deciding on layout, colors, fonts, or motion, write out a line of design that reads: page type, target audience, primary mission, brand constraints, and sources of trustworthiness.
+   - Determine whether the current interface is a visual website, work/brand display, product marketing, tool workspace, data-intensive interface, mobile native process, or design draft restoration task.
+   - If the brief is clearly divergent, e.g. "minimalist yet intensely experimental", only ask a question that will change direction; otherwise make clear choices based on context.
+   - Regulated, public service, medical, financial, children, or strong accessibility scenarios prioritize stability, clarity, and recoverability without sacrificing usability for aesthetic adventures.
+
+3. Define aesthetic proposition
+   - Write out the target users, usage scenarios, sources of trustworthiness, and a visual anchor that will be remembered.
+   - Visual anchors can come from information structure, real media, data form, industry materials, font character, interaction rhythm or spatial organization, rather than empty decoration.
+   - Expression must serve the business context: tool-based interfaces focus on efficiency and stability, while display-based pages focus on subject recognition and memory points.
+   - Set design dials for page types: visual intensity, motion intensity, information density, media authenticity and content persuasiveness; these dials must change with the task, rather than sticking to the same set of templates.
+   - Tool-type and data-type interfaces increase information density and reduce decorative animation by default; marketing, portfolio and brand pages can increase visual tension, but still ensure that the first screen task, main body and CTA are visible.
+   - The design dial is used to constrain implementation choices: high visual tension does not equal chaotic typography, high dynamic intensity does not equal scroll hijacking, and high media authenticity does not equal piles of stock atmosphere images.
+
+4. Generate or read design system
+   - If the project does not yet have a design system, you can run `node skills/fec-ui-design/scripts/design-system.mjs "<product audience tone>" --project "<name>"` to generate suggestions.
+   - If reuse across sessions is required, use `--persist` to generate `design-system/<project>/MASTER.md`; use `--page <page>` to write page differences into `pages/<page>.md`.
+   - When building a specific page, read the page override first, and then read the Master; the page rules only cover the differences and do not copy the full design system.
+
+5. Establish above-the-fold and visual hierarchy
+   - Tool-based interface: The core workspace, list, table, canvas or editor is directly displayed on the first screen.
+   - Landing page: H1 uses the brand, product, place, name or clear category, and the value description is placed in the auxiliary copy.
+   - Product/Object page: The real product, object, status or checkable media must be visible on the first screen.
+   - The first screen should leave a clear memory point, but should not obscure core tasks, navigation and status feedback.
+   - Marketing and product pages need to clearly define the audience, pain points, commitments, evidence and action entry points; the copywriting structure serves conversion, but does not use exaggerated, empty or unverifiable claims.
+   - The first screen of a visual page cannot be just text, gradients and decorations; it needs real products, people, spaces, brand applications, data status or checkable generated assets to bear the main information.
+   - Navigation should remain single-line and highly restrained on desktop; CTA copy should be kept short and clear, and should not be replaced with multi-line buttons on desktop.
+
+6. Organize visual language
+   - Font: Give priority to using the project font system; if the task allows the establishment of a new direction, choose a title/text font combination that can express the character of the product and ensure readability.
+   - Color: Clarify the roles of primary, functional, neutral and accent colors to avoid using equal force on all elements.
+   - Space: Choose high-density, blank, asymmetric, column, canvas or editor layout according to the task, and do not apply fixed card templates.
+   - Motion effects: Only establish rhythm for page entry, hierarchical expansion, status confirmation, error feedback and key guidance, and respect `prefers-reduced-motion`.
+   - Media: Prioritize the use of real products, real states, real diagrams, checkable screenshots or locally generated assets; do not replace the main information with vague atmosphere images, placeholder URLs or irrelevant illustrations.
+   - Charts: First determine whether the data task is trend, comparison, composition, distribution or process, and then choose charts. Do not make all data into cards or pie charts.
+   - Visual reference: When there is no authoritative design draft and the visual quality of the page is the core goal, you can first generate or collect section-level reference images, and then extract the layout, hierarchy, color and media strategy from the images; do not compress the entire site into an unreadable long image.
+
+7. Align design systems, components and tokens
+   - First reuse the existing components, tokens, icon libraries, routing and layout conventions of the project.
+   - When tokens are missing, centrally complete them or record them clearly. Do not scatter hard coding in multiple components.
+   - Write out reused components, new components, responsive strategies and state overrides before implementing complex UI.
+   - The design system first defines semantic tokens, component APIs, state matrices and usage boundaries, and then falls to Tailwind, CSS Modules, component libraries or CSS variable implementations.
+   - Tailwind's special token, variant, dark mode and class management are offloaded to the Tailwind design system workflow; cross-device layout, container query and touch target are offloaded to the responsive layout workflow.
+   - The component API should distinguish between basic components, business components and page-private components; avoid letting a single `variant` bear semantic, size, density and permission implications at the same time.
+
+8. Polish geometry, text and states
+   - Nested fillets follow the optical relationship of "the outer fillet is approximately equal to the inner fillet + spacing".
+   - Asymmetric icons, play triangles, arrows, stars, etc. need to be fine-tuned according to the visual center.
+   - Titles and short text can use `text-wrap: balance` or `text-wrap: pretty`.
+   - Tables, prices, counters, and timers use `font-variant-numeric: tabular-nums`.
+   - The clickable area of the small control should be at least 40x40px, and 44x44px is preferred if space allows.
+   - focus ring is used for keyboard positioning, hover/active is used for mouse feedback, and disabled is not only expressed by transparency.
+   - Do not repeat the same three cards, stagger left and right, or have a large title with an explanatory paragraph on the right in multiple consecutive blocks; the layout of each block serves the specific information task of that block.
+   - The number of cells in the Bento and feature grid must be determined by the real content, and no empty cells are used to supplement the composition; multi-cell grids must at least have clear distinctions in primary and secondary, media or status.
+   - The small uppercase eyebrow should be used with restraint and not become a rhythm crutch for each block.
+
+9. Verify design results
+   - Check loading, empty, error, disabled, hover, focus, selected status.
+   - Check whether the copy text overflows or is blocked in mobile(375px), tablet(768px), desktop(1440px).
+   - For interfaces that rely on pictures, charts, canvases or 3D, confirm that the resources are truly rendered and bear the main information.
+   - Review whether there are traces of templates such as default purple gradients, empty heroes, card stacks, single hues, or non-contextual fonts.
+   - Check whether the first screen has task entrance, subject identification, credible evidence and content clues for the next screen; if only decoration is left, return to the information architecture and redo it.
+   - Complete hover, active, focus-visible, disabled, loading, selected, invalid and skeleton states for production-grade controls.
+   - Fatigue when checking scan paths, density, fixed sizes, and reuse for dashboards, tables, editors, and configuration tables.
+   - For marketing pages, portfolios and brand pages, check whether the first screen adapts to the height of common small notebooks, whether the navigation is single-line, and whether the CTA is qualified and does not wrap.
+   - Review whether there are more than three consecutive paragraphs with the same section structure, repeated zigzag, repeated three cards, cards within a card set, fake screenshots, or visual assets without main information.
 
 ## Constraints
 
-- 不把工具型应用做成营销落地页；首屏应是可用工作区。
-- 不用通用紫色渐变、装饰光斑、堆叠卡片或空泛 hero 作为默认方案。
-- 不用三等分 feature cards、连续 zigzag、重复 eyebrow、假产品截图或不可检查媒体作为默认页面节奏。
-- 不使用无语境默认字体、均匀无重点配色、重复圆角卡片和模板化双栏 hero 来替代真实设计判断。
-- 不在卡片里再套大卡片；页面分区优先用全宽区域或无框布局。
-- 不用可见文案解释控件本该表达的功能，常见动作优先用图标和 tooltip。
-- 不为了质感添加大面积装饰、模糊光斑、无语义渐变或无关重写。
-- 不为了统一风格让整个界面落入单一色相；颜色应有层次和语义区分。
-- 不把生成器输出当成不可修改的设计稿；它是决策起点，必须结合项目已有组件、token、用户任务和真实数据校正。
-- 不用不可检查的远程占位图、通用 stock 氛围图或 lorem 文案作为交付主体；缺素材时明确生成、制作或降级为真实结构化内容。
-- 不让视觉 polish 破坏键盘路径、触摸目标、文本可读性或低端设备性能。
-- 不把 Tailwind、组件库或 Storybook 文档等实现载体当成设计方向本身；它们应承接已经明确的产品语境和 token 边界。
-- 不因参考系统偏好而强制某个框架、图标库、动效库或 CSS 工具；始终优先遵循当前项目依赖和设计系统。
+- Do not turn tool-based applications into marketing landing pages; the home screen should be the available workspace.
+- No generic purple gradients, decorative flares, stacked cards, or empty heroes as the default scheme.
+- Don’t use thirds of feature cards, continuous zigzags, repeating eyebrows, fake product screenshots, or uncheckable media as the default page rhythm.
+- Don’t use context-free default fonts, uniform unfocused color palettes, repetitive rounded-corner cards, and templated two-column heroes as a substitute for real design judgment.
+- Do not put large cards inside cards; give priority to using full-width area or frameless layout for page partitions.
+- No visible copy is used to explain the functions that controls should express. Use icons and tooltips first for common actions.
+- Do not add large-area decorations, blurry spots, semantic-less gradients or irrelevant rewriting for the sake of texture.
+- Do not make the entire interface fall into a single hue in order to unify the style; colors should be hierarchical and semantically differentiated.
+- Do not regard the generator output as an unmodifiable design draft; it is the starting point for decision-making and must be corrected based on the existing components, tokens, user tasks and real data of the project.
+- No uncheckable remote placeholder images, generic stock mood images, or lorem copy as the delivery body; explicitly generate, produce, or degrade to real structured content when material is lacking.
+- Don't let visual polish ruin keyboard paths, touch targets, text readability, or low-end device performance.
+- Do not regard implementation vehicles such as Tailwind, component libraries, or Storybook documents as the design direction itself; they should inherit the already clear product context and token boundaries.
+- Do not force a framework, icon library, animation library or CSS tool to reference system preferences; always prioritize current project dependencies and design systems.
 
 ## Expected Output
 
-输出应包含明确的设计方向、首屏记忆点、视觉语言策略、组件/布局边界、状态覆盖、响应式策略和验证结果。复核时界面应符合业务语境、视觉层级支持快速扫描、交互状态完整，并避免泛化模板感。
+The output should include clear design direction, above-the-fold memo, visual language strategy, component/layout boundaries, state overrides, responsiveness strategy, and validation results. When reviewing, the interface should conform to the business context, the visual hierarchy should support fast scanning, the interaction status should be complete, and a generalized template feeling should be avoided.

package/skills/fec-ui-design/references/design-intelligence.md

@@ -1,97 +1,97 @@
-# 设计智能参考
+#DesignSmartReference
 
-本参考用于把模糊的 UI 请求转成可执行设计系统。先识别产品类别，再组合风格原型、色彩角色、字体情绪、动效节奏、图表任务和 UX 风险。
+This reference is used to turn obscure UI requests into an executable design system. Start by identifying the product category, then combine style archetypes, color roles, font moods, motion rhythms, graphic tasks, and UX risks.
 
-## 决策流程
+## Decision-making process
 
-1. 提取关键词：产品类型、用户、场景、主要任务、内容密度、品牌语气、技术栈。
-2. 写出设计读取：页面类型、受众、主任务、品牌约束和可信赖感来源。
-3. 匹配产品规则：从 `data/product-rules.json` 选择最接近的类别，记录推荐结构、风险和反模式。
-4. 选择风格原型：从 `data/style-archetypes.json` 选择 1 个主风格和最多 1 个辅助风格，避免风格拼贴。
-5. 设定设计拨盘：视觉张力、动效强度、信息密度、媒体真实性、内容说服力都用 1-10 表达，并随页面类型变化。
-6. 建立 token 方向：定义主色、强调色、背景、前景、边框、危险色和 focus ring 的语义角色。
-7. 选择字体情绪：不要只选“好看的字体”，要说明标题和正文各自承担的语气与可读性。
-8. 判断数据表达：趋势用折线/面积，比较用柱状，构成少量类别可用环图，流程用漏斗/步骤，明细必须保留表格替代。
-9. 输出反模式和质量门禁：每个设计建议必须附带“不要做什么”，并根据页面类型补充首屏、CTA、媒体真实性、section 变化和状态完整度检查。
+1. Extract keywords: product type, users, scenarios, main tasks, content density, brand tone, technology stack.
+2. Write out the design reads: page type, audience, primary mission, brand constraints, and sources of trustworthiness.
+3. Match product rules: Select the closest category from `data/product-rules.json` and record the recommended structure, risks and anti-patterns.
+4. Select style archetypes: Select 1 main style and up to 1 auxiliary style from `data/style-archetypes.json` to avoid style collage.
+5. Set the design dial: visual tension, motion intensity, information density, media authenticity, and content persuasiveness are all expressed on a scale of 1-10, and vary with the page type.
+6. Establish token direction: define the semantic roles of main color, accent color, background, foreground, border, dangerous color and focus ring.
+7. Choose font mood: Don’t just choose a “good-looking font”, explain the tone and readability of the title and body text respectively.
+8. Judgment of data expression: Use polylines/areas for trends, columns for comparisons, donut charts to form a small number of categories, funnels/steps for processes, and tables must be retained for details.
+9. Output anti-patterns and quality gates: Every design suggestion must be accompanied by a “what not to do” and supplemented with above-the-fold, CTAs, media authenticity, section changes, and state integrity checks based on page type.
 
-## 方向 Advisor
+## Direction Advisor
 
-当用户只说“好看一点”“给几个方向”“我也不知道什么风格”且没有权威设计稿时，不要连续追问泛泛口味问题。先给 3 个差异明显的方向，让用户能判断取舍。
+When the user only says "looks better", "give me some directions", "I don't know what style" and there is no authoritative design draft, don't continue to ask general questions about taste. First, give 3 directions with obvious differences so that users can judge the choice.
 
-每个方向必须包含：
+Each direction must contain:
 
-- 适用场景：为什么适合当前产品、受众和任务。
-- 视觉锚点：信息结构、真实媒体、数据形态、材质、字体性格、空间组织或交互节奏。
-- 关键 token：主色、强调色、背景、字体情绪、圆角/边框/阴影倾向。
-- 避免项：这个方向最容易滑向的模板化错误。
+- Applicable scenarios: Why it is suitable for the current product, audience and task.
+- Visual anchors: information structure, real media, data form, material, font character, spatial organization or interaction rhythm.
+- Key tokens: main color, accent color, background, font mood, rounded corners/border/shadow tendency.
+- What to avoid: This is the easiest templating error to slip into.
 
-三个方向应来自不同设计逻辑，例如：
+The three directions should come from different design logics, such as:
 
-- 信息架构型：高密度、理性、数据优先，适合 B2B、运营、金融、工程工具。
-- 编辑叙事型：版式、留白、强文字层级，适合品牌故事、内容产品、作品集。
-- 产品实证型：真实截图、对象、状态、流程证据优先，适合 SaaS、硬件、开发者工具。
-- 表现实验型：强动效、空间感、生成视觉，适合发布页、活动页、艺术/创意项目。
-- 温暖人本型：低攻击性色彩、可亲近插画或真实人物，适合教育、健康、生活方式。
+- Information architecture type: high-density, rational, data-first, suitable for B2B, operations, finance, and engineering tools.
+- Editorial narrative type: layout, white space, strong text hierarchy, suitable for brand stories, content products, and portfolios.
+- Product demonstration type: real screenshots, objects, status, and process evidence are given priority, suitable for SaaS, hardware, and developer tools.
+- Experimental expression: strong motion effect, sense of space, generative vision, suitable for release pages, event pages, and art/creative projects.
+- Warm and humanistic: low-offensive colors, approachable illustrations or real characters, suitable for education, health, and lifestyle.
 
-用户选择方向后，再把它落成设计系统和页面结构；不要把 3 个方向拼贴成一个混杂系统。
+After the user chooses the direction, then implement it into the design system and page structure; do not collage the 3 directions into a mixed system.
 
-## 真实资产优先
+## Real assets take priority
 
-品牌或产品相关 UI 的识别度来自真实资产，而不是颜色猜测。优先级：
+Brand or product related UI recognition comes from real assets, not color guesswork. Priority:
 
-1. Logo、产品图、真实 UI 截图、实体照片、品牌应用图。
-2. 项目内已有 icon、组件、数据状态、图表和截图。
-3. 为当前任务生成的专用资产。
-4. 明确标记的结构化 placeholder。
+1. Logo, product pictures, real UI screenshots, physical photos, and brand application pictures.
+2. The project already has icons, components, data status, charts and screenshots.
+3. Special assets generated for the current task.
+4. Clearly marked structured placeholder.
 
-不要用 CSS 轮廓、通用插画、假截图或远程占位图替代用户需要识别的主体。缺少关键资产时，先标记资产缺口并给替代路线；若 logo 或主体产品是首屏识别核心，应暂停确认或改为不依赖品牌识别的结构方案。
+Don’t use CSS outlines, generic illustrations, fake screenshots, or remote placeholder images to replace the subject that users need to identify. When there is a lack of key assets, first mark the asset gap and provide an alternative route; if the logo or main product is the core of first-screen recognition, confirmation should be suspended or changed to a structural plan that does not rely on brand recognition.
 
-## v0 校准
+## v0 calibration
 
-视觉风险高、方向不明确或页面影响面较大时，先交付一个可看的 v0，而不是一次性做完整页面。
+When the visual risk is high, the direction is unclear, or the page has a large impact, deliver a viewable v0 first instead of doing the entire page at once.
 
-v0 应包含：
+v0 should contain:
 
-- 核心布局、首屏层级、主要 token 和一个关键模块。
-- 明确 placeholder 和资产缺口。
-- 1-2 个可替换方向点，例如密度、色彩温度或媒体策略。
-- 不包含完整状态矩阵、所有内容细节或生产级动效。
+- Core layout, first screen hierarchy, main token and a key module.
+- Clarify placeholder and asset gaps.
+- 1-2 alternative direction points such as density, color temperature or media strategy.
+- Does not include the full state matrix, all content details, or production-grade animations.
 
-v0 通过后再补齐组件、状态、响应式和交互动效。
+After v0 is passed, components, states, responsiveness and interactive effects will be completed.
 
-## 设计 Critique
+## Design Critique
 
-当用户要求“评审 UI”“好不好看”“再高级一点”或交付前需要自检时，按 5 个维度输出具体问题，而不是只给主观形容：
+When users request to "review the UI", "whether it looks good or not", "more advanced" or a self-inspection is required before delivery, output specific questions in 5 dimensions instead of just giving subjective descriptions:
 
-- 方向一致性：视觉选择是否服务设计读取和产品任务。
-- 层级与扫描：首屏、标题、CTA、数据、状态是否有清楚主次。
-- 工艺质量：间距、对齐、色彩数量、文字换行、圆角/边框/阴影是否稳定。
-- 功能完整度：loading、empty、error、disabled、hover、focus、selected 是否覆盖。
-- 原创性与识别度：是否摆脱通用渐变、三卡片、假截图、无主体 hero。
+- Directional consistency: Whether the visual choice serves the design read and product mission.
+- Hierarchy and scanning: Whether the first screen, title, CTA, data, and status are clearly prioritized.
+- Workmanship quality: spacing, alignment, number of colors, text wrapping, rounded corners/borders/shadows are stable.
+- Function completeness: whether loading, empty, error, disabled, hover, focus, and selected are covered.
+- Originality and recognition: whether to get rid of universal gradients, three cards, fake screenshots, and bodyless heroes.
 
-输出应按严重程度给出可执行修复，不评价设计者本人。
+The output should give executable fixes by severity, without judging the designers themselves.
 
-## 何时运行生成器
+## When to run the generator
 
-使用以下命令生成设计系统建议：
+Generate design system recommendations using the following command:
 
 ```bash
 node skills/fec-ui-design/scripts/design-system.mjs "beauty spa booking" --project "Serenity Spa"
 ```
 
-输出 Markdown 适合贴入计划或 PR 描述；输出 JSON 适合测试或工具消费：
+Output Markdown is suitable for pasting into plans or PR descriptions; output JSON is suitable for testing or tool consumption:
 
 ```bash
 node skills/fec-ui-design/scripts/design-system.mjs "fintech analytics dashboard" --format json --stack next
 ```
 
-## 输出必须回答
+## Output must answer
 
-- 这个界面的主任务是什么？
-- 设计读取和五个设计拨盘分别是什么？
-- 推荐哪种页面结构或工作区结构？
-- 视觉锚点是什么，为什么贴合业务？
-- 主风格、字体、色彩、动效分别服务什么目标？
-- 图表和数据密度如何处理？
-- 哪些反模式必须避免？
-- 上线前最小 QA 清单是什么？
+- What is the main task of this interface?
+- What are the design reads and the five design dials?
+- What page structure or workspace structure is recommended?
+- What is a visual anchor and why does it fit the business?
+- What goals do the main style, font, color, and animation serve respectively?
+- How to deal with charts and data density?
+- What anti-patterns must be avoided?
+- What is the minimum QA checklist before going live?

package/skills/fec-ui-design/references/master-page-overrides.md

@@ -1,30 +1,30 @@
-# 全局/页面级差异覆盖
+# Global/page level difference coverage
 
-当项目需要长期保持 UI 一致性时，用 `design-system/MASTER.md` 存放全局设计系统，用 `design-system/pages/<page>.md` 存放页面级差异。
+When the project needs to maintain UI consistency for a long time, use `design-system/MASTER.md` to store the global design system, and use `design-system/pages/<page>.md` to store page-level differences.
 
-## 读取顺序
+## Reading order
 
-1. 先检查当前页面是否有 `design-system/<project>/pages/<page>.md`。
-2. 如果存在，页面文件里的规则覆盖 Master 中相同维度。
-3. 如果不存在，完全遵循 `design-system/<project>/MASTER.md`。
-4. 页面文件只记录差异，不复制 Master 全文。
+1. First check whether the current page has `design-system/<project>/pages/<page>.md`.
+2. If it exists, the rules in the page file cover the same dimensions in the Master.
+3. If it does not exist, follow `design-system/<project>/MASTER.md` exactly.
+4. The page file only records differences and does not copy the full text of the Master.
 
-## 生成命令
+## Generate command
 
 ```bash
 node skills/fec-ui-design/scripts/design-system.mjs "saas analytics dashboard" --project "Acme Console" --persist --output-dir .
 ```
 
-生成页面 overrides：
+Generate page overrides:
 
 ```bash
 node skills/fec-ui-design/scripts/design-system.mjs "saas analytics dashboard" --project "Acme Console" --page dashboard --persist --output-dir .
 ```
 
-## 页面 override 应包含
+## Page override should contain
 
-- 页面任务和信息密度差异
-- 布局差异：工作区、表格、图表、表单、详情页或营销首屏
-- token 差异：只写需要覆盖的语义色、间距、状态或图表色
-- 组件差异：只写当前页面新增或改变的组件行为
-- QA 焦点：当前页面最容易出错的响应式、可访问性、性能或交互风险
+- Differences in page tasks and information density
+- Layout differences: workspace, table, chart, form, detail page or marketing first screen
+- token difference: only write the semantic color, spacing, status or chart color that needs to be covered
+- Component differences: only write new or changed component behaviors on the current page
+- QA Focus: The current page’s most error-prone responsiveness, accessibility, performance, or interaction risks

package/skills/fec-ui-design/references/pre-delivery-checklist.md

@@ -1,39 +1,39 @@
-# UI/UX 交付前检查
-
-## 严重
-
-- 文本对比度：正文至少 4.5:1，大字号至少 3:1。
-- 键盘可达：菜单、弹窗、标签页、抽屉和自定义控件都能键盘操作。
-- 焦点可见：focus ring 不能被全局样式移除。
-- 图标按钮：必须有可访问名称。
-- 触摸目标：移动端主要交互至少 44x44px；空间允许时使用 48px。
-
-## 高优先级
-
-- 首屏：工具型界面直接展示核心工作区，不用营销 hero 替代功能。
-- 首屏：营销、作品集和品牌页在常见小笔记本高度内显示主体、CTA 和下一屏线索。
-- CTA：按钮文案在桌面端不换行，对比度合格，同一意图使用一致标签。
-- 导航：桌面端保持单行，移动端折叠后仍能到达主要路径。
-- 响应式：375px、768px、1024px、1440px 无水平溢出、遮挡或文本截断。
-- 性能：图片有尺寸或 aspect-ratio；非首屏图片懒加载；列表过大时虚拟化。
-- 动效：只动画 transform/opacity，尊重 `prefers-reduced-motion`。
-- 状态：loading、empty、error、disabled、hover、focus、selected 都有设计。
-
-## 中优先级
-
-- 字体：正文不小于 16px；数字列、金额、计时器使用 tabular nums。
-- 颜色：错误、成功、警告不只靠颜色表达。
-- 表单：label 常驻，错误靠近字段，提交后有 loading/success/error。
-- 导航：当前路由可识别，返回行为可预测，深层页面仍能回到主路径。
-- 图表：有标题、单位、图例、tooltip 或明细表替代，色彩不依赖红绿区分。
-
-## 反模式
-
-- 用装饰光斑、紫色渐变、卡片堆叠掩盖信息结构不足。
-- 连续三段以上复用三卡片、左右交错、split header 或同一种 reveal 动效。
-- 视觉型页面只有文字和渐变，没有真实产品、真实状态、品牌应用或可检查媒体。
-- Bento 用空格子补构图，或 feature grid 每个格子同权重、同背景、同节奏。
-- hover 导致布局位移。
+# UI/UX pre-delivery inspection
+
+## Serious
+
+- Text contrast: at least 4.5:1 for main text and 3:1 for large fonts.
+- Keyboard accessible: menus, pop-up windows, tabs, drawers and custom controls can all be operated by the keyboard.
+- Focus visible: focus ring cannot be removed by global styles.
+- Icon button: must have an accessible name.
+- Touch targets: Primary interactions on mobile should be at least 44x44px; use 48px when space allows.
+
+## High priority
+
+- First screen: The tool-based interface directly displays the core workspace, without the need for marketing hero replacement functions.
+- Above the fold: Marketing, portfolio, and brand pages display body, CTA, and next-screen cues within common small notebook heights.
+- CTA: The button copy does not wrap on the desktop, the contrast is acceptable, and consistent labels are used for the same purpose.
+- Navigation: Keep a single line on the desktop, and the main path can still be reached after folding on the mobile version.
+- Responsive: 375px, 768px, 1024px, 1440px No horizontal overflow, occlusion or text truncation.
+- Performance: images have size or aspect-ratio; images below the first screen are lazy loaded; virtualization is used when the list is too large.
+- Animation: only animate transform/opacity, respecting `prefers-reduced-motion`.
+- Status: loading, empty, error, disabled, hover, focus, and selected are all designed.
+
+## Medium priority
+
+- Font: The main text should not be smaller than 16px; use tabular nums for numerical columns, amounts, and timers.
+- Color: Error, success, and warning are not only expressed by color.
+- Form: label is resident, errors are close to fields, and there will be loading/success/error after submission.
+- Navigation: The current route is identifiable, the return behavior is predictable, and deep pages can still return to the main path.
+- Charts: replaced by titles, units, legends, tooltips or detailed tables, and the colors do not rely on the distinction between red and green.
+
+## Anti-pattern
+
+- Use decorative light spots, purple gradients, and card stacks to cover up the lack of information structure.
+- Reuse three cards, left and right interleaving, split header or the same reveal animation for more than three consecutive paragraphs.
+- Visual pages have only text and gradients, no real products, real status, brand applications or inspectable media.
+- Bento uses empty grids to complete the composition, or feature grid. Each grid has the same weight, background, and rhythm.
+-Hover causes layout displacement.
 - `transition: all`、`will-change: all`。
-- 低对比灰字、无意义透明度、单一色相界面。
-- 空状态只有“暂无数据”，没有下一步动作。
+- Low-contrast gray text, meaningless transparency, and single-hue interface.
+- The empty status is only "No data yet" and there is no next action.

package/skills/fec-validation-fix/SKILL.md

@@ -1,51 +1,51 @@
 ---
 name: fec-validation-fix
-description: Use when running existing project validation commands and fixing failures after code changes, including lint, type-check, unit/integration test, build, CI, or local script failures. Do not use when the task is to design or author new component/E2E tests; Chinese triggers include 验证, 检查失败, 修复失败, CI 失败.
+description: Use when running existing project validation commands and fixing failures after code changes, including lint, type-check, unit/integration test, build, CI, or local script failures. Do not use when the task is to design or author new component/E2E tests; Chinese triggers include validation, check failures, fix failures, CI failures.
 ---
 
-# 验证并修复
+# Verify and fix
 
 ## Purpose
 
-自动化执行已有验证命令，分析失败原因并安全修复，确保质量门禁达标。
+Automatically execute existing verification commands, analyze the reasons for failure and safely repair them to ensure that quality access control meets standards.
 
 ## Procedure
 
-1. 从 package.json 或仓库文档中识别可用命令。
-2. 优先按以下顺序执行：
+1. Identify available commands from package.json or repository documentation.
+2. Prioritize execution in the following order:
    - lint
    - type-check
    - unit/integration tests
    - build
-3. 仔细阅读失败输出。
-4. 将错误按文件、错误类型和依赖关系分组，优先处理阻塞后续诊断的根因。
-5. 一次只修复一类问题，并显示或记录关键错误上下文。
-6. 每次关键修复后重新执行受影响命令，确认错误是否减少。
-7. 如果同一错误连续三次修复仍失败，停止扩大改动并报告阻塞。
-8. 最后按 `Expected Output` 总结执行结果、修复内容和剩余风险。
+3. Read the failure output carefully.
+4. Group errors by file, error type and dependency, prioritizing root causes that block subsequent diagnosis.
+5. Fix one type of problem at a time and display or log critical error context.
+6. After each critical repair, re-execute the affected command to confirm whether the error is reduced.
+7. If the same error still fails to be repaired three times in a row, stop expanding changes and report blocking.
+8. Finally, press `Expected Output` to summarize the execution results, repair content and remaining risks.
 
 ## Failure Triage
 
-- 先修最早出现且会级联的错误，例如缺失类型、导入失败、配置解析失败。
-- 区分真实产品 bug、测试环境问题、快照漂移、依赖版本变化和 flaky。
-- 对 CI 专属失败记录 Node 版本、包管理器、环境变量、路径大小写和工作目录差异。
-- 修复测试时优先修产品代码或测试等待方式，不用删除断言掩盖真实回归。
+- Fix the earliest errors that will cascade first, such as missing types, import failures, and configuration parsing failures.
+- Differentiate between real product bugs, test environment issues, snapshot drift, dependency version changes and flaky.
+- Log Node version, package manager, environment variables, path case, and working directory differences for CI-specific failures.
+- When fixing tests, give priority to fixing product code or testing waiting methods, instead of deleting assertions to cover up real regressions.
 
 ## Constraints
 
-- 不要盲目关闭规则来消除报错
-- 除非有明确理由，不要为了通过检查而降低类型安全
-- 不要因为附近测试失败就顺手重写无关模块
-- 不要一次性修改多个无关根因
-- 不要删除失败测试来让验证通过
-- 不要只运行失败命令的片段就声称整体验证通过
+- Do not blindly turn off rules to eliminate errors
+- Don't compromise type safety to pass checks unless there is a clear reason to do so
+- Don’t rewrite irrelevant modules just because a nearby test fails
+- Do not modify multiple irrelevant root causes at once
+- Don't remove failing tests to make validation pass
+- Don't just run a fragment of the failed command and claim that the overall validation passed
 
-## 详细参考
+## Detailed reference
 
-撰写验证修复报告时，加载 [references/report-template.md](references/report-template.md)。
+When writing a verification fix report, load [references/report-template.md](references/report-template.md).
 
 ## Expected Output
 
-- lint / type-check / test / build 等验证命令全部通过
-- 失败项已修复或给出明确原因和后续行动
-- 修复报告保存为 `reports/validation-fix-YYYY-MM-DD-HHmmss.md`
+- All verification commands such as lint/type-check/test/build passed
+- Failed items have been fixed or given clear reasons and follow-up actions
+- The fix report is saved as `reports/validation-fix-YYYY-MM-DD-HHmmss.md`