@bovinphang/frontend-craft 2.6.0 → 2.8.0

package/skills/fec-implement-from-design/SKILL.md

@@ -1,122 +1,129 @@
 ---
 name: fec-implement-from-design
-description: Use when implementing UI from Figma, Sketch, MasterGo, Pixso, Modao, MockingBot, screenshots, design selections, design tokens, or design-to-code tasks for production frontend components/pages; Chinese triggers include 设计稿, 按设计实现.
+description: Use when implementing UI from Figma, Sketch, MasterGo, Pixso, Modao, MockingBot, screenshots, design selections, design tokens, or design-to-code tasks for production frontend components/pages; Chinese triggers include design draft, implementation by design.
 ---
 
-# 按设计稿实现
+# Implement according to design draft
 
 ## Purpose
 
-基于设计工具（Figma、Sketch、MasterGo、Pixso、墨刀、摹客）的设计上下文，高保真实现页面或组件，强调组件复用、设计 Token 映射、可访问性和面向生产的前端实现。
+Based on the design context of design tools (Figma, Sketch, MasterGo, Pixso, Mokou, Mock), high-fidelity implementation of pages or components emphasizes component reuse, design token mapping, accessibility, and production-oriented front-end implementation.
 
-## 支持的设计工具
+## Supported design tools
 
-| 工具     | MCP 集成                  | 获取设计数据方式                          |
+| Tools | MCP Integration | How to obtain design data |
 | -------- | ------------------------- | ----------------------------------------- |
-| Figma    | `figma` / `figma-desktop` | API 获取设计结构、变量定义                |
-| Sketch   | `sketch`                  | MCP 获取设计选区截图                      |
-| MasterGo | `mastergo`                | API 获取 DSL 结构数据                     |
-| Pixso    | `pixso`                   | 本地 MCP 获取帧数据和代码                 |
-| 墨刀     | `modao`                   | MCP 获取原型数据、生成设计描述            |
-| 摹客     | 无 MCP                    | 通过用户提供的截图、标注或导出的 CSS 获取 |
+| Figma | `figma` / `figma-desktop` | API to obtain design structure and variable definitions |
+| Sketch | `sketch` | MCP Get screenshot of design selection |
+| MasterGo | `mastergo` | API to get DSL structure data |
+| Pixso | `pixso` | Local MCP gets frame data and code |
+| Mo Dao | `modao` | MCP obtains prototype data and generates design descriptions |
+| Mocke | No MCP | Acquired via user-provided screenshots, annotations, or exported CSS |
 
-## 目标
+## Target
 
-- 尽量高还原地实现设计稿
-- 在创建新组件前优先复用现有项目组件
-- 尽可能把设计变量映射到现有 Token
-- 保持实现结果可维护、类型明确、可测试且具备可访问性
-- 避免引入重复的基础组件或并行设计系统
+- Realize the design draft as accurately as possible
+- Prioritize reusing existing project components before creating new ones
+- Map design variables to existing Tokens as much as possible
+- Keep implementations maintainable, well-typed, testable, and accessible
+- Avoid introducing duplication of basic components or parallel design systems
 
 ## Procedure
 
-### 1. 识别设计来源
+### 1. Identify design sources
 
-按优先级选择设计数据获取方式：
+Select the design data acquisition method according to priority:
 
-- `figma` — Figma API 集成
-- `figma-desktop` — Figma 桌面端集成
-- `mastergo` — MasterGo DSL 数据
-- `pixso` — Pixso 本地 MCP
-- `modao` — 墨刀原型数据
-- `sketch` — Sketch 选区截图
-- 如以上 MCP 均不可用，请求用户提供设计截图或标注（适用于摹客等无 MCP 工具）
+- `figma` — Figma API integration
+- `figma-desktop` — Figma desktop integration
+- `mastergo` — MasterGo DSL data
+- `pixso` — Pixso local MCP
+- `modao` — Ink knife prototype data
+- `sketch` — Sketch selection screenshot
+- If none of the above MCPs are available, ask the user to provide design screenshots or annotations (applicable to tools without MCP such as Mocke)
+- If there is no authoritative design draft, but the task clearly requires a visual website, brand page, portfolio or high-aesthetic redesign, user-provided or locally generated section-level reference images can be used as a temporary source of visual truth; this source must be analyzed first and then implemented, and marked in the plan as not an authoritative design system.
 
-### 2. 读取设计上下文
+### 2. Read the design context
 
-通过 MCP 或用户提供的设计数据读取设计上下文：
+Read the design context from the MCP or user-supplied design data:
 
