@bovinphang/frontend-craft 2.6.0 → 2.8.0

package/skills/fec-performance-optimization/SKILL.md

@@ -1,76 +1,80 @@
 ---
 name: fec-performance-optimization
-description: Use when diagnosing or improving frontend performance, Core Web Vitals, bundle size, runtime rendering cost, network waterfalls, memory leaks, long tasks, Lighthouse findings, or performance budgets; Chinese triggers include 性能优化, 页面卡顿, 首屏慢, 包体积, Web Vitals.
+description: Use when diagnosing or improving frontend performance, Core Web Vitals, bundle size, runtime rendering cost, network waterfalls, memory leaks, long tasks, Lighthouse findings, or performance budgets; Chinese triggers include performance optimization, page freeze, slow first screen, bundle volume, Web Vitals.
 ---
 
-# 前端性能优化
+# Front-end performance optimization
 
 ## Purpose
 
-用可度量的方式定位前端性能瓶颈，并把优化建议收敛到用户主路径、构建产物和运行时证据。
+Use measurable methods to locate front-end performance bottlenecks, and converge optimization suggestions to the user's main path, build products, and runtime evidence.
 
 ## Procedure
 
-1. 锁定体验目标
-   - 明确问题属于首屏加载、交互延迟、滚动卡顿、内存上涨、网络瀑布、包体积，还是视觉稳定性。
-   - 记录路由、设备、网络条件、浏览器、复现步骤和当前可用指标。
-   - 没有指标时先建立基线，不直接给出“优化一切”的泛化建议。
-
-2. 建立度量基线
-   - 读取项目脚本、构建配置、依赖和已有性能报告。
-   - 对页面体验优先使用 Lighthouse、Performance trace、React Profiler、Vue Devtools、Memory snapshot 或 RUM 数据。
-   - 对包体优先看构建产物、source map、依赖重复、首屏 chunk 和动态 import 边界。
-   - 对运行时卡顿优先看长任务、重复渲染、昂贵计算、同步循环、布局抖动和大列表。
-
-3. 分层定位
-   - 加载层：关键 CSS、字体、图片、脚本阻塞、预加载和缓存。
-   - 渲染层：不稳定 key、过宽 Context、无意义 effect、重复计算、组件树过大。
-   - 数据层：串行请求、重复请求、过大 payload、缺少分页或缓存策略。
-   - 主线程：JSON/CSV 解析、图片处理、复杂排序过滤、同步压缩和大对象深拷贝。
-   - 资源层：事件监听、定时器、订阅、WebGL/Canvas 资源和对象 URL 未释放。
-
-4. 形成优化方案
-   - 每个建议必须绑定位置、影响、改法和验证方式。
-   - 优先处理高频主路径和 P95 体验；低频后台任务不抢占首屏预算。
-   - 先做低风险高收益改动，如懒加载、去重、缓存、尺寸预留、虚拟列表、稳定引用和释放资源。
-   - 对会牺牲可维护性的技巧，必须说明收益证据和替代方案。
-
-5. 验证回归
-   - 重新运行受影响构建、测试和性能采集命令。
-   - 对比优化前后指标或产物体积。
-   - 确认 loading、empty、error、offline、reduced-motion 和移动端状态未被优化破坏。
+1. Lock in experience goals
+   - Clarify whether the problem is first screen loading, interaction delay, scrolling lag, memory increase, network waterfall, packet size, or visual stability.
+   - Document routes, devices, network conditions, browsers, replication steps, and currently available metrics.
+   - When there are no indicators, establish a baseline first and do not directly give generalized suggestions of "optimizing everything".
+
+2. Establish a measurement baseline
+   - Read project scripts, build configurations, dependencies and existing performance reports.
+   - Prioritize the use of Lighthouse, Performance trace, React Profiler, Vue Devtools, Memory snapshot or RUM data for page experience.
+   - Prioritize build products, source maps, dependency duplication, first-screen chunks and dynamic import boundaries for package bodies.
+   - Prioritize long tasks, repeated renderings, expensive calculations, synchronized loops, layout jitters and large lists for runtime lags.
+   - If there are online monitoring, platform indicators or CI products, first use them to confirm the affected routes, devices, time windows and user main paths, and then decide which source code to read.
+
+3. Hierarchical positioning
+   - Loading layers: critical CSS, fonts, images, script blocking, preloading and caching.
+   - Rendering layer: unstable keys, too wide Context, meaningless effects, repeated calculations, and component trees that are too large.
+   - Data layer: serial requests, repeated requests, too large payload, lack of paging or caching strategy.
+   - Main thread: JSON/CSV parsing, image processing, complex sorting and filtering, synchronous compression and large object deep copy.
+   - Resource layer: event listeners, timers, subscriptions, WebGL/Canvas resources and object URLs are not released.
+
+4. Form an optimization plan
+   - Each suggestion must be bound to location, impact, modification and verification method.
+   - Prioritize the high-frequency main path and P95 experience; low-frequency background tasks do not occupy the first screen budget.
+   - Make low-risk, high-yield changes first, such as lazy loading, deduplication, caching, size reservation, virtual lists, stable references and releasing resources.
+   - For techniques that sacrifice maintainability, evidence of benefits and alternatives must be stated.
+   - It is recommended to go through the candidate access control before entering the implementation: whether there is indicator support, whether the route/component/chunk/request can be located, whether it can be verified by the front end, and whether there are smaller changes.
+
+5. Verify regression
+   - Rerun affected build, test, and performance collection commands.
+   - Compare indicators or product volumes before and after optimization.
+   - Confirm that loading, empty, error, offline, reduced-motion and mobile state are not destroyed by optimization.
 
 ## Budgets
 
 | Area | Default Target | Notes |
 | ---- | -------------- | ----- |
