@bovinphang/frontend-craft 2.7.0 → 2.8.0

package/skills/fec-source-driven-development/SKILL.md

@@ -1,87 +1,87 @@
 ---
 name: fec-source-driven-development
-description: Use when frontend decisions depend on framework, library, browser, runtime, package, API, or platform behavior that may have changed, including official documentation checks, version-sensitive patterns, migration choices, or public interface assumptions; Chinese triggers include 查官方文档, 以源码为准, source-driven, 版本差异.
+description: Use when frontend decisions depend on framework, library, browser, runtime, package, API, or platform behavior that may have changed, including official documentation checks, version-sensitive patterns, migration choices, or public interface assumptions; Chinese triggers include Check official documentation, source code shall prevail, source-driven, version differences.
 ---
 
-# 来源驱动开发
+# Source driven development
 
 ## Purpose
 
-在前端实现、评审和架构决策中优先依据项目内事实、官方文档和当前版本行为，避免沿用过时经验或未经验证的假设。
+Prioritize the use of in-project facts, official documentation, and current version behavior in front-end implementation, review, and architecture decisions, and avoid relying on outdated experience or unverified assumptions.
 
 ## Procedure
 
-1. 判断是否需要查源
-   - 涉及框架新版本、路由、渲染模式、缓存、构建工具、浏览器 API、包发布格式、鉴权协议或公共接口时必须查源。
-   - 涉及项目约定时先读本仓库 README、配置、模板、已有实现、测试和迁移记录。
-   - 只是稳定语言语法或明显局部重构时，可使用项目现有模式作为事实来源。
-
-2. 收集权威材料
-   - 首选官方文档、规范、源码、release notes、migration guide、类型定义和项目内测试。
-   - 第三方文章只能作为线索，不能作为最终依据。
-   - 对快速变化的库记录包名、版本、文档日期或页面标题。
-   - 当用户要求从本地知识库、项目资料库或 `knowledge/` 目录回答问题时，先走本地知识检索，不使用网络搜索补事实。
-
-3. 提炼决策
-   - 写清当前版本推荐做法、弃用做法、限制条件和迁移注意事项。
-   - 对多个可行方案说明选择理由、兼容性、维护成本和回退方式。
-   - 若文档和项目现状冲突，优先解释冲突并给出渐进调整，不直接推翻已运行系统。
-   - 对依赖升级、框架迁移和公共 API 变化，记录 release notes、migration guide、版本范围、破坏性变更和回滚方案。
-
-4. 落到实现
-   - 将外部行为隔离在适配层、配置层或小型工具函数中，避免在组件里散落版本假设。
-   - 公共接口变化要保持命名、错误形状、默认值和兼容策略清晰。
-   - 代码注释只记录非显而易见的来源约束，不粘贴大段文档。
-
-5. 验证假设
-   - 用类型检查、最小复现、单元测试、组件测试、E2E、构建或浏览器验证证明关键假设。
-   - 如果无法验证，报告不确定性、风险范围和需要用户或团队确认的信息。
-6. 留下轻量决策记录
-   - 当结论会影响公共接口、依赖版本、目录规范或团队工作流时，补充 ADR/变更记录或交给文档同步流程。
+1. Determine whether it is necessary to check the source
+   - Source checking is required when new versions of frameworks, routing, rendering modes, caches, build tools, browser APIs, package publishing formats, authentication protocols, or public interfaces are involved.
+   - When it comes to project commitments, read the README, configuration, templates, existing implementations, testing and migration records of this warehouse first.
+   - Use the project's existing schema as a source of truth when simply stabilizing the language syntax or significantly partial refactoring.
+
+2. Collect authoritative materials
+   - Preferred official documentation, specifications, source code, release notes, migration guide, type definitions and in-project testing.
+   - Third-party articles can only be used as clues and cannot be used as the final basis.
+   - Record package name, version, document date or page title for rapidly changing libraries.
+   - When a user asks to answer a question from a local knowledge base, project repository or `knowledge/` directory, perform local knowledge retrieval first and do not use network search to fill in the facts.
+
+3. Refine decisions
+   - Write down recommended practices, deprecated practices, limitations and migration considerations for the current version.
+   - Explain the reasons for selection, compatibility, maintenance costs and fallback methods for multiple feasible options.
+   - If there is a conflict between the document and the current status of the project, priority will be given to explaining the conflict and making incremental adjustments instead of directly overturning the running system.
+   - Record release notes, migration guide, version scope, breaking changes and rollback plans for dependency upgrades, framework migrations and public API changes.
+
+4. Fall to implementation
+- Isolate external behavior in the adaptation layer, configuration layer or small utility functions to avoid spreading version assumptions throughout the component.
+   - Public interface changes should keep naming, error shapes, default values, and compatibility policies clear.
+   - Code comments only record non-obvious source constraints and do not paste large sections of documentation.
+
+5. Test your hypothesis
+   - Prove key assumptions with type checking, minimal reproduction, unit testing, component testing, E2E, build or browser validation.
+   - If verification is not possible, report uncertainty, risk range, and information that requires confirmation by the user or team.
+6. Leave a lightweight record of decisions
+   - Supplement ADR/change records or hand off to the document sync process when conclusions impact public interfaces, dependency versions, catalog specifications or team workflows.
 
 ## Local Knowledge Retrieval
 