-- 检查布局结构
-- 检查间距、字体、颜色、变量、状态、图标和组件层级
-- 如果 MCP 提供了资源文件或 SVG / 图片源，直接使用
-- 如果 MCP 已提供真实资源，不要自行造占位资源
-- 如果用户提供截图而非 MCP 数据，从截图中推断布局、颜色、字体等视觉信息
+- Check layout structure
+- Check spacing, fonts, colors, variables, states, icons and component hierarchy
+- If MCP provides resource files or SVG/image sources, use them directly
+- If MCP has provided real resources, do not create placeholder resources by yourself
+- If the user provides screenshots instead of MCP data, infer visual information such as layout, color, font, etc. from the screenshots
+- If using images/screenshots for reference, first extract block structure, visual hierarchy, main and functional colors, font temperament, spacing rhythm, media position, interaction status hints and responsive risks before writing code.
+- Prioritize the use of clear section-level reference images or local detail images for multi-section pages; do not guess buttons, font sizes, spacing and component status from compressed long images.
+- Unreadable text, fake screenshots, uninspectable materials or conflict status in visual references cannot be copied directly; they need to be translated into the real content, real status or clear placeholder description of the project.
 
-### 3. 搜索可复用组件
+### 3. Search for reusable components
 
-在创建新组件前先搜索代码库中的可复用组件，重点检查：
+Before creating a new component, search the code base for reusable components, focusing on:
 
 - Button
 - Input / Select / Checkbox / Radio / Switch
 - Modal / Drawer / Dialog
 - Table / List / Card
 - Tabs / Breadcrumb / Pagination
-- 页面容器 / 区块容器 / 空状态 / Loading 状态
+- Page Container/Block Container/Empty State/Loading State
 
-### 4. 产出实现计划
+### 4. Output realization plan
 
-在改文件前先产出一份简短实现计划，计划必须包含：
+Before revising the document, produce a short implementation plan. The plan must include:
 
-- 需要改动的文件列表
-- 组件拆分方案
-- 状态 / 数据流
-- 响应式行为
-- 复用还是新建的决策
-- 设计缺口或歧义点
+- List of files that need to be changed
+- Component splitting plan
+- Status/data flow
+- Responsive behavior
+- The decision to reuse or create a new one
+- Design gaps or points of ambiguity
+- The authenticity of the source of the image/screenshot, and what visual details are covered by project tokens, component conventions, or accessibility requirements
 
-### 5. 按框架实现
+### 5. Implementation by framework
 
-按仓库当前使用的前端框架进行实现：
+Implement according to the front-end framework currently used by the warehouse:
 
-- 严格遵循仓库现有约定
-- 优先使用明确类型的 props 和 interfaces/types
-- 保持组件小而可组合
-- 将重复逻辑提取为 hooks / composables / utilities
+- Strictly follow the existing agreements in the warehouse
+- Prefer explicitly typed props and interfaces/types
+- Keep components small and composable
+- Extract duplicate logic into hooks/composables/utilities
 
-### 6. 设计 Token 映射
+### 6. Design Token Mapping
 
-- 优先使用现有 design token、CSS 变量、主题变量或工具类
-- 除非确实没有对应 Token，否则不要硬编码颜色、圆角和间距
-- 如果设计使用了新 Token，要明确指出，不要悄悄到处硬编码
+- Prefer using existing design tokens, CSS variables, theme variables or tool classes
+- Do not hardcode colors, rounded corners and spacing unless there is no corresponding token
+- If the design uses a new Token, make it clear and don’t quietly hardcode it everywhere
 
-### 7. 可访问性保障
+### 7. Accessibility guarantee
 
-- 优先使用语义化 HTML
-- 确保交互控件具有可访问名称
-- 保留可见的焦点样式
-- 检查对话框、菜单、标签页、表单控件的键盘可操作性
+- Prioritize the use of semantic HTML
+- Make sure interactive controls have accessible names
+- Preserve visible focus styles
+- Check the keyboard operability of dialog boxes, menus, tabs, and form controls
 
-### 8. 编码后验证
+### 8. Verify after encoding
 
-- 如有 lint，执行 lint
-- 如有测试，执行测试
-- 如果缺少测试，说明建议补充的最小测试范围
+- If there is lint, execute lint
+- If there are tests, execute them
+- If testing is missing, indicate the recommended minimum testing range
 
-## 详细参考
+## Detailed reference
 
-撰写实现计划报告时，加载 [references/design-plan-template.md](references/design-plan-template.md)。
+When writing the implementation plan report, load [references/design-plan-template.md](references/design-plan-template.md).
 
 ## Constraints
 