-| LCP | 约 2.5s 内 | 以核心页面、目标地区网络和真实设备为准 |
-| CLS | 低于 0.1 | 媒体、广告、异步内容需要预留空间 |
-| INP | 约 200ms 内 | 优先拆分长任务和降低交互路径重渲染 |
-| Initial JS | 遵循项目预算 | 没有预算时先报告当前 gzip / brotli 体积 |
-| Main thread | 避免连续长任务 | 大计算考虑分片、缓存或 Worker |
+| LCP | Within about 2.5s | Subject to core page, target area network and real device |
+| CLS | Less than 0.1 | Media, advertising, and asynchronous content require reserved space |
+| INP | Within about 200ms | Prioritize splitting long tasks and reduce interaction path re-rendering |
+| Initial JS | Follow project budget | Report current gzip / brotli size first if there is no budget |
+| Main thread | Avoid continuous long tasks | Consider sharding, caching or Worker for large calculations |
 
 ## Checks
 
-- 首屏资源是否包含非首屏组件、图表、编辑器、地图或全量图标库。
-- 图片是否有明确尺寸、合适格式、懒加载和首屏优先级。
-- 列表、表格、时间线是否需要虚拟化或分页。
-- 搜索、筛选、排序是否在热路径重复 O(n*m) 扫描。
-- 请求是否可并行、可缓存、可取消、可复用。
-- 监听、订阅、定时器、AbortController、Object URL、Canvas/WebGL 资源是否对称清理。
+- Whether the above-the-fold resources include non-above-the-fold components, charts, editors, maps, or full icon libraries.
+- Whether the image has clear size, appropriate format, lazy loading and first screen priority.
+- Whether lists, tables, and timelines require virtualization or paging.
+- Whether searching, filtering, and sorting repeat O(n*m) scans on the hot path.
+- Whether the request can be parallelized, cached, cancelled, and reusable.
+- Whether listening, subscription, timer, AbortController, Object URL, Canvas/WebGL resources are cleaned symmetrically.
 
 ## Constraints
 