-当用户指定本地知识库路径，或默认 `knowledge/` 目录存在时，可用本流程回答资料库问题、抽取证据或辅助决策。
+When the user specifies the local knowledge base path, or the default `knowledge/` directory exists, this process can be used to answer database questions, extract evidence, or assist decision-making.
 
-1. 定位根目录
-   - 用户明确指定路径时使用该路径。
-   - 否则检查当前项目下 `knowledge/` 是否存在；不存在时说明未找到默认知识库并请求路径。
-   - 不用文件 glob 判断目录是否存在。
+1. Locate the root directory
+   - Use this path when the user explicitly specifies the path.
+   - Otherwise, check whether `knowledge/` under the current project exists; if it does not exist, it means that the default knowledge base is not found and the path is requested.
+   - No need to use file glob to determine whether the directory exists.
 
-2. 分层导航
-   - 优先读取根目录和子目录中的 `data_structure.md`。
-   - 根据目录说明选择最相关的少量分支，不一次性遍历整个知识库。
-   - 记录候选文件、主题、时间/版本范围和为什么相关。
+2. Hierarchical navigation
+   - Read `data_structure.md` in the root directory and subdirectories first.
+   - Select the most relevant few branches according to the directory description, without traversing the entire knowledge base at once.
+   - Document candidate files, topics, time/version range and why they are relevant.
 
-3. 渐进检索
-   - Markdown、文本、日志：先用关键词搜索，再局部读取命中上下文。
-   - PDF：处理前先确认可用工具和提取路线，优先提取到临时文本后再检索，避免把整份 PDF 打进上下文。
-   - Excel：处理前先确认读取/分析路线，先看工作表、列名和少量样例，再按字段过滤或聚合。
-   - 默认最多 5 轮关键词迭代；每轮根据已找到证据调整同义词、缩写和范围。
+3. Progressive search
+   - Markdown, text, log: first search with keywords, and then partially read the hit context.
+   - PDF: Confirm the available tools and extraction routes before processing, and prioritize extraction of temporary text before retrieval to avoid putting the entire PDF into context.
+   - Excel: Confirm the read/analysis route before processing, first look at the worksheet, column names and a few samples, and then filter or aggregate by field.
+   - Default to up to 5 rounds of keyword iteration; each round adjusts synonyms, abbreviations, and scope based on found evidence.
 
-4. 回答与溯源
-   - 先给结论，再列文件路径、章节、页码、工作表或行号附近作为依据。
-   - 证据不足时说明查过哪些路径、缺什么信息，以及用户如何缩小范围。
-   - 不把知识库外的网络信息混入答案，除非用户另行要求查外部来源。
+4. Answer and traceability
+   - Give the conclusion first, and then list the file path, chapter, page number, worksheet or line number as a basis.
+   - If there is insufficient evidence, explain which paths have been checked, what information is missing, and how the user can narrow down the scope.
+   - Do not mix online information from outside the knowledge base into answers unless the user requests otherwise to check external sources.
 
 ## Source Priority
 
 | Priority | Source | Use |
 | -------- | ------ | --- |