-- 如果已有设计上下文（MCP 或截图），不要靠猜来实现 UI
-- 如果项目已有 UI 体系，不要再引入一套新的 UI Kit
-- 除非有合理理由，不要用硬编码替代已 Token 化的样式
-- 不要忽略 hover、active、disabled、loading、empty、error 等状态
-- 摹客等无 MCP 工具场景下，主动向用户索要关键截图和标注信息，不要凭空编造视觉数据
+- If you already have a design context (MCP or screenshots), don’t rely on guesswork to implement the UI
+- If the project already has a UI system, do not introduce a new UI Kit
+- Do not replace tokenized styles with hard-coding unless there is a valid reason
+- Don't ignore statuses such as hover, active, disabled, loading, empty, error, etc.
+- In scenarios where MCP tools are not available, such as Mocke, proactively ask users for key screenshots and annotation information, and do not make up visual data out of thin air.
+- Do not treat the generated image as a directly reproducible code specification; it only provides visual evidence, and the final implementation must obey the current project components, tokens, accessibility and performance boundaries
+- Do not replace section analysis with an unreadable full-page image; key sections, CTAs, forms, navigation and status must be inspectable
 
 ## Expected Output
 
-- 设计实现计划报告保存为 `reports/design-plan-YYYY-MM-DD-HHmmss.md`，包含实现概要、组件拆分方案、状态/数据流、变更文件清单
-- 代码实现高保真还原设计稿，组件复用率最大化
-- 设计变量映射到现有 Token，无硬编码颜色/间距/圆角
-- 交互元素具备可访问名称和键盘支持，焦点样式可见
+- The design implementation plan report is saved as `reports/design-plan-YYYY-MM-DD-HHmmss.md`, including implementation summary, component splitting plan, status/data flow, and change file list
+- The code realizes high-fidelity restoration of the design draft, maximizing component reuse rate
+- Design variables map to existing Tokens, no hard-coded colors/spacing/rounded corners
+- Interactive elements have accessible names and keyboard support, and focus styles are visible

package/skills/fec-implement-from-design/references/design-plan-template.md

@@ -1,36 +1,36 @@
-# 设计实现计划模板
+# Design implementation plan template
 
 ```markdown
-# 设计实现计划
+# Design implementation plan
 
-> 生成时间: YYYY-MM-DD HH:mm
-> 评审工具: frontend-craft
-> 设计工具: Figma / Sketch / MasterGo / Pixso / 墨刀 / 摹客
+> Generation time: YYYY-MM-DD HH:mm
+> Review tool: frontend-craft
+> Design tools: Figma / Sketch / MasterGo / Pixso / Ink Knife / Mockup
 
-## 实现概要
-- 设计稿来源: ...
-- 目标页面/组件: ...
+## Implementation Summary
+- Source of design draft: ...
+- Target page/component: ...
 
-## 复用的组件
+## Reused components
 - ...
 
-## 新建的组件
+## New component
 - ...
 
-## 组件拆分方案
+## Component splitting plan
 - ...
 
-## 状态/数据流
+## Status/data flow
 - ...
 
-## 与设计稿的偏差
+## Deviation from the design draft
 - ...
 
-## 缺失的资源 / Token / 交互细节
+## Missing resources/Token/Interaction details
 - ...
 
-## 变更文件清单
+## Change file list
 - ...
 ```
 
-实现计划确定后，将报告保存到 `reports/design-plan-YYYY-MM-DD-HHmmss.md`，并告知用户报告路径。
+After the implementation plan is determined, save the report to `reports/design-plan-YYYY-MM-DD-HHmmss.md` and inform the user of the report path.

package/skills/fec-legacy-to-modern-migration/SKILL.md

@@ -1,190 +1,46 @@
 ---
 name: fec-legacy-to-modern-migration
-description: Use when planning or implementing an intentional migration from JavaScript, jQuery, HTML/CSS, server-rendered templates, MPA legacy frontend code, or older framework code toward a modern frontend stack while preserving behavior. Do not use for routine legacy bug fixes that stay in the old stack; Chinese triggers include 遗留项目, 技术栈升级, jQuery 迁移.
+description: Use when planning or implementing an intentional migration from JavaScript, jQuery, HTML/CSS, server-rendered templates, MPA legacy frontend code, or older framework code toward a modern frontend stack while preserving behavior. Do not use for routine legacy bug fixes that stay in the old stack; Chinese triggers include legacy projects, technology stack upgrades, jQuery migration.
 ---
 
-# 传统前端到现代框架迁移
+# Migration from traditional front-end to modern framework
 