-- 不做没有目标和证据的过早优化。
-- 不靠关闭功能、删除状态反馈或降低可访问性来换性能分数。
-- 不为一次 Lighthouse 分数牺牲真实用户主路径。
-- 不引入大型新依赖解决小问题；先利用项目已有工具和浏览器能力。
-- 不把后端、网络和浏览器侧问题混为一谈；前端能验证的部分要单独列证据。
+- Don’t do premature optimization without goals and evidence.
+- Don’t trade off features, remove status feedback, or reduce accessibility in exchange for performance points.
+- Do not sacrifice real user home paths for a single Lighthouse score.
+- Solve small problems without introducing large new dependencies; first use the existing tools and browser capabilities of the project.
+- Do not confuse back-end, network and browser-side issues; the parts that can be verified on the front-end should be separately documented.
+- Do not jump directly from repo-wide grep to the optimization conclusion; first use indicators or recurrence paths to narrow down candidates, and then read the relevant source code.
 
-## 详细参考
+## Detailed reference
 
-撰写性能分析报告时，加载 [references/report-template.md](references/report-template.md)。
+When writing a performance analysis report, load [references/report-template.md](references/report-template.md).
+When you need to locate framework-specific performance risks classified by React, Vue, Next.js or Nuxt, load [references/framework-performance-patterns.md](references/framework-performance-patterns.md).
 
 ## Expected Output
 
-输出有证据链的性能分析报告，说明基线、瓶颈、优化建议、验证方式和剩余风险。报告保存为 `reports/performance-review-YYYY-MM-DD-HHmmss.md`。
+Output a performance analysis report with an evidence chain, describing the baseline, candidate access control, bottlenecks, optimization suggestions, verification methods and remaining risks. The report is saved as `reports/performance-review-YYYY-MM-DD-HHmmss.md`.

package/skills/fec-performance-optimization/references/framework-performance-patterns.md

@@ -0,0 +1,38 @@
+#Framework-specific performance diagnostic mode
+
+This reference is used for special positioning after entering the performance optimization process. Establish goals, baselines, and candidate gates first, then read corresponding categories by framework; don't jump directly from these lists to conclusions.
+
+## React / Client React
+
+- **Waterfall**: Whether independent requests, permission checks, feature flags, or subcomponent data are waited for serially. Confirm dependencies using Network waterfall, React Profiler, or user path logs.
+- **Bundle**: Whether to simultaneously introduce charts, editors, maps, 3D, full icons, heavy date libraries or barrel exports on the first screen. Locate chunks using build products, source maps, or bundle analyzers.
+- **Rerender**: Whether the Context is too wide, whether the selector is too thick, whether the default object/array props are created every time, and whether expensive derivation is executed repeatedly in the hot path. Use React Profiler or reproducible interactive proofs.
+- **Effect**: Whether to use effect to save data that can be directly deduced, whether to put interaction logic into effect, whether to lack cancellation, cleanup or stable dependencies. Confirm with render count, request count, or memory/subscription evidence.
+- **Lazy boundary**: Whether Suspense, dynamic import, error fallback, loading/empty/error status appear in pairs, whether lazy loading destroys focus or first screen layout stability.
+
+## Vue 3 / Nuxt Client
+
+- **Reactive payload size**: Whether large objects, tabular data, or third-party instances are deeply reactively proxied. Use component updates, memory snapshots, or evidence of long tasks to determine whether shallow reactive or immutable boundaries are needed.
+- **Computed/watch**: Whether the computed derived value is manually synchronized with a wide range watcher, whether the watch monitors wide objects, and whether the asynchronous watch lacks cancellation and race handling.
+- **Template hot path**: Mixed `v-if` in `v-for`, inline recalculation, missing stable `:key`, or rendering non-viewport nodes in a large list.
+- **Async component boundary**: Whether heavy-duty components use asynchronous components or route-level dynamic import, whether the loading state is stable, and whether the error state is recoverable.
+- **Store fan-out**: Whether the Pinia store spreads high-frequency UI temporary state to a wide range of subscribers, or copies the server cache to the global store.
+
+## Next.js
+
+- **Dynamic route drift**: Whether cookies, headers, searchParams or uncached fetch make static routes dynamic. Confirm with build output, response headers, or route behavior.
+- **RSC serialization**: Whether the Server Component passes too large props, duplicate data or unserializable structures to the Client Component.
+- **Fetch/cache policy**: Whether `force-cache`, `no-store`, `revalidate`, tag/path revalidation match the data privacy and update frequency.
+- **Client boundary leakage**: Whether the root layout or high-level client boundary is synchronized with heavy browser libraries, providers or unnecessary state.
+- **Middleware cost**: Whether the middleware carries heavy queries, log batch processing, or business logic that can be placed in the route handler.
+
+## Nuxt 3
+
+- **Rendering mode mismatch**: Whether the page should be SSR, SSG, ISR/route rules or SPA, and whether the actual behavior is consistent with the deployment target.
+- **Data duplication**: `useFetch` / `useAsyncData` Whether the request is repeated, whether the key is stable, whether the client hydration repeatedly pulls the same data.
+- **Route middleware cost**: Whether the routing middleware does heavy asynchronous work, repeated authentication requests or non-cacheable global blocking logic.
+- **Client-only islands**: Whether charts, editors, maps or WebGL that run only in the browser are isolated to client-only or async boundaries.
+
+## Output requirements
+
+Each framework-specific proposal must be written clearly: source of evidence, affected routes/components/chunks/requests, recommended changes, verification commands and possible impact on loading, error, empty, offline, reduced-motion or mobile status.