-| 1 | 项目内配置、测试、已有实现 | 判断本仓库真实约定 |
-| 2 | 官方文档、源码、类型定义 | 判断当前推荐行为 |
-| 3 | 标准规范、浏览器兼容数据 | 判断平台能力和兼容边界 |
-| 4 | Issue、讨论、第三方文章 | 辅助排查，不能单独定案 |
+| 1 | Configuration, testing, and implementation within the project | Determine the true agreement of this warehouse |
+| 2 | Official documents, source code, type definitions | Determine current recommended behavior |
+| 3 | Standard specifications, browser compatibility data | Determine platform capabilities and compatibility boundaries |
+| 4 | Issues, discussions, third-party articles | Auxiliary investigation, cannot be finalized alone |
 
 ## Constraints
 
-- 不凭记忆给版本敏感结论。
-- 不把过时教程当作当前最佳实践。
-- 不引用无法复核的来源作为关键依据。
-- 不为追新而改动稳定项目约定；必须说明收益和迁移成本。
-- 不在交付中复制长篇外部文档；只保留必要结论和链接或文件路径。
-- 不把“查过文档”停留在口头；版本敏感决策需要能追溯到具体版本、路径或官方页面。
+- Don't give version-sensitive conclusions from memory.
+- Do not treat outdated tutorials as current best practices.
+- Do not cite sources that cannot be reviewed as critical evidence.
+- Do not change the stable project agreement to pursue new developments; the benefits and migration costs must be explained.
+- Do not copy long external documents in the delivery; keep only necessary conclusions and links or file paths.
+- Don't just say "checked the documentation"; version-sensitive decisions need to be traceable to a specific version, path or official page.
 
 ## Expected Output
 
-输出来源清单、版本或项目事实、决策结论、实现影响、验证命令和未决风险。若修改代码，关键行为应有测试或构建验证支撑。
+Output source lists, version or project facts, decision conclusions, implementation impacts, validation orders, and open risks. If code is modified, key behaviors should be supported by tests or build verification.

package/skills/fec-state-management/SKILL.md

@@ -1,28 +1,28 @@
 ---
 name: fec-state-management
-description: Use when choosing, implementing, reviewing, or refactoring frontend state ownership across React, Vue, Next.js, Nuxt, URL state, server state, form state, browser persistence, or global stores. Prefer narrower skills for TanStack Query cache details, browser storage persistence, or form validation internals; Chinese triggers include 状态管理, 状态归属, store 选型.
+description: Use when choosing, implementing, reviewing, or refactoring frontend state ownership across React, Vue, Next.js, Nuxt, URL state, server state, form state, browser persistence, or global stores. Prefer narrower skills for TanStack Query cache details, browser storage persistence, or form validation internals; Chinese triggers include state management, state ownership, store selection.
 ---
 
-# 前端状态管理
+# Front-end status management
 
 ## Purpose
 
-为前端状态确定清晰归属，避免全局 store 膨胀、重复缓存和派生状态同步错误。
+Determine clear ownership of front-end state to avoid global store bloat, duplicate caching, and derived state synchronization errors.
 
 ## Procedure
 
-### 1. 先分类状态来源
+### 1. Classify status sources first
 
-不要先选 Redux、Zustand、Pinia 或 Context。先把每个状态标到唯一归属，再决定工具。
+Don't choose Redux, Zustand, Pinia or Context first. First mark each state to its unique owner, and then decide on the tool.
 
-| 状态类型         | 典型例子                             | 默认归属                 |
+| Status Type | Typical Example | Default Attribution |
 | ---------------- | ------------------------------------ | ------------------------ |
-| 本地 UI 状态     | 弹窗开关、tab、展开行、hover 编辑态  | 组件内 state / ref       |
-| 表单状态         | 输入值、脏字段、校验错误、提交中     | 表单库或表单组件         |
-| 服务端状态       | 列表、详情、分页结果、远程错误       | 请求缓存库               |
-| URL 状态         | 搜索词、筛选、排序、页码、选中 tab   | 路由参数 / search params |
-| 全局客户端状态   | 登录用户、主题、权限快照、购物车草稿 | 全局 store               |
-| 浏览器持久化状态 | 跨刷新保留的草稿、偏好、离线队列     | 存储层 + 状态适配器      |
+| Local UI state | Pop-up window switch, tab, expand row, hover editing state | In-component state / ref |
+| Form status | Input value, dirty field, validation error, submitting | Form library or form component |
+| Server status | List, details, paging results, remote errors | Request cache library |
+| URL status | Search terms, filter, sort, page number, selected tab | Routing parameters / search params |
+| Global client status | Login users, topics, permission snapshots, shopping cart drafts | Global store |
+| Browser persistent state | Drafts, preferences, offline queues retained across refreshes | Storage layer + state adapter |
 
 ```tsx
 type ReportsStateMap = {
@@ -34,9 +34,9 @@ type ReportsStateMap = {
 };
 ```
 