-适用于将 JavaScript + jQuery + HTML/CSS 多页面应用（MPA）、服务端模板渲染项目或旧框架代码，渐进迁移到 React、Vue、Next.js、Nuxt、TypeScript，或保留 MPA 形态但现代化模块、构建、类型和测试的场景。
+Suitable for scenarios where you are gradually migrating JavaScript + jQuery + HTML/CSS multi-page applications (MPA), server-side template rendering projects, or legacy framework code to React, Vue, Next.js, Nuxt, TypeScript, or retaining MPA form but modernizing modules, builds, types, and tests.
 
 ## Purpose
 
-指导传统前端项目渐进迁移到目标现代栈，提供迁移策略、概念映射、分阶段步骤和实施约束，确保功能等价和风险可控。
+Guide the gradual migration of traditional front-end projects to the target modern stack, provide migration strategies, concept mapping, phased steps and implementation constraints to ensure functional equivalence and controllable risks.
 
 ## Procedure
 
-1. 先识别目标栈、迁移边界和是否保留 MPA/服务端模板形态。
-2. 选择渐进式或一次性重写策略，并输出迁移分析报告。
-3. 做存量盘点、依赖关系分析和迁移优先级排序。
-4. 按准备、基础层、模块/页面迁移、收尾的顺序推进，每次迁移一个可验证单元。
-5. 每个迁移单元按检查清单验证功能等价、视觉一致、类型安全、可访问性、i18n、资源和样式边界。
-
-## 迁移策略选择
-
-| 策略                        | 适用情况                             | 优点                         | 风险                         |
-| --------------------------- | ------------------------------------ | ---------------------------- | ---------------------------- |
-| **渐进式（Strangler Fig）** | 大型项目、需持续交付、团队熟悉度不足 | 风险可控、可分批上线、可回滚 | 新旧并存期长、需维护两套代码 |
-| **一次性重写**              | 中小型项目、业务稳定、有充足时间窗口 | 目标架构清晰、无历史包袱     | 周期长、上线压力大、回滚困难 |
-
-**推荐**：优先考虑渐进式，除非项目规模小且业务简单。
-
-## 概念映射
-
-### jQuery → React
-
-| 遗留模式                                   | React 对应                             |
-| ------------------------------------------ | -------------------------------------- |
-| `$(selector).html(content)`                | 声明式 JSX + state 驱动渲染            |
-| `$(document).on('click', '.btn', handler)` | `onClick` + 事件委托由 React 处理      |
-| `$.ajax()` / `$.get()`                     | 项目请求层、`fetch` / `axios`，可按需接 TanStack Query 或 SWR |
-| 全局变量 / 命名空间存储状态                | 局部 state、Context 或项目既有 store，可按需使用 Zustand/Redux |
-| `$(el).show()` / `$(el).hide()`            | 条件渲染 `{visible && <Component />}`  |
-| 手动 DOM 操作 `append` / `remove`          | 数据驱动，通过 setState 触发重渲染     |
-| 模板字符串拼接 HTML                        | JSX 组件 + props                       |
-| 多页面 + 服务端路由                        | React Router 客户端路由                |
-
-### jQuery → Vue 3
-
-| 遗留模式                                   | Vue 3 对应                                         |
-| ------------------------------------------ | -------------------------------------------------- |
-| `$(selector).html(content)`                | 模板 + `ref` / `reactive` 驱动渲染                 |
-| `$(document).on('click', '.btn', handler)` | `@click` + 事件修饰符                              |
-| `$.ajax()` / `$.get()`                     | 项目请求层、`fetch` / `axios`，可按需接 VueUse、Nuxt `useFetch` 或 TanStack Query Vue adapter |
-| 全局变量 / 命名空间存储状态                | `ref` / `reactive` / Pinia                         |
-| `$(el).show()` / `$(el).hide()`            | `v-show` / `v-if`                                  |
-| 手动 DOM 操作                              | 数据驱动，通过响应式更新视图                       |
-| 模板字符串拼接 HTML                        | 单文件组件 `<template>` + props                    |
-| 多页面 + 服务端路由                        | Vue Router 客户端路由                              |
-
-### 通用映射
-
-| 遗留概念                          | 现代对应                                   |
-| --------------------------------- | ------------------------------------------ |
-| 页面级 JS 入口（每页一个 script） | 路由/页面入口 + 懒加载模块，或保留 MPA 入口并现代化打包 |
-| 公共 JS 模块（utils、ajax 封装）  | `services/`、`utils/`、类型化 API 层       |
-| 内联样式 / 页面级 CSS             | 目标项目样式体系，如 CSS Modules、Tailwind、全局样式分层或组件库样式 |
-| 服务端模板变量                    | 通过 API 获取、SSR/loader 注入，或保留服务端模板边界并类型化数据 |
-| 表单提交 + 整页刷新               | 表单库 + 客户端校验 + API 调用             |
-
-## 迁移前分析
-
-在动手迁移前，必须完成以下分析并输出**迁移分析报告**：
-
-1. **存量盘点**
-   - 页面数量、功能模块数量
-   - 依赖的 jQuery 插件及替代方案（如 DataTables → TanStack Table）
-   - 现有 API 调用方式、是否有统一封装
-   - 是否有服务端模板（JSP/Thymeleaf/EJS 等）需要保留、局部替换或改为纯前端渲染
-   - 目标栈是 React/Vue/Next/Nuxt、现代 MPA，还是只做局部 TypeScript/构建/测试现代化
-
-2. **依赖关系**
-   - 页面间共享的 JS/CSS 模块
-   - 跨页面复用的业务逻辑
-   - 与后端的接口契约（是否需调整）
-
-3. **迁移优先级**
-   - 按业务价值、复杂度、耦合度排序
-   - 优先迁移独立模块、低耦合页面
-   - 识别可复用的工具函数、常量、类型定义
-
-## 分阶段迁移流程
-
-### 阶段 0：准备
-
-- 搭建或识别目标项目骨架：React/Vue/Next/Nuxt、现代 MPA，或现有项目内的渐进式 TypeScript/构建入口
-- 配置 ESLint、Prettier、测试框架
-- 建立 `services/request.ts` 统一请求层，与现有 API 兼容
-- 将遗留项目中的 `utils`、`constants` 逐步迁移并补充类型
-
-### 阶段 1：基础层
-
-- 迁移并类型化 API 调用（`$.ajax` → `axios`/`fetch`）
-- 迁移工具函数（日期、格式化、校验等）
-- 迁移常量、枚举、类型定义
-- 建立目标导航/页面入口骨架；未迁移页面可继续走旧路由、重定向、iframe 或微前端嵌入
-
-### 阶段 2：按模块/页面迁移
-
-- 每次迁移一个完整功能或页面
-- 从简单到复杂：静态页 → 列表页 → 表单页 → 复杂交互页
-- 迁移时提取可复用组件，遵循目标 React 或 Vue 项目的目录结构
-- 每完成一个模块，补充单元测试和 E2E 关键路径
-
-### 阶段 3：收尾
-
-- 按迁移策略移除或冻结旧代码入口；若保留 MPA，则收敛旧入口并完成现代化边界
-- 配置 404、错误边界、全局错误处理
-- 性能优化（懒加载、代码分割、缓存策略）
-- 文档更新、部署流程调整
-
-## 重构实施要求
-
-迁移时需遵循以下实施约束，确保视觉与交互一致、代码更简洁易维护。
-
-### 图片与图标
-
-- 直接使用原项目的图片资源路径，不重新托管或替换
-- 可使用 SVG 图片（`<img src="*.svg" />` 或 CSS `background-image`）；图标组件或可访问交互确需内联 SVG 时，应遵循目标项目图标规范并说明理由。
-- 若原项目使用了 iconfont 或 IcoMoon 图标，重构时优先继续使用，保持图标体系一致；替换为其他图标方案前需评估视觉一致性、包体和维护成本。
-- 图标优先使用原项目已有的图标文件（iconfont / IcoMoon / 已有 SVG），必要时可引入 SVG 文件作为独立资源
-
-### 国际化（i18n）
-
-- 新栈代码（React / Vue 等）中的用户可见文案须走项目 i18n，不在新代码里硬编码中/英文案
-- 遗留 HTML/JS 中**不要新增**用户可见硬编码文案，除非纯静态且仓库尚无可用 i18n 接入点；改动文案前先查 locales 是否已有条目，并同步主要语言文件
-- key 按页面/模块/语义组织，复用既有 key；仅当旧 key 为对外契约时才做映射过渡，详见项目规则中的 **国际化 (i18n)**（`templates/shared/rules/fec-i18n.md` 内「遗留代码与迁移场景」）
-
-### 样式
-
-- 布局样式对齐原项目视觉效果，但**只参考原项目效果，不照搬其 CSS**
-- 优先使用 **flex 弹性布局**，避免 `float`、复杂 `position`、冗余嵌套
-- 避免不合理写法：如 `!important` 滥用、过深选择器、重复定义
-- 组件中优先避免内联样式（`style={{ ... }}` / `style="..."`）；确需使用运行时动态值、第三方组件 API 或 CSS 变量桥接时，应保持局部、可解释，并优先放入目标项目样式体系。
-
-### 目标
-
-- **视觉和交互**：与原项目一致，用户无感知差异
-- **代码质量**：更简洁、易维护，符合目标框架规范
-- **业务功能**：与原项目保持一致，**不得缺失功能**；迁移前后行为等价
-
-## 迁移检查清单
-
-每个迁移单元完成后，确认：
-
-- [ ] 业务逻辑与旧实现一致，无功能遗漏，功能完整等价
-- [ ] 类型定义完整，无 `any` 滥用
-- [ ] API 调用使用统一 request 层，错误处理完整
-- [ ] 表单校验、loading、空状态、错误状态已实现
-- [ ] 可访问性：表单有 label、交互可键盘操作
-- [ ] 无 XSS 风险（用户输入已转义或使用安全 API）
-- [ ] 关键路径有测试覆盖
-- [ ] 符合目标栈的项目规范（React / Vue / Next / Nuxt / MPA 现代化等）
-- [ ] 图片使用原项目资源；图标体系优先沿用原项目或目标项目规范，例外已说明
-- [ ] 样式参考原项目效果但不照搬 CSS，优先使用目标项目样式体系，内联样式例外已说明
-- [ ] 视觉与交互与原项目一致，代码更简洁易维护
-- [ ] 新代码路径文案已 i18n；遗留层未扩大硬编码；locales 检索与多语言同步已完成（参见 i18n 规则迁移补充清单）
+1. First identify the target stack, migration boundaries and whether to retain the MPA/server template form.
+2. Load [references/migration-strategy-and-mapping.md](references/migration-strategy-and-mapping.md), select a progressive or one-time rewrite strategy, and clarify the mapping of legacy patterns to the target stack.
+3. Load [references/migration-execution-checklist.md](references/migration-execution-checklist.md) to complete inventory inventory, dependency analysis, prioritization and phased migration plan.
+4. When writing a migration analysis or migration plan report, load [references/migration-report-template.md](references/migration-report-template.md).
+5. Advance in the order of preparation, base layer, module/page migration, and closing, migrating one verifiable unit at a time.
+6. Each migration unit verifies functional equivalence, visual consistency, type safety, accessibility, i18n, resource and style boundaries.
 
 ## Constraints
 