package/skills/fec-performance-optimization/references/report-template.md

@@ -1,53 +1,59 @@
-# 性能分析报告模板
+#Performance analysis report template
 
 ```markdown
-# 前端性能分析报告
+# Front-end performance analysis report
 
-> 生成时间: YYYY-MM-DD HH:mm
-> 目标页面/流程: ...
-> 环境: 设备、浏览器、网络、分支或版本
+> Generation time: YYYY-MM-DD HH:mm
+> Target page/process: ...
+> Environment: Device, Browser, Network, Branch or Version
 
-## 性能目标
+## Performance target
 
-- 关注指标: LCP / CLS / INP / TBT / bundle size / memory / FPS
-- 项目预算或目标阈值
-- 用户主路径和 P95 场景
+- Focus on metrics: LCP / CLS / INP / TBT / bundle size / memory / FPS
+- Project budget or target threshold
+- User home path and P95 scene
 
-## 基线数据
+## Baseline data
 
-| 指标 | 当前值 | 采集方式 | 备注 |
+| Indicator | Current value | Collection method | Remarks |
 | --- | --- | --- | --- |
 | LCP | ... | Lighthouse / RUM / trace | ... |
 
-## 瓶颈定位
+## Bottleneck location
 
-- 加载层、渲染层、数据层、主线程或资源层问题
-- 关联文件、路由、chunk、组件或请求
-- 支持该判断的 trace、bundle、日志或截图证据
+- Problems with loading layer, rendering layer, data layer, main thread or resource layer
+- Associated files, routes, chunks, components or requests
+- Trace, bundle, log or screenshot evidence to support this judgment
 
-## 优先级
+## Candidate access control
 
-| 优先级 | 问题 | 用户影响 | 风险 |
+| Candidate questions | Indicator support | Positioning scope | Front-end verifiability | Conclusion |
+| --- | --- | --- | --- | --- |
+| ... | RUM / trace / bundle / network | route / component / chunk / request | Yes / No / Collaboration required | investigate / defer / reject |
+
+## Priority
+
+| Priority | Issues | User Impact | Risks |
 | --- | --- | --- | --- |
 | P0 / P1 / P2 | ... | ... | ... |
 
-## 优化方案
+## Optimization plan
 
-- 具体改法
-- 替代方案
-- 可维护性、可访问性和产品行为影响
+- Specific changes to the law
+- Alternatives
+- Maintainability, accessibility and product behavior impacts
 
-## 验证对比
+## Verification comparison
 
-| 指标 | 优化前 | 优化后 | 采集方式 |
+| Indicators | Before optimization | After optimization | Collection method |
 | --- | --- | --- | --- |
 | ... | ... | ... | ... |
 
-## 剩余风险
+## Residual risk
 
-- 未覆盖设备、网络或浏览器
-- 需要后端、设计、产品或基础设施协作的部分
-- 建议监控或后续任务
+- No device, network or browser coverage
+- Parts that require backend, design, product or infrastructure collaboration
+- Suggest monitoring or follow-up tasks
 ```
 