-### 2. 保持最小状态
+### 2. Keep it minimal
 
-可从 props、server state、URL 或已有 state 推导出来的值，不要另存一份。
+Do not save a new copy of a value that can be inferred from props, server state, URL, or existing state.
 
 ```tsx
 interface Invoice {
@@ -51,9 +51,9 @@ function InvoiceList({ invoices }: { invoices: Invoice[] }) {
 }
 ```
 
-### 3. 选择 React 全局状态方案
+### 3. Select the React global state solution
 
-React 中优先本地化和组合；只有跨页面、跨 feature 或需要统一动作时才引入全局 store。
+Priority is given to localization and combination in React; the global store is only introduced when cross-page, cross-feature or unified actions are required.
 
 ```tsx
 import { create } from "zustand";
@@ -69,17 +69,17 @@ export const useWorkspaceStore = create<WorkspaceState>((set) => ({
 }));
 ```
 
-决策顺序：
+Decision order:
 
-1. 只在一个组件或一个小子树使用：`useState` / `useReducer`。
-2. 低频全局配置或依赖注入：Context。
-3. 中等复杂业务状态：Zustand 或 Jotai，按仓库现有选型优先。
-4. 大型应用、严格动作流、审计或时间旅行调试：Redux Toolkit。
-5. 远程数据：使用数据获取 skill 管理 query key、缓存和失效策略。
+1. Use only in one component or a small subtree: `useState` / `useReducer`.
+2. Low-frequency global configuration or dependency injection: Context.
+3. Moderately complex business status: Zustand or Jotai, priority will be given based on the existing selection of the warehouse.
+4. Large applications, strict action flow, auditing or time travel debugging: Redux Toolkit.
+5. Remote data: Use the data acquisition skill to manage query keys, cache and invalidation policies.
 
-### 4. 选择 Vue 全局状态方案
+### 4. Select Vue global state solution
 
-Vue 3 中，局部跨层级传递使用 `provide/inject`；全局业务状态使用 Pinia 或项目既有 store。
+In Vue 3, use `provide/inject` for local cross-level transfer; use Pinia or the existing store of the project for global business status.
 
 ```ts
 import { computed, readonly, ref } from "vue";
@@ -101,9 +101,9 @@ export const useSessionStore = defineStore("session", () => {
 });
 ```
 
-### 5. 明确状态边界和迁移步骤
+### 5. Clarify status boundaries and migration steps
 
-重构状态时先做状态清单，再逐步移动读写入口。每一步都应保持行为可验证。
+When reconstructing the state, first make a state list, and then gradually move the read and write entries. Each step should keep the behavior verifiable.
 
 ```ts
 interface StateMigrationItem {
@@ -123,18 +123,18 @@ const migrationPlan: StateMigrationItem[] = [
 ];
 ```
 
-## 详细参考
+## Detailed reference
 
-需要 Store 形状示例、选择器模式、URL 状态同步、持久化适配器、SSR 边界或审查清单时，加载 [references/state-patterns.md](references/state-patterns.md)。
+Load [references/state-patterns.md](references/state-patterns.md) when you need Store shape examples, selector patterns, URL state synchronization, persistence adapters, SSR boundaries, or review checklists.
 
 ## Constraints
 
-- 不把服务端响应复制到全局 store；缓存、失效和重试归数据获取层。
-- 不把表单每个字段提升到全局 store；跨步骤共享也优先由表单上下文或提交草稿适配器处理。
-- 不用 Context 承载高频变化的大对象；会扩大重渲染范围。
-- 持久化状态必须明确字段白名单、版本号、过期策略和敏感数据排除。
-- SSR 场景不要在模块顶层创建带用户数据的单例 store。
+- Do not copy the server response to the global store; caching, invalidation and retries belong to the data acquisition layer.
+- Do not promote each field of the form to the global store; cross-step sharing is also handled first by the form context or submit draft adapter.
+- No need to use Context to carry large objects that change frequently; it will expand the re-rendering range.
+- Persistence state must specify field whitelist, version number, expiration policy and sensitive data exclusion.
+- In SSR scenarios, do not create a singleton store with user data at the top level of the module.
 
 ## Expected Output
 
