@bovinphang/frontend-craft 2.7.0 → 2.9.0

package/skills/fec-react-project-standard/SKILL.md

@@ -1,91 +1,91 @@
 ---
 name: fec-react-project-standard
-description: Use when designing or reviewing React + TypeScript project structure, feature/module boundaries, component architecture, hooks organization, routing composition, state/API/error/styling defaults, or repository-wide React conventions. Prefer narrower skills for forms, data fetching, tests, accessibility, virtualization, animation, or security deep dives; Chinese triggers include React 项目规范, React 组件架构.
+description: Use when designing or reviewing React + TypeScript project structure, feature/module boundaries, component architecture, hooks organization, routing composition, state/API/error/styling defaults, or repository-wide React conventions. Prefer narrower skills for forms, data fetching, tests, accessibility, virtualization, animation, or security deep dives; Chinese triggers include React project specification, React component architecture.
 ---
 
-# React 项目规范
+# React project specifications
 
-适用于 React + TypeScript 仓库中的中大型模块建设、页面重构和工程结构设计。
+Suitable for medium and large module construction, page reconstruction and engineering structure design in React + TypeScript warehouse.
 
 ## Purpose
 
-为 React + TypeScript 项目提供工程结构、模块边界和默认实现约定，确保架构清晰、代码可维护。
+Provide engineering structure, module boundaries and default implementation conventions for React + TypeScript projects to ensure clear architecture and maintainable code.
 
 ## Procedure
 
-本 skill 主要解决 React 工程任务“如何设计和落地”的问题，不重复声明基础编码底线。处理 React 工程化任务时，按以下顺序执行：
-
-1. 识别仓库已有约定
-   - 目录组织方式
-   - 样式体系
-   - 状态管理方案
-   - 请求封装方式
-   - 测试框架
-   - UI 组件库 / 设计系统
-
-2. 判断目标属于哪一层
-   - 路由页面
-   - 页面私有组件
-   - feature 业务模块
-   - 全局通用组件
+This skill mainly solves the problem of "how to design and implement" React engineering tasks, without repeating the basic coding bottom line. When handling React engineering tasks, perform them in the following order:
+
+1. Identify the warehouse and have an agreement
+   - Directory organization
+   - Style system
+   - Status management solution
+   - Request packaging method
+   - Testing framework
+   - UI component library/design system
+
+2. Determine which layer the target belongs to
+   - Routing page
+   -Page private components
+   - feature business module
+   - Global common components
    - hooks / services / stores / utils
 