-分析完成后，将报告保存到 `reports/performance-review-YYYY-MM-DD-HHmmss.md`，并告知用户报告路径。
+After the analysis is completed, save the report to `reports/performance-review-YYYY-MM-DD-HHmmss.md` and inform the user of the report path.

package/skills/fec-pwa-implementation/SKILL.md

@@ -1,35 +1,35 @@
 ---
 name: fec-pwa-implementation
-description: Use when adding or reviewing Progressive Web App capabilities such as installability, manifest metadata, Service Worker registration, Workbox caching, offline fallback, app update prompts, maskable icons, or iOS PWA compatibility. Do not use for general API caching or non-installable performance tuning; Chinese triggers include PWA, 离线, Service Worker.
+description: Use when adding or reviewing Progressive Web App capabilities such as installability, manifest metadata, Service Worker registration, Workbox caching, offline fallback, app update prompts, maskable icons, or iOS PWA compatibility. Do not use for general API caching or non-installable performance tuning; Chinese triggers include PWA, offline, Service Worker.
 ---
 
-# PWA 实现
+# PWA implementation
 
 ## Purpose
 
-让 Web 应用具备可安装、离线兜底和可控更新能力。
+Make web applications installable, offline and controllable to update.
 
 ## Procedure
 
-1. 确认 PWA 是否值得做：面向移动端/桌面安装、弱网离线、重复访问场景时优先；纯内部后台、强实时流媒体或只需要普通缓存时不要强行 PWA。
-2. 先补齐 manifest、图标、主题色和 HTML 引用；图标至少覆盖 192/512，Android 需 maskable，iOS 需 apple touch icon。
-3. 注册 Service Worker，并设计更新提示；不要静默 `skipWaiting()` 后强刷用户页面。
-4. 用 Workbox 或框架插件管理 precache/runtime cache；登录、支付、权限变更等敏感请求必须走网络。
-5. 提供 offline fallback 页面和安装提示 UI，并验证首次加载、离线访问、更新激活、卸载重装。
+1. Confirm whether PWA is worth doing: priority is given to mobile/desktop installations, weak network offline, and repeated access scenarios; do not force PWA when it is purely internal backend, has strong real-time streaming media, or only requires ordinary caching.
+2. First complete the manifest, icon, theme color and HTML reference; the icon covers at least 192/512, Android needs to be maskable, and iOS needs apple touch icon.
+3. Register the Service Worker and design an update prompt; do not forcefully refresh the user page after silently `skipWaiting()`.
+4. Use Workbox or framework plug-in to manage precache/runtime cache; sensitive requests such as login, payment, and permission changes must go through the network.
+5. Provide offline fallback page and installation prompt UI, and verify initial loading, offline access, update activation, uninstallation and reinstallation.
 
-## 详细参考
+## Detailed reference
 