-产出状态归属清单、选型理由、store/API 边界和验证步骤。实现时应保留 loading/error/empty、刷新、回退、跨路由和权限变化等关键行为。
+Output status attribution list, selection reasons, store/API boundaries and verification steps. Key behaviors such as loading/error/empty, refresh, rollback, cross-routing, and permission changes should be retained during implementation.

package/skills/fec-state-management/references/state-patterns.md

@@ -1,15 +1,15 @@
-# 状态管理模式
+#State management mode
 
-## 所有权审查清单
+## Ownership Review Checklist
 
-- 每个状态字段有唯一归属：本地状态、表单状态、服务端缓存、URL 状态、全局 Store 或浏览器持久化。
-- 派生值由源状态计算得出，而不是通过 effect 或 watcher 手动同步。
-- URL 状态用于可分享、刷新后需保留的视图状态，如筛选、搜索、排序和分页。
-- 服务端数据保留在请求缓存中；全局 Store 仅存放选中的 ID、本地偏好或乐观更新提示。
-- 持久化的客户端状态需有白名单、schema 版本号、迁移路径和敏感字段排除规则。
-- Store 的 action 以领域事件命名，而非组件处理器命名。
+- Each status field has a unique ownership: local status, form status, server-side cache, URL status, global Store or browser persistence.
+- Derived values are calculated from the source state rather than manually synchronized via effects or watchers.
+- URL state is used for view states that are shareable and need to be retained after refresh, such as filtering, searching, sorting, and paging.
+- Server-side data is kept in the request cache; the global Store only stores selected IDs, local preferences, or optimistic update prompts.
+- Persistent client state requires a whitelist, schema version number, migration path and sensitive field exclusion rules.
+- Store actions are named after domain events, not component processors.
 
-## React Store 形状示例
+## React Store shape example
 
 ```tsx
 import { create } from "zustand";
@@ -41,7 +41,7 @@ export const useCartStore = create<CartState>()(
 );
 ```
 
-选择器应尽可能返回稳定的原始值或经过 memo 的切片：
+Selectors should return stable raw values or memo-encoded slices whenever possible:
 
 ```tsx
 const itemCount = useCartStore((state) =>
@@ -49,9 +49,9 @@ const itemCount = useCartStore((state) =>
 );
 ```
 
-## URL 状态边界
+## URL status boundaries
 
-当另一个用户应能打开相同视图，或刷新后需要保留视图时，使用 URL 状态。
+Use URL state when another user should be able to open the same view, or when the view needs to be preserved after a refresh.
 
 ```tsx
 import { useSearchParams } from "react-router-dom";
@@ -72,9 +72,9 @@ export function useReportFilters() {
 }
 ```
 
-## 持久化适配器边界
+## Persistence adapter boundary
 
-仅持久化稳定的客户端偏好设置或非敏感草稿。序列化逻辑放在组件外部。
+Only persist stable client preferences or non-sensitive drafts. Serialization logic is placed outside the component.
 
 ```ts
 interface PersistedGridState {
@@ -101,9 +101,9 @@ export function writeGridState(state: PersistedGridState): void {
 }
 ```
 
-## SSR 与请求隔离
+## SSR is isolated from requests
 
-- 当状态可能包含用户数据时，每次请求需创建独立的 Store。
-- 服务端渲染期间不要读取 `window`、`localStorage` 或 `document`。
-- 水合后再加载持久化偏好，并在水合前提供确定性默认值。
-- 服务端缓存脱水与纯客户端全局 Store 分开处理。
+- When the state may contain user data, a separate Store needs to be created for each request.
+- Do not read `window`, `localStorage` or `document` during server rendering.
+- Reload persistence preferences after hydration and provide deterministic defaults before hydration.
+- Server-side cache dehydration is handled separately from pure client-side global Store.

package/skills/fec-storybook-component-doc/SKILL.md

@@ -1,37 +1,37 @@
 ---
 name: fec-storybook-component-doc
-description: Use when setting up or reviewing Storybook component documentation, design-system presentation, isolated component state previews, stories, addons, decorators, MDX docs, component-state interaction checks, visual baselines, or Chromatic. For real-browser cross-page journeys or broader coverage planning, choose the matching testing workflow first; Chinese triggers include Storybook, 组件文档, Design System, 视觉回归.
+description: Use when setting up or reviewing Storybook component documentation, design-system presentation, isolated component state previews, stories, addons, decorators, MDX docs, component-state interaction checks, visual baselines, or Chromatic. For real-browser cross-page journeys or broader coverage planning, choose the matching testing workflow first; Chinese triggers include Storybook, component documentation, Design System, visual regression.
 ---
 