-- 迁移前必须先输出迁移分析报告，明确策略、优先级和风险
-- 不要在一次迁移中同时改架构、改 UI、改接口
-- 优先保证功能等价，再考虑优化和现代化
-- 迁移过程中保持旧系统可运行，避免大爆炸式上线
-- 遇到 jQuery 插件无现成替代时，可暂时用 iframe 或微前端方式嵌入，待后续替换
-- **目标栈**：先识别 React/Vue/Next/Nuxt、现代 MPA 或局部现代化目标，不默认强制改成 SPA。
-- **图片与图标**：使用原项目图片资源，图标体系优先沿用原项目或目标项目规范；内联 SVG 例外需有可访问性、组件化或维护理由。
-- **样式**：参考原项目效果不照搬 CSS，优先使用目标项目样式体系；内联样式例外需局部、可解释。
-- **目标**：视觉与交互一致、代码更简洁易维护，业务功能不得缺失
-
-## 详细参考
-
-撰写迁移分析或迁移计划报告时，加载 [references/migration-report-template.md](references/migration-report-template.md)。
+- Before migration, a migration analysis report must be output to clarify strategies, priorities and risks.
+- Do not change the architecture, UI, and interfaces at the same time in one migration.
+- Prioritize functional equivalence before considering optimization and modernization.
+- Keep the old system operational during the migration process to avoid a big bang rollout.
+- When there is no ready replacement for the jQuery plug-in, you can temporarily embed it using iframe or micro-front-end and wait for subsequent replacement.
+- The target stack first identifies React/Vue/Next/Nuxt, modern MPA or partial modernization targets, and does not force the change to SPA by default.
+- Images use original project resources; the icon system prefers to use the original project or target project specifications; inline SVG exceptions must have accessibility, componentization or maintenance reasons.
+- The style refers to the original project effect but does not copy CSS. The target project style system is preferred; inline style exceptions must be local and interpretable.
+- The goal is to have consistent visuals and interactions, make the code simpler and easier to maintain, and business functions must not be missing.
+- For migrations involving pages, components, routing, forms, pop-ups, navigation or key user processes, a list of behaviors before and after refactoring must be established, and the critical paths must be compared and verified using Playwright or an equivalent real browser verification method.
+- For visually sensitive pages, screenshot comparison or manual screenshot acceptance should be supplemented; dynamic content, animation, fonts and environmental differences need to be clearly blocked, stabilized or explained.
+- For pure logic, type, build or UI-less migrations, Playwright is not forced and a validation layer closer to risk should be chosen: type-check, unit test, component test, build or lint.
+- The verification goal is not to be completely consistent at the pixel level, but to confirm that there are no missing business functions, key interactions are equivalent, there are no unexpected deviations in the main visual layout, and the code is clearer and maintainable than the old implementation.
 
 ## Expected Output
 