-3. 设计边界后再落代码
-   - 哪些逻辑属于页面编排
-   - 哪些逻辑属于 feature
-   - 哪些逻辑应下沉为通用能力
-   - 哪些状态应本地管理，哪些应交给 store / query / URL
-   - 状态归属复杂时使用状态管理流程先做状态清单
-   - DTO、公共 props、泛型组件或 `tsconfig` 边界复杂时，先使用 TypeScript 项目规范流程收敛跨框架类型契约
-
-4. 输出时补齐关键质量项
-   - loading / error / empty / data 状态
-   - 错误处理与重试
-   - 类型约束
-   - 关键测试入口
-   - 必要的专项 skill 分流
-   - 依赖是否已存在于 `package.json`，缺失时先给安装命令再使用
-   - 重型 UI 能力（动效、图表、3D、编辑器、地图）是否隔离为 leaf component 并按需加载
-   - 图片、视频、字体等资源是否本地化、可缓存，并避免占位 URL 进入交付
-   - 页面级 Error Boundary、模块级 fallback、API 错误映射和用户可恢复动作是否一致
-   - Tailwind token/variant 或响应式布局需求是否应分流到对应专项 skill
-   - 对明显架构性能风险做轻量筛查，如重型依赖边界、过宽 Context、高频派生值和懒加载 fallback；需要指标证据时进入性能优化 workflow
-
-## 详细参考
-
-按需要加载更细的参考文件：
-
-- 项目目录、组件分层、组件边界和组件目录建议：加载 [references/react-project-structure.md](references/react-project-structure.md)。
-- 组件模式、Hooks、路由、状态归属、API 层、错误处理和 Suspense/懒加载：加载 [references/react-runtime-patterns.md](references/react-runtime-patterns.md)。
-- 样式、注释、TypeScript、测试、反模式和输出检查清单：加载 [references/react-quality-patterns.md](references/react-quality-patterns.md)。
-- React 项目规范层面的轻量性能约定：加载 [references/react-performance-patterns.md](references/react-performance-patterns.md)。
+3. Design the boundaries before writing the code
+   - What logic belongs to page layout
+   - Which logic belongs to feature
+   - Which logic should be transferred to general capabilities?
+   - Which state should be managed locally and which should be handed over to store/query/URL
+   - When the status ownership is complex, use the status management process to make a status list first
+   - When the boundaries of DTO, public props, generic components or `tsconfig` are complex, first use the TypeScript project specification process to converge cross-framework type contracts
+
+4. Complete key quality items when outputting
+   - loading / error / empty / data status
+   - Error handling and retrying
+   - Type constraints
+   - Key test entrance
+   - Diversion of necessary special skills
+   - Check whether the dependency already exists in `package.json`. If it is missing, give the installation command first and then use it.
+   - Whether heavy UI capabilities (animation, charts, 3D, editors, maps) are isolated as leaf components and loaded on demand
+   - Whether images, videos, fonts and other resources are localized and cacheable, and avoid placeholder URLs from entering delivery
+   - Whether page-level Error Boundary, module-level fallback, API error mapping and user-recoverable actions are consistent
+   - Whether Tailwind token/variant or responsive layout requirements should be diverted to the corresponding special skill
+- Perform lightweight screening for obvious architectural performance risks, such as heavy dependency boundaries, too wide Context, high-frequency derived values and lazy loading fallback; enter the performance optimization workflow when indicator evidence is needed
+
+## Detailed reference
+
+Load more detailed reference files as needed:
+
+- Project Directory, Component Hierarchy, Component Boundary and Component Directory Recommendations: Load [references/react-project-structure.md](references/react-project-structure.md).
+- Component pattern, Hooks, routing, state ownership, API layer, error handling and Suspense/lazy loading: Load [references/react-runtime-patterns.md](references/react-runtime-patterns.md).
+- Style, annotations, TypeScript, tests, anti-patterns and output checklist: Loading [references/react-quality-patterns.md](references/react-quality-patterns.md).
+- Lightweight performance conventions at the React project specification level: Load [references/react-performance-patterns.md](references/react-performance-patterns.md).
 
 ## Constraints
 
-- 默认遵守仓库现有全局规则和 React rule
-- 若仓库已有明确目录结构、样式体系、状态管理或请求封装，优先沿用仓库约定
-- 组件文件规模宜约 **300 行**内；逾 **500 行**或复杂度过高须拆分子组件、Hooks、utils、类型
-- 禁止新增类组件（Error Boundary 用 `react-error-boundary` 等库）
-- 禁止绕过模块出口，从 feature 深层路径导入
-- 不要用 `useEffect + setState` 模拟本可直接计算的派生值
-- 避免 prop drilling 过深却不考虑组合或局部封装
-- 不在通用页面组件里同步引入 GSAP、Three.js、Lottie、富文本编辑器或地图 SDK；需要时用动态导入、路由级分包或叶子组件隔离。
-- 不在 React 组件中散落裸 `fetch`、API URL、token refresh 或上传流程；跨边界请求应收敛到 API 集成层。
-- 不用 Error Boundary 处理普通 API 失败；请求错误应优先落到 loading/error/empty/data 状态和可恢复操作。
-- 不把 React 性能建议写成无证据的全局 memo 化；先定位请求瀑布、bundle 边界、重复渲染或 effect 误用。
+- Comply with the existing global rules and React rules of the warehouse by default
+- If the warehouse already has a clear directory structure, style system, status management or request encapsulation, the warehouse convention will be used first.
+- The size of the component file should be approximately **300 lines**; if it exceeds **500 lines** or is too complex, it must be split into sub-components, Hooks, utils, and types.
+- It is forbidden to add new class components (Error Boundary uses libraries such as `react-error-boundary`)
+- Disable bypassing module exports and importing from feature deep paths
+- Do not use `useEffect + setState` to simulate derived values that can be calculated directly
+- Avoid prop drilling too deep without considering composition or partial encapsulation
+- Do not synchronously introduce GSAP, Three.js, Lottie, rich text editor or map SDK into common page components; use dynamic import, route-level subcontracting or leaf component isolation when necessary.
+- No bare `fetch`, API URL, token refresh or upload processes scattered around React components; cross-border requests should be converged to the API integration layer.
+- Do not use Error Boundary to handle normal API failures; request errors should first fall into the loading/error/empty/data state and recoverable operations.
+- Do not write React performance recommendations as global memo without evidence; first locate request waterfall, bundle boundaries, repeated rendering or effect misuse.
 
 ## Expected Output
 