-# Storybook 组件文档化
+# Storybook component documentation
 
 ## Purpose
 
-为 UI 组件建立文档化、设计系统展示和隔离状态预览环境；交互与视觉测试只覆盖 Storybook 场景内的组件状态。
+Establish documentation, design system display and isolated state preview environment for UI components; interaction and visual testing only cover component states within the Storybook scene.
 
 ## Procedure
 
-1. 初始化或识别现有 Storybook 配置，沿用项目框架适配器、stories glob、主题和构建命令。
-2. 每个组件的 Story 覆盖默认态、主要变体、尺寸、语义 tone、disabled、loading、error、empty、selected、invalid 和关键边缘状态。
-3. 依赖 Router、Store、i18n、ThemeProvider 的组件用 decorators 包裹，不在 Story 中复制应用入口。
-4. 复杂组件用 MDX 补充使用说明、Props、slots/children、variant 矩阵、状态示例、可访问性要求和源码展示。
-5. 需要自动化时接入 interaction tests、addon-a11y、Chromatic 或 Storybook Test Runner；这些能力服务于组件文档和设计系统展示，不承接跨页业务旅程。
-6. 设计系统组件应记录 token 来源、Tailwind/class 变体、暗色模式、响应式尺寸和不支持的组合，避免消费者靠猜测拼装。
+1. Initialize or identify an existing Storybook configuration, inheriting the project framework adapter, stories globs, themes, and build commands.
+2. Each component's Story covers default state, main variant, size, semantic tone, disabled, loading, error, empty, selected, invalid and key edge states.
+3. Components that rely on Router, Store, i18n, and ThemeProvider are wrapped with decorators and do not copy the application entry in Story.
+4. Use MDX to supplement complex components with usage instructions, Props, slots/children, variant matrices, status examples, accessibility requirements and source code display.
+5. When automation is required, connect interaction tests, addon-a11y, Chromatic or Storybook Test Runner; these capabilities serve component documentation and design system display and do not undertake cross-page business journeys.
+6. Design system components should record token sources, Tailwind/class variants, dark modes, responsive sizes, and unsupported combinations to avoid consumers guessing at assembly.
 
-## 详细参考
+## Detailed reference
 
-- 需要 `main.ts`、`preview.ts`、stories、decorators、MDX、交互测试和视觉回归示例时，加载 [references/story-patterns.md](references/story-patterns.md)。
+- Load [references/story-patterns.md](references/story-patterns.md) when you need `main.ts`, `preview.ts`, stories, decorators, MDX, interaction tests and visual regression examples.
 
 ## Constraints
 
-- Story 需随组件 prop 变更同步更新。
-- Provider 依赖必须通过 decorator 补齐。
-- Storybook 构建产物 `storybook-static/` 不应提交到 Git。
-- Storybook 用于开发和组件文档，不替代生产页面 SEO。
-- Storybook 视觉基线用于组件状态；跨页面截图和真实路由流程分流到 E2E workflow。
-- 大型组件库需控制 stories glob 和 addon 开销。
-- 不用 Storybook 隐藏组件 API 问题；若变体组合爆炸，应先收敛组件职责或拆分组件。
+- Story needs to be updated synchronously with component prop changes.
+- Provider dependencies must be completed through decorators.
+- Storybook build product `storybook-static/` should not be committed to Git.
+- Storybook is used for development and component documentation and is not a replacement for production page SEO.
+- Storybook visual baseline for component state; cross-page screenshots and real routing processes are offloaded to E2E workflow.
+- Large component libraries need to control stories glob and addon overhead.
+- Don’t use Storybook to hide component API issues; if variant combinations explode, you should first converge component responsibilities or split components.
 
 ## Expected Output
 
-可交互的组件文档和设计系统展示站点，每个组件状态都有隔离预览，Props 表格可生成，关键 Storybook 场景有可选 play 测试或视觉回归基线。
+Interactive component documentation and design system showcase site with isolated previews of each component state, Props tables to generate, and key Storybook scenes with optional play testing or visual regression baselines.