-- 需要 manifest 字段、HTML 引用、图标要求、截图和 iOS 注意事项时，加载 [references/manifest-and-icons.md](references/manifest-and-icons.md)。
-- 需要 Service Worker 注册、Workbox 策略、Vite 集成、离线兜底和更新流程时，加载 [references/service-worker-workbox.md](references/service-worker-workbox.md)。
+- Load [references/manifest-and-icons.md](references/manifest-and-icons.md) when manifest fields, HTML references, icon requirements, screenshots, and iOS notes are required.
+- Load [references/service-worker-workbox.md](references/service-worker-workbox.md) when Service Worker registration, Workbox policy, Vite integration, offline backup and update process are required.
 
 ## Constraints
 
-- Service Worker 仅在 HTTPS 下工作（localhost 除外）。
-- 缓存策略必须区分页面、静态资源、API 与敏感操作；不要把登录、支付、权限接口缓存起来。
-- Service Worker 更新有生命周期延迟；用户可见刷新提示优先于强制刷新。
-- iOS PWA 能力弱于 Android，安装、推送和生命周期都要单独验证。
-- 缓存有配额和逐出机制，必须设置 max entries / max age。
+- Service Worker only works under HTTPS (except localhost).
+- The caching strategy must distinguish between pages, static resources, APIs and sensitive operations; do not cache login, payment, and permission interfaces.
+- Service Worker updates have a lifecycle delay; user-visible refresh prompts take precedence over forced refreshes.
+- iOS PWA capabilities are weaker than Android, and installation, push and life cycle must be verified separately.
+- The cache has quotas and eviction mechanisms, and max entries / max age must be set.
 
 ## Expected Output
 
-产出可安装的 Web 应用、离线 fallback、可见更新提示和明确缓存策略。验证 Lighthouse PWA、DevTools Application 面板、离线模式、更新发布和移动端安装流程。
+Produce installable web apps, offline fallbacks, visible update prompts, and explicit caching policies. Validate Lighthouse PWA, DevTools Application panel, offline mode, update release and mobile installation process.

package/skills/fec-pwa-implementation/references/manifest-and-icons.md

@@ -1,16 +1,16 @@
-# Manifest、图标与安装入口
+# Manifest, icon and installation entrance
 
-## Manifest 示例
+## Manifest Example
 
 ```json
 {
-  "name": "我的应用",
-  "short_name": "应用",
+  "name": "My App",
+  "short_name": "Application",
   "start_url": "/",
   "display": "standalone",
   "background_color": "#ffffff",
   "theme_color": "#0052cc",
-  "description": "应用描述",
+"description": "Application description",
   "icons": [
     {
       "src": "/icon-192.png",
@@ -36,7 +36,7 @@
 }
 ```
 
-## HTML 引用
+## HTML Quote
 
 ```html
 <link rel="manifest" href="/manifest.json" />
@@ -44,10 +44,10 @@
 <link rel="apple-touch-icon" href="/icon-192.png" />
 ```
 
-## 检查要点
+## Check Points
 
-- `display: "standalone"` 才有接近原生应用的启动体验。
-- `purpose: "any maskable"` 避免 Android 自适应图标被裁剪。
-- `start_url` 应指向登录后或游客可安全进入的入口。
-- `screenshots` 会影响安装对话框质量。
-- iOS 仍依赖 `apple-touch-icon`，安装提示也通常需要用户手动完成。
+- `display: "standalone"` will have a startup experience close to native applications.
+- `purpose: "any maskable"` prevents Android adaptive icons from being cropped.
+- `start_url` should point to a login or entry point that is safe for visitors.
+- `screenshots` can affect the quality of the installation dialog.
+- iOS still relies on `apple-touch-icon`, and installation prompts usually require users to complete it manually.

package/skills/fec-pwa-implementation/references/service-worker-workbox.md

@@ -1,6 +1,6 @@
-# Service Worker、Workbox 与更新流
+# Service Worker, Workbox and update flow
 