-- 组件边界清晰，pages/features/components 分层明确
-- Props 类型完整且明确；复杂公共类型或外部数据收窄已分流到 TypeScript 项目规范流程
-- 可复用逻辑已提取为 hooks，loading/error/empty/data 状态齐全
-- API 层具备类型约束和统一错误处理，状态管理符合就近原则
-- URL 状态、服务端状态、表单状态和全局客户端状态边界明确
-- 关键行为有测试覆盖，关键模块已用 `react-error-boundary` 包裹
-- 超长列表已评估虚拟化，弹窗/复合组件具备键盘与焦点支持
-- 先尊重仓库现状，再给推荐结构
-- 给出必要的文件划分建议
-- 必要时说明为什么这样分层
-- 对新增模块，优先输出最小可落地结构，而不是一次性过度设计
-- 对重构任务，优先保证可迁移性和风险可控
-- 对性能相关 React 变更，说明触发的风险类别、证据来源和验证命令
+- Component boundaries are clear, pages/features/components are clearly layered
+- The Props type is complete and clear; the narrowing of complex public types or external data has been diverted to the TypeScript project specification process
+- Reusable logic has been extracted into hooks, and the loading/error/empty/data status is complete
+- The API layer has type constraints and unified error handling, and status management conforms to the proximity principle
+- URL status, server status, form status and global client status have clear boundaries
+- Key behaviors are covered by tests, and key modules have been wrapped with `react-error-boundary`
+- The long list has been evaluated for virtualization, and pop-up/composite components have keyboard and focus support
+- Respect the current situation of the warehouse first, and then recommend the structure
+- Give necessary suggestions for file division
+- Explain why this is layered if necessary
+- For new modules, give priority to outputting the smallest floor-mountable structure rather than over-designing it all at once
+- For reconstruction tasks, give priority to ensuring portability and risk controllability
+- For performance-related React changes, describe the triggered risk categories, evidence sources, and verification commands

package/skills/fec-react-project-standard/references/react-performance-patterns.md

@@ -2,34 +2,34 @@
 
 This file keeps lightweight React project-standard performance guidance. Use the frontend performance workflow when the task needs metrics, traces, profiles, bundle analysis, network evidence, or a formal performance report.
 