package/skills/fec-storybook-component-doc/references/story-patterns.md

@@ -1,6 +1,6 @@
-# Storybook 配置与示例
+# Storybook configuration and examples
 
-## 初始化
+## Initialization
 
 ```bash
 npx storybook@latest init
@@ -75,22 +75,22 @@ import * as InputStories from "./Input.stories";
 
 <Meta of={InputStories} />
 
-# Input 输入框
+#Input input box
 
-用于用户文本输入，支持校验提示、前后缀图标、字数统计等。
+Used for user text input, supporting verification prompts, suffix and suffix icons, word count, etc.
 
-### 何时使用
+### When to use
 
-- 单行文本输入
-- 需要实时校验反馈的表单字段
+- Single line text input
+- Form fields that require real-time verification feedback
 
 <Canvas of={InputStories.Default} />
 
-### 属性
+### Properties
 
 <Controls />
 
-### 源码
+### Source code
 
 <Source of={InputStories.Default} />
 ```
@@ -103,9 +103,9 @@ import { expect, userEvent, within } from "@storybook/test";
 export const FormSubmission: Story = {
   play: async ({ canvasElement }) => {
     const canvas = within(canvasElement);
-    await userEvent.type(canvas.getByLabelText("用户名"), "admin");
-    await userEvent.click(canvas.getByRole("button", { name: /登录/ }));
-    await expect(canvas.findByText("登录成功")).resolves.toBeInTheDocument();
+await userEvent.type(canvas.getByLabelText("username"), "admin");
+    await userEvent.click(canvas.getByRole("button", { name: /login/ }));
+    await expect(canvas.findByText("Login successful")).resolves.toBeInTheDocument();
   },
 };
 ```

package/skills/fec-svg-animation/SKILL.md

@@ -1,38 +1,38 @@
 ---
 name: fec-svg-animation
-description: Use when implementing or reviewing SVG animation, path drawing, icon motion, logo animation, illustration motion, micro-interactions, CSS/SMIL/Framer Motion/GSAP choices, motion accessibility, or fallback behavior; Chinese triggers include SVG 动画, 路径描边, 动效.
+description: Use when implementing or reviewing SVG animation, path drawing, icon motion, logo animation, illustration motion, micro-interactions, CSS/SMIL/Framer Motion/GSAP choices, motion accessibility, or fallback behavior; Chinese triggers include SVG animation, path stroke, animation.
 ---
 
-# SVG 动画实现
+# SVG animation implementation
 
 ## Purpose
 
-为 SVG 图标、插画和数据可视化提供可维护、可访问、性能可控的动画方案。
+Provide maintainable, accessible, and performance-controllable animation solutions for SVG icons, illustrations, and data visualizations.
 
 ## When to Use
 
-- 需要实现 SVG 图标、Logo、插画或路径描边动画。
-- 需要在 React/Vue 组件中接入 Framer Motion、GSAP 或 CSS 动画。
-- 需要根据 `prefers-reduced-motion` 提供动效降级。
-- 不用于复杂 3D/WebGL 场景；此类场景优先使用 Canvas / Three.js workflow。
+- SVG icon, logo, illustration or path stroke animation needs to be implemented.
+- Framer Motion, GSAP or CSS animation needs to be connected to React/Vue components.
+- Need to provide motion reduction according to `prefers-reduced-motion`.
+- Not used for complex 3D/WebGL scenes; for such scenes, Canvas / Three.js workflow is preferred.
 
 ## Procedure
 
-### 1. 选择动画方式
+### 1. Select animation mode
 
-按复杂度和运行时需求选型：
+Choose based on complexity and runtime requirements:
 
-| 场景 | 推荐 |
+| Scenario | Recommendation |
 | --- | --- |
 | hover/focus、opacity、transform | CSS animation/transition |
-| 路径描边、简单重复动效 | CSS + `stroke-dasharray` |
-| React 组件状态驱动动画 | Framer Motion |
-| 时间轴、复杂编排、滚动触发 | GSAP |
-| 需要保持零依赖的静态 SVG | CSS 或 SMIL |
+| Path stroke, simple repeating animation | CSS + `stroke-dasharray` |
+| React component state-driven animation | Framer Motion |
+| Timeline, complex arrangement, scrolling trigger | GSAP |
+| Need to keep static SVG with zero dependencies | CSS or SMIL |
 
-如果动效跨越页面转场、滚动叙事或复杂组件编排，应先按交互动效 workflow 判断强度、懒加载和 reduced-motion 策略；本 skill 只负责 SVG 图形本身的路径、形变和图标 motion。
+If the animation spans page transitions, scrolling narratives, or complex component arrangements, you should first judge the intensity, lazy loading, and reduced-motion strategies according to the interactive effects workflow; this skill is only responsible for the path, deformation, and icon motion of the SVG graphics themselves.
 
-### 2. 使用 CSS 实现路径描边
+### 2. Use CSS to implement path strokes
 
 ```tsx
 export function CheckmarkIcon() {
@@ -73,7 +73,7 @@ export function CheckmarkIcon() {
 }
 ```
 
-### 3. 在 React 中使用 Framer Motion
+### 3. Using Framer Motion in React
 
 ```tsx
 import { motion, useReducedMotion } from "framer-motion";
@@ -82,7 +82,7 @@ export function AnimatedSparkline({ path }: { path: string }) {
   const reduceMotion = useReducedMotion();
 
   return (
-    <svg viewBox="0 0 120 40" role="img" aria-label="趋势图">
+    <svg viewBox="0 0 120 40" role="img" aria-label="Trend Chart">
       <motion.path
         d={path}
         fill="none"
@@ -97,7 +97,7 @@ export function AnimatedSparkline({ path }: { path: string }) {
 }
 ```
 
-### 4. 使用 GSAP 编排复杂时间轴
+### 4. Use GSAP to orchestrate complex timelines
 
 ```tsx
 import { useLayoutEffect, useRef } from "react";
@@ -126,23 +126,23 @@ export function LogoReveal() {
 }
 ```
 
-### 5. 控制运行成本
+### 5. Control operating costs
 
-- 大型 SVG 拆成静态底图和少量可动画节点，不要让每个 path 都参与时间轴。
-- 图标库或 Lottie 替代方案必须按需加载，不进入所有页面的基础包。
-- 循环动画只在可见区域运行，页面隐藏或组件卸载时停止。
-- 移动端减少滤镜、mask、clipPath 和大量渐变叠加。
+- Split large SVG into static basemaps and a small number of animatable nodes. Do not let each path participate in the timeline.
+- Icon libraries or Lottie alternatives must be loaded on demand, without going into the base package for all pages.
+- The loop animation only runs in the visible area and stops when the page is hidden or the component is unloaded.
+- The mobile version reduces filters, masks, clipPaths and a large number of gradient overlays.
 
 ## Constraints
 
-- 优先动画 `transform`、`opacity` 和 SVG 路径属性；避免高频修改 layout 相关属性。
-- 交互控件必须保留可见 focus 状态，动画不能替代状态表达。
-- 所有非装饰性 SVG 必须有可访问名称；装饰性 SVG 使用 `aria-hidden="true"`。
-- 默认尊重 `prefers-reduced-motion`，复杂动效必须提供静态或弱动效降级。
-- 不要把大型 SVG 内联到频繁重渲染的组件中；提取为 memoized 组件或外部资源。
-- 不用动画改变可点击区域、阅读顺序或焦点位置。
-- 不让 SVG 滤镜、模糊、mask 或 clipPath 成为移动端掉帧主因；复杂效果需要设备降级。
+- Prioritize animation `transform`, `opacity` and SVG path attributes; avoid frequent modification of layout-related attributes.
+- Interactive controls must retain the visible focus state, and animation cannot replace state expression.
+- All non-decorative SVGs must have accessible names; decorative SVGs use `aria-hidden="true"`.
+- Default respects `prefers-reduced-motion`, complex animations must provide static or weak motion degradation.
+- Don't inline large SVGs into frequently re-rendered components; extract as memoized components or external resources.
+- Change clickable area, reading order or focus position without animation.
+- Don't let SVG filters, blur, mask or clipPath become the main cause of frame drops on mobile devices; complex effects require device downgrading.
 
 ## Expected Output
 
-产出一个可复用的 SVG 动画组件或样式方案，包含选型理由、动效降级和可访问性处理。验证时检查动画流畅、无布局抖动、键盘与 reduced-motion 场景可用。
+Produce a reusable SVG animation component or style solution, including selection reasons, animation degradation and accessibility processing. During verification, check that the animation is smooth, there is no layout jitter, and keyboard and reduced-motion scenes are available.