-## 注册 Service Worker
+## Register Service Worker
 
 ```ts
 export function registerServiceWorker() {
@@ -23,16 +23,16 @@ export function registerServiceWorker() {
 }
 ```
 
-## 缓存策略
+## Caching strategy
 
-| 策略 | 适用 | 注意 |
+| Policy | Applicable | Note |
 | --- | --- | --- |
-| `CacheFirst` | 带 hash 的图片、字体、CSS/JS | 必须设置过期策略 |
-| `NetworkFirst` | 页面导航、低风险 GET API | 网络失败才降级缓存 |
-| `StaleWhileRevalidate` | 字体、头像、低风险静态数据 | 用户会先看到旧数据 |
-| `NetworkOnly` | 登录、支付、权限、写操作 | 不进入 SW 缓存 |
+| `CacheFirst` | Images, fonts, CSS/JS with hash | Expiration policy must be set |
+| `NetworkFirst` | Page navigation, low-risk GET API | Downgrade cache only when network fails |
+| `StaleWhileRevalidate` | Fonts, avatars, low-risk static data | Users will see old data first |
+| `NetworkOnly` | Login, payment, permissions, write operations | Do not enter SW cache |
 
-## Vite 集成
+## Vite integration
 
 ```ts
 import { VitePWA } from "vite-plugin-pwa";
@@ -61,8 +61,8 @@ export default defineConfig({
 });
 ```
 
-## 离线与更新
+## Offline and Updates
 
-- 为未缓存页面准备 `/offline.html`，不要让用户只看到浏览器错误页。
-- 更新提示应说明“新版本已可用”，由用户确认刷新。
-- 调试时使用 DevTools Application 面板，必要时清理旧 Service Worker 和 Cache Storage。
+- Prepare `/offline.html` for uncached pages, don't let users only see browser error pages.
+- The update prompt should state "New version is available" and it is up to the user to confirm the refresh.
+- Use the DevTools Application panel when debugging and clean up old Service Workers and Cache Storage if necessary.

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

@@ -1,83 +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 或泛型组件复杂时使用 TypeScript 类型安全流程先收敛类型契约
-
-4. 输出时补齐关键质量项
-   - loading / error / empty / data 状态
-   - 错误处理与重试
-   - 类型约束
-   - 关键测试入口
-   - 必要的专项 skill 分流
-   - 依赖是否已存在于 `package.json`，缺失时先给安装命令再使用
-   - 重型 UI 能力（动效、图表、3D、编辑器、地图）是否隔离为 leaf component 并按需加载
-   - 图片、视频、字体等资源是否本地化、可缓存，并避免占位 URL 进入交付
-   - 页面级 Error Boundary、模块级 fallback、API 错误映射和用户可恢复动作是否一致
-   - Tailwind token/variant 或响应式布局需求是否应分流到对应专项 skill
-
-## 详细参考
-
-需要具体 React 项目结构、组件模式、Hooks、路由、状态归属、API 层形状、错误处理、样式默认值、TypeScript 约定或审查清单时，加载 [references/react-project-details.md](references/react-project-details.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 状态和可恢复操作。
+- 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 类型完整且明确，无 `any` 滥用
-- 可复用逻辑已提取为 hooks，loading/error/empty/data 状态齐全
-- API 层具备类型约束和统一错误处理，状态管理符合就近原则
-- URL 状态、服务端状态、表单状态和全局客户端状态边界明确
-- 关键行为有测试覆盖，关键模块已用 `react-error-boundary` 包裹
-- 超长列表已评估虚拟化，弹窗/复合组件具备键盘与焦点支持
-- 先尊重仓库现状，再给推荐结构
-- 给出必要的文件划分建议
-- 必要时说明为什么这样分层
-- 对新增模块，优先输出最小可落地结构，而不是一次性过度设计
-- 对重构任务，优先保证可迁移性和风险可控
+- 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

@@ -0,0 +1,35 @@
+# React performance patterns
+
+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.
+
+### 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
+
+---
+