-### 性能（与「性能优化」一节配合）
-
-- **useMemo**：昂贵派生、大列表排序/过滤；注意不可变数据，例如 `useMemo(() => [...list].sort(...), [list])`，避免直接 `sort` 可变原数组。
-- **useCallback**：传给 **`React.memo`** 子组件或作为其他 Hook 依赖的回调，在确有稳定引用需求时使用。
-- **React.memo**：纯展示、props 浅比较可接受的组件；不要全局套 memo。
-- **虚拟列表**：超长列表用 **TanStack Virtual**、**react-window** 等，只渲染视区内节点（路由级与组件级懒加载仍见「Suspense 与懒加载」）。
-
-## 性能优化
-
-在以下场景考虑性能优化：
-
-- 大列表 / 大表格
-- 高频重渲染组件
-- 大量 props 传递的复杂树
-- 重型第三方组件
-- 高频变化 context
-
-### 推荐手段
-
-- 合理使用 `React.memo`
-- 只在必要时使用 `useMemo` / `useCallback`
-- 列表使用稳定 `key`
-- 大列表使用虚拟滚动
-- 路由级做 code splitting
-- 避免将高频变化值放进顶层 context
-- 避免在 render 中无意义创建大量新对象 / 新函数 / 新数组
-- 重型图表、编辑器、地图、3D 和媒体处理能力放到叶子组件或路由级懒加载边界
-- 懒加载组件必须配套 loading、error、empty 或降级 UI，避免只优化包体却破坏用户状态
+### Performance (in conjunction with the "Performance Optimization" section)
+
+- **useMemo**: Expensive derivation, large list sorting/filtering; pay attention to immutable data, such as `useMemo(() => [...list].sort(...), [list])`, and avoid directly `sort` the mutable original array.
+- **useCallback**: passed to **`React.memo`** sub-component or used as a callback for other Hook dependencies, used when there is a stable reference requirement.
+- **React.memo**: An acceptable component with pure display and shallow props; do not apply memo globally.
+- **Virtual List**: For very long lists, use **TanStack Virtual**, **react-window**, etc., and only render nodes in the viewport (see "Suspense and Lazy Loading" for routing-level and component-level lazy loading).
+
+## Performance optimization
+
+Consider performance optimization in the following scenarios:
+
+- Large list/large table
+- High frequency re-rendering components
+- Complex trees passed with a large number of props
+- Heavy-duty third-party components
+- High frequency changing context
+
+### Recommended means
+
+- Use `React.memo` appropriately
+- Use `useMemo` / `useCallback` only when necessary
+- List uses stable `key`
+- Use virtual scrolling for large lists
+- Code splitting at routing level
+- Avoid putting high-frequency changing values into the top-level context
+- Avoid meaninglessly creating a large number of new objects/new functions/new arrays in render
+- Heavy charting, editor, map, 3D and media processing capabilities into leaf components or route-level lazy loading boundaries
+- Lazy loading components must be equipped with loading, error, empty or downgraded UI to avoid only optimizing the package body but destroying the user state
 
 ---
 

package/skills/fec-react-project-standard/references/react-project-structure.md

@@ -1,177 +1,177 @@
 # React project structure and component boundaries
 
-## 项目结构（推荐参考）
+## Project structure (recommended reference)
 