-- 迁移分析报告保存为 `reports/migration-plan-YYYY-MM-DD-HHmmss.md`，包含策略选择、存量盘点、依赖关系、分阶段步骤、风险与回滚方案
-- 迁移后的业务功能与原项目完全等价，无功能缺失
-- 视觉与交互与原项目一致，用户无感知差异
-- 类型定义完整，无 `any` 滥用，API 调用统一且类型安全
-- 图片使用原项目资源，样式进入目标项目样式体系，图标和内联样式例外有明确理由
-- 新代码文案已 i18n，关键路径有测试覆盖
+- The migration analysis report is saved as `reports/migration-plan-YYYY-MM-DD-HHmmss.md`, including strategy selection, inventory inventory, dependencies, phased steps, risks and rollback plans.
+- The migrated business functions are completely equivalent to those of the original project, with no missing functions.
+- The visuals and interactions are consistent with the original project, and there is no perceived difference for users.
+- Complete type definition, no `any` abuse, unified API calls and type safety.
+- Images use original project resources, and styles enter the target project style system. Exceptions for icons and inline styles have clear reasons.
+- The new code copy has been i18n, and the critical path is covered by tests.

package/skills/fec-legacy-to-modern-migration/references/migration-execution-checklist.md

@@ -0,0 +1,110 @@
+# Migration execution and checklist
+
+## Pre-migration analysis
+
+Before starting the migration, the following analysis must be completed and a **migration analysis report** must be output:
+
+1. **Inventory Count**
+   - Number of pages and number of functional modules
+   - Dependent jQuery plugins and alternatives (such as DataTables → TanStack Table)
+   - Existing API calling methods and whether there is unified encapsulation
+   - Are there any server-side templates (JSP/Thymeleaf/EJS, etc.) that need to be retained, partially replaced, or changed to pure front-end rendering?
+   - Is the target stack React/Vue/Next/Nuxt, modern MPA, or just partial TypeScript/build/test modernization?
+
+2. **Dependencies**
+   - JS/CSS modules shared between pages
+- Business logic reused across pages
+   - Interface contract with the backend (whether it needs to be adjusted)
+
+3. **Migration Priority**
+   - Sort by business value, complexity, coupling degree
+   - Prioritize migrating independent modules and low-coupling pages
+   - Identify reusable utility functions, constants, and type definitions
+
+## Phased migration process
+
+### Phase 0: Preparation
+
+- Build or identify target project skeleton: React/Vue/Next/Nuxt, modern MPA, or progressive TypeScript/build entry within existing projects
+- Configure ESLint, Prettier, and test framework
+- Establish `services/request.ts` unified request layer, compatible with existing API
+- Gradually migrate `utils` and `constants` in legacy projects and add types
+
+### Phase 1: Base Layer
+
+- Migrate and type API calls (`$.ajax` → `axios`/`fetch`)
+- Migration tool functions (date, formatting, verification, etc.)
+- Migrate constants, enumerations, and type definitions
+- Establish target navigation/page entry skeleton; unmigrated pages can continue to use old routing, redirection, iframe or micro-front-end embedding
+
+### Phase 2: Migration by module/page
+
+- Migrate one complete feature or page at a time
+- From simple to complex: static page → list page → form page → complex interactive page
+- Extract reusable components during migration, following the directory structure of the target React or Vue project
+- Supplementary unit testing and E2E critical path for each completed module
+
+### Phase 3: Closing
+
+- Remove or freeze old code entries according to the migration strategy; if MPA is retained, the old entries will be converged and the modernization boundary will be completed
+- Configure 404, error boundaries, and global error handling
+- Performance optimization (lazy loading, code splitting, caching strategy)
+- Document updates and deployment process adjustments
+
+## Refactoring implementation requirements
+
+The following implementation constraints need to be followed when migrating to ensure consistent vision and interaction, and the code is simpler and easier to maintain.
+
+### Pictures and Icons
+
+- Directly use the image resource path of the original project without rehosting or replacing it.
+- SVG images (`<img src="*.svg" />` or CSS `background-image`) can be used; when icon components or accessible interactions require inline SVG, the target project icon specifications should be followed and the reasons should be explained.
+- If the original project uses iconfont or IcoMoon icons, priority should be given to continuing to use them during reconstruction to keep the icon system consistent; visual consistency, packaging, and maintenance costs need to be evaluated before replacing with other icon schemes.
+- For icons, priority is given to using existing icon files in the original project (iconfont / IcoMoon / existing SVG). If necessary, SVG files can be introduced as independent resources
+
+### Internationalization (i18n)
+
+- User-visible copy in the new stack code (React/Vue, etc.) must follow the project i18n, and do not hardcode Chinese/English copy in the new code
+- **Do not add** user-visible hard-coded copy in legacy HTML/JS, unless it is purely static and the warehouse does not yet have an available i18n access point; before changing the copy, check whether locales already has an entry, and synchronize the main language files
+- Keys are organized by page/module/semantics, and existing keys are reused; mapping transition is only done when the old key is an external contract. For details, see **Internationalization (i18n)** in the project rules ("Legacy Code and Migration Scenarios" in `templates/shared/rules/fec-i18n.md`)
+
+### Style
+
+- The layout style aligns with the visual effects of the original project, but **only refers to the original project effects and does not copy its CSS**
+- Prioritize the use of **flex elastic layout** to avoid `float`, complex `position`, and redundant nesting
+- Avoid unreasonable writing methods: such as `!important` abuse, excessively deep selectors, and repeated definitions
+- Prioritize to avoid inline styles (`style={{ ... }}` / `style="..."`) in components; when it is necessary to use runtime dynamic values, third-party component APIs or CSS variable bridging, they should be kept local and interpretable and put into the target project style system first.
+
+### Target
+
+- **Visual and interactive**: consistent with the original project, no perceived difference by users
+- **Code Quality**: more concise, easier to maintain, and in line with the target framework specifications
+- **Business functions**: consistent with the original project, **no missing functions**; behaviors before and after migration are equivalent
+
+### Verification layering
+
+- If it involves the migration of pages, components, routing, forms, pop-ups, navigation or key user processes, first establish a list of behaviors before and after refactoring, and then use Playwright or an equivalent real browser verification method to compare and verify the critical paths.
+- For visually sensitive pages, supplement screenshot comparison or manual screenshot acceptance; dynamic content, animation, fonts and environmental differences need to be clearly blocked, stabilized or explained.
+- For pure logic, type, build or UI-less migrations, Playwright is not forced and a validation layer closer to risk should be chosen: type-check, unit test, component test, build or lint.
+- The verification goal is not to be completely consistent at the pixel level, but to confirm that there are no missing business functions, key interactions are equivalent, there are no unexpected deviations in the main visual layout, and the code is clearer and maintainable than the old implementation.
+
+## Migration Checklist
+
+After each migration unit is completed, confirm:
+
+- [ ] A behavioral list before and after refactoring has been established, covering public APIs, routing, forms, permissions, error status, cache, hidden points and key interactions
+- [ ] The business logic is consistent with the old implementation, no functions are missing, and the functions are completely equivalent.
+- [ ] Migration involving UI, interaction or critical processes has completed critical path comparison using Playwright or equivalent real browser verification
+- [ ] For visually sensitive pages, screenshot comparison or manual screenshot acceptance has been completed, and the method of handling differences in dynamic content, animation, fonts and environment has been explained.
+- [ ] Pure logic, type, build or no UI migrations have selected a validation layer that is closer to the risk and do not force the application of Playwright
+- [ ] Type definition is complete, no `any` abuse
+- [ ] API calls use a unified request layer, with complete error handling
+- [ ] Form verification, loading, empty state, and error state have been implemented
+- [ ] Accessibility: The form has a label and can be interacted with via the keyboard.
+- [ ] No XSS risk (user input is escaped or secure API is used)
+- [ ] Critical path has test coverage
+- [ ] Comply with the project specifications of the target stack (React / Vue / Next / Nuxt / MPA modernization, etc.)
+- [ ] Pictures use original project resources; icon systems give priority to the original project or target project specifications, exceptions have been explained
+- [ ] The style refers to the original project effect but does not copy the CSS. The target project style system is used first. The inline style exception has been explained.
+- [ ] The visual and interaction are consistent with the original project, and the code is simpler and easier to maintain.
+- [ ] The new code path copy has been i18n; the legacy layer has not been expanded and hardcoded; locales retrieval and multi-language synchronization have been completed (see i18n rule migration supplementary list)