-以下为中大型 React 项目的业界最佳实践结构，按项目实际情况裁剪：
+The following is the industry's best practice structure for medium and large React projects, tailored according to the actual situation of the project:
 
 ```text
 src/
-├── app/                        # 应用入口与全局配置
-│   ├── App.tsx                 # 根组件（Provider 组合）
-│   ├── routes.tsx              # 路由配置
-│   └── providers.tsx           # 全局 Provider 组装
+├── app/ # Application entry and global configuration
+│ ├── App.tsx # Root component (Provider combination)
+│ ├── routes.tsx # Routing configuration
+│ └── providers.tsx # Global Provider assembly
 │
-├── pages/                      # 页面组件（与路由一一对应）
+├── pages/ # Page components (one-to-one correspondence with routing)
 │   ├── Dashboard/
 │   │   ├── DashboardPage.tsx
-│   │   ├── components/         # 页面私有组件
-│   │   └── hooks/              # 页面私有 hooks
+│ │ ├── components/ # Page private components
+│ │ └── hooks/ # Page private hooks
 │   ├── UserList/
 │   └── Settings/
 │
-├── layouts/                    # 布局组件
-│   ├── MainLayout.tsx          # 主布局（侧边栏 + 顶栏 + 内容区）
-│   ├── AuthLayout.tsx          # 登录/注册页布局
-│   └── BlankLayout.tsx         # 空白布局（错误页等）
+├── layouts/ # Layout component
+│ ├── MainLayout.tsx # Main layout (sidebar + top bar + content area)
+│ ├── AuthLayout.tsx # Login/registration page layout
+│ └── BlankLayout.tsx # Blank layout (error page, etc.)
 │
-├── features/                   # 功能模块（按业务领域划分）
+├── features/ # Function modules (divided by business areas)
 │   ├── auth/
-│   │   ├── components/         # 模块组件
-│   │   ├── hooks/              # 模块 hooks
-│   │   ├── api.ts              # 模块 API 调用
-│   │   ├── types.ts            # 模块类型定义
-│   │   ├── constants.ts        # 模块常量
-│   │   └── index.ts            # 模块公开导出
+│ │ ├── components/ # Module components
+│ │ ├── hooks/ # module hooks
+│ │ ├── api.ts # Module API call
+│ │ ├── types.ts # Module type definition
+│ │ ├── constants.ts # Module constants
+│ │ └── index.ts # Module publicly exported
 │   └── order/
 │
-├── components/                 # 全局共享 UI 组件
+├── components/ # Globally shared UI components
 │   ├── Button/
 │   │   ├── Button.tsx
 │   │   ├── Button.styles.css
 │   │   └── __tests__/
 │   ├── Modal/
 │   ├── Form/
-│   └── ErrorBoundary/          # 对 react-error-boundary 等的薄封装（函数组件）
+│ └── ErrorBoundary/ # Thin wrapper (function component) for react-error-boundary etc.
 │
-├── hooks/                      # 全局共享 hooks
+├── hooks/ # Global shared hooks
 │   ├── useAuth.ts
 │   ├── useDebounce.ts
 │   └── useMediaQuery.ts
 │
-├── services/                   # API 基础层
-│   ├── request.ts              # Axios/fetch 实例与拦截器
-│   └── endpoints/              # API 端点定义（如按领域拆分）
+├── services/ # API base layer
+│ ├── request.ts # Axios/fetch instance and interceptor
+│ └── endpoints/ # API endpoint definition (such as split by field)
 │
-├── stores/                     # 全局状态管理
+├── stores/ # Global status management
 │   ├── authStore.ts
 │   └── uiStore.ts
 │
-├── locales/                    # 国际化语言包
-│   ├── zh-CN.json              # 中文
-│   ├── en-US.json              # 英文
-│   └── index.ts                # i18n 实例初始化（i18next / react-intl）
+├── locales/ # International language pack
+│ ├── zh-CN.json # Simplified Chinese
+│ ├── en-US.json # English
+│ └── index.ts # i18n instance initialization (i18next / react-intl)
 │
-├── assets/                     # 静态资源
-│   ├── images/                 # 图片（PNG、JPG、WebP）
-│   ├── icons/                  # SVG 图标
-│   └── fonts/                  # 自定义字体
+├── assets/ # Static resources
+│ ├── images/ # Pictures (PNG, JPG, WebP)
+│ ├── icons/ # SVG icon
+│ └── fonts/ # Custom fonts
 │
-├── config/                     # 应用配置
-│   ├── env.ts                  # 环境变量类型化封装
-│   └── features.ts             # Feature Flags 管理
+├── config/ # Application configuration
+│ ├── env.ts # Typed encapsulation of environment variables
+│ └── features.ts # Feature Flags Management
 │
-├── types/                      # 全局共享类型
-│   ├── api.ts                  # API 响应/请求通用类型
-│   ├── models.ts               # 业务实体类型
-│   └── global.d.ts             # 全局类型扩展（图片模块声明等）
+├── types/ # Global shared types
+│ ├── api.ts # API response/request common type
+│ ├── models.ts #Business entity type
+│ └── global.d.ts # Global type extension (picture module declaration, etc.)
 │
-├── utils/                      # 纯工具函数
-│   ├── format.ts               # 日期、数字、货币格式化
-│   ├── validators.ts           # 表单校验规则
-│   └── storage.ts              # LocalStorage / SessionStorage 封装
+├── utils/ # Pure utility function
+│ ├── format.ts # Date, number, currency formatting
+│ ├── validators.ts # Form validation rules
+│ └── storage.ts # LocalStorage / SessionStorage package
 │
-├── styles/                     # 全局样式与主题
-│   ├── global.css              # 全局基础样式（reset / normalize）
-│   ├── variables.css           # CSS 变量（颜色、间距、字号）
-│   ├── breakpoints.ts          # 响应式断点常量
-│   └── themes/                 # 主题定义
-│       ├── light.css           # 亮色主题变量
-│       ├── dark.css            # 暗色主题变量
-│       └── index.ts            # 主题切换逻辑
+├── styles/ # Global styles and themes
+│ ├── global.css # Global basic style (reset/normalize)
+│ ├── variables.css # CSS variables (color, spacing, font size)
+│ ├── breakpoints.ts # Responsive breakpoint constants
+│ └── themes/ # theme definition
+│ ├── light.css # Light theme variable
+│ ├── dark.css # Dark theme variable
+│ └── index.ts # theme switching logic
 │
-└── constants/                  # 全局常量
-    ├── routes.ts               # 路由路径常量
-    └── config.ts               # 业务常量（分页大小、超时时间等）
+└── constants/ # Global constants
+    ├── routes.ts #Routing path constants
+    └── config.ts #Business constants (paging size, timeout, etc.)
 ```
 
-### 关键原则
+### Key Principles
 
-- `pages/` 做路由映射和页面编排，不承载大块可复用业务逻辑
-- `layouts/` 负责页面骨架和布局容器，由路由配置引用
-- `features/` 按业务领域划分，模块内尽量自包含
-- `components/` 仅放跨页面、跨模块复用的通用组件
-- `hooks/` 仅放全局通用 hooks；业务 hooks 优先放回对应 feature 或 page
-- `locales/` 存放语言包 JSON 文件，组件中使用 `t('key')` 而非硬编码文案
-- `assets/` 存放静态资源，图标优先使用 SVG，图片优先使用 WebP/AVIF
-- `services/` 负责请求基础设施，不堆叠业务细节
-- `config/` 统一封装环境变量和特性开关，禁止组件中直接读取 `import.meta.env`
-- `styles/` 和主题变量统一管理，避免颜色和尺寸散落在业务代码中
-- 每个模块通过 `index.ts` 管控对外公开 API，避免深层路径导入
+- `pages/` does route mapping and page arrangement, and does not carry large pieces of reusable business logic.
+- `layouts/` is responsible for the page skeleton and layout container, referenced by the routing configuration
+- `features/` is divided according to business areas, and the module should be as self-contained as possible
+- `components/` only contains common components that are reused across pages and modules
+- `hooks/` only puts global general hooks; business hooks are put back to the corresponding feature or page first
+- `locales/` stores language pack JSON files, use `t('key')` in the component instead of hard-coded copy
+- `assets/` stores static resources, SVG is preferred for icons, and WebP/AVIF is preferred for images.
+- `services/` is responsible for requesting infrastructure and does not stack business details
+- `config/` uniformly encapsulates environment variables and feature switches, prohibiting direct reading of `import.meta.env` in components
+- `styles/` and theme variables are managed uniformly to avoid colors and sizes being scattered in business code
+- Each module controls the public API through `index.ts` to avoid deep path imports
 
 ---
 
-## 组件与模块分层
+## Component and module layering
 
-推荐分层：
+Recommended layering:
 
 ```text
-页面组件 (Pages)        → 路由映射、布局组合、页面编排
-  └── 容器/编排层        → 数据获取、状态组织、事件编排
-       └── 业务组件      → 领域逻辑展示
-            └── 通用组件 → 无业务耦合、可跨模块复用
+Page components (Pages) → route mapping, layout combination, page arrangement
+  └── Container/orchestration layer → data acquisition, status organization, event orchestration
+       └── Business components → Domain logic display
+            └── Common components → No business coupling, reusable across modules
 ```
 
-### 什么时候放到 `pages/`
+### When to put it in `pages/`
 
-适合放：
+Suitable for:
 
-- 路由入口组件
-- 页面级布局组合
-- 页面私有的轻量编排逻辑
+- Routing entry component
+- Page level layout combination
+- Page private lightweight orchestration logic
 
-不适合放：
+Not suitable for:
 
-- 大量领域逻辑
-- 可复用于多个页面的复杂业务块
-- 与某个业务域强绑定的 API / hooks / types
+- A lot of domain logic
+- Complex business blocks that can be reused on multiple pages
+- API/hooks/types that are strongly bound to a certain business domain
 
-### 什么时候放到 `features/`
+### When to put it in `features/`
 
-适合放：
+Suitable for:
 
-- 某个业务域的组件、hooks、api、types
-- 可被多个页面共享但带业务语义的逻辑
-- 一个完整业务单元的自包含实现
+- Components, hooks, apis, and types of a certain business domain
+- Logic that can be shared by multiple pages but has business semantics
+- Self-contained implementation of a complete business unit
 
-### 什么时候放到 `components/`
+### When to put it in `components/`
 
-适合放：
+Suitable for:
 
-- 按钮、弹窗、表单项、表格壳子、空态、错误态等通用 UI
-- 与具体业务无关、可跨模块复用的组件
+- Common UI such as buttons, pop-up windows, form items, table shells, empty states, error states, etc.
+- Components that have nothing to do with specific business and can be reused across modules
 
 ---
 
-## 组件设计规范
+## Component design specifications
 
-- 使用**函数组件**、Hooks 与 TypeScript；**不要**新增类组件（Error Boundary 用 `react-error-boundary` 等库，见下文）
-- **单文件规模**与拆分原则见 `templates/shared/rules/fec-react.md`「**组件文件规模**」（约 300 行内为佳，逾 500 行或复杂度过高拆子组件、Hooks、utils、类型）
-- 保持组件职责单一、可组合
-- 将可复用逻辑提取到 hooks
-- 在合适场景优先使用受控组件 API
-- props 定义清晰且类型明确
-- 优先复用现有设计系统组件
-- 保持可访问性与键盘交互
-- 避免过深的 JSX 嵌套和重复分支
-- 对可推导的值不要额外存 state
+- Use **Functional Components**, Hooks and TypeScript; **Do not** add new class components (Error Boundary uses libraries such as `react-error-boundary`, see below)
+- **Single file size** and splitting principles can be found in `templates/shared/rules/fec-react.md` "**Component file size**" (approximately 300 lines is preferred, if it exceeds 500 lines or is too complex, sub-components, Hooks, utils, and types will be split)
+- Keep components with single responsibilities and composable
+- Extract reusable logic into hooks
+- Prioritize the use of controlled component APIs in appropriate scenarios
+- props are clearly defined and typed
+- Prioritize reuse of existing design system components
+- Maintain accessibility with keyboard interaction
+- Avoid deep JSX nesting and duplicate branches
+- Do not store additional state for deducible values
 
 ---
 
 
-## 组件目录建议
+## Component directory suggestions
 
-当组件复杂度较低时，可只保留一个文件。  
-当组件包含样式、子组件、hooks、测试时，推荐使用如下结构：
+When the component complexity is low, only one file can be kept.  
+When a component contains styles, subcomponents, hooks, and tests, it is recommended to use the following structure:
 
 ```text
 ComponentName/
@@ -186,12 +186,12 @@ ComponentName/
     └── ComponentName.spec.tsx
 ```
 
-说明：
+Description:
 
-- 类型复杂时再拆 `ComponentName.types.ts`
-- 存在局部逻辑复用时再拆 `hooks/`
-- 子组件仅在当前组件内部使用时，放到当前目录 `components/`
-- 测试是否就近放置，应遵循仓库现有约定
+- Split `ComponentName.types.ts` when the type is complex
+- Split `hooks/` when there is local logic reuse
+- When the subcomponent is only used inside the current component, it is placed in the current directory `components/`
+- Whether the test should be placed nearby should follow the existing protocols of the warehouse
 
 ---