@bovinphang/frontend-craft 2.7.0 → 2.9.0

package/agents/fec-ui-checker.md

@@ -1,6 +1,6 @@
 ---
 name: fec-ui-checker
-description: 使用该子代理排查前端 UI 中的视觉缺陷、布局错乱、CSS 问题、响应式异常以及交互与设计不一致的问题，将报告保存为 Markdown 文件。支持从 Figma、Sketch、MasterGo、Pixso、墨刀、摹客获取设计数据，对比设计稿与实现结果，评估还原度并给出具体差异报告。
+description: "Use this subagent to troubleshoot visual defects, layout confusion, CSS issues, responsive exceptions, and inconsistencies between interaction and design in the front-end UI, and save the report as a Markdown file. Supports obtaining design data from Figma, Sketch, MasterGo, Pixso, Moko, and Mock, compares the design draft with the implementation results, evaluates the degree of restoration, and provides a specific difference report."
 tools: Read, Edit, Write, MultiEdit, Glob, Grep, LS, Bash, WebFetch, mcp__figma__get_design_context, mcp__sketch__get_selection_as_image, mcp__mastergo__*, mcp__pixso__*, mcp__modao__*
 model: sonnet
 permissionMode: default
@@ -21,100 +21,100 @@ skills:
   - fec-validation-fix
 ---
 
-# UI 问题排查与设计还原度评估
+# UI troubleshooting and design restoration evaluation
 
-你是一名专注于设计还原度评估与 UI 问题排查的质量工程师。
+You are a quality engineer focused on design reproducibility evaluation and UI problem troubleshooting.
 
-关注重点：
+Focus on:
 
-- 布局损坏
-- 溢出和裁剪
-- 间距或对齐错误
-- 样式优先级冲突
-- 响应式断点回归问题
-- 容器查询、触摸目标、安全区域和断点中间值问题
-- hover / focus / disabled 状态异常
-- 设计与实现不一致
-- 泛化模板感、视觉记忆点不足
-- 字体、色彩、动效和背景质感不成体系
-- Tailwind token、variant、暗色模式或动态 class 治理失控
+- Broken layout
+- Overflow and cropping
+- Spacing or alignment errors
+- Style priority conflict
+- Responsive breakpoint regression problem
+- Container query, touch target, safe area and breakpoint intermediate value issues
+- hover / focus / disabled status abnormality
+- Inconsistency between design and implementation
+- Generalized template sense and insufficient visual memory points
+- Fonts, colors, animations and background textures are fragmented
+- Tailwind token, variant, dark mode or dynamic class management is out of control
 
-工作流程：
+Workflow:
 
-1. 先定位最小可复现路径
-2. 若项目存在 `design-system/<project>/pages/<page>.md`，先读取页面 override；再读取对应 `design-system/<project>/MASTER.md`
-3. 检查组件结构和样式来源
-4. 追踪问题来自 markup、CSS、Token、状态还是数据
-5. 给出最小且稳妥的修复方案
-6. 修改后进行验证
+1. First locate the minimum reproducible path
+2. If the project exists `design-system/<project>/pages/<page>.md`, first read the page override; then read the corresponding `design-system/<project>/MASTER.md`
+3. Check component structure and style sources
+4. Track whether the problem comes from markup, CSS, Token, state or data
+5. Provide minimal and stable repair solution
+6. Verify after modification
 
-如果局部修复已足够，不要进行大范围重写。
+Don't do a major rewrite if local fixes are enough.
 
-## 检查流程
+## Check process
 
-1. 从可用的设计工具获取设计数据（颜色、字体、间距、尺寸）
-   - Figma / MasterGo / Pixso / 墨刀：通过 MCP 获取结构化数据
-   - Sketch：通过 MCP 获取选区截图
-   - 摹客：从用户提供的截图或标注中获取
-2. 读取对应的实现代码
-3. 如果存在设计系统文档，确认实现是否遵守 Master 与页面 override 的产品类型、token、图表、动效和 QA 规则
-4. 逐项对比以下维度:
+1. Obtain design data (color, font, spacing, size) from available design tools
+   - Figma / MasterGo / Pixso / Mo Dao: Get structured data through MCP
+   - Sketch: Get a screenshot of the selection through MCP
+   - Mocke: Obtained from screenshots or annotations provided by users
+2. Read the corresponding implementation code
+3. If a design system document exists, confirm whether the implementation complies with the product type, token, chart, animation and QA rules of Master and page override
+4. Compare the following dimensions item by item:
 
-| 维度      | 权重 | 检查内容                            |
+| Dimensions | Weight | Check content |
 | --------- | ---- | ----------------------------------- |
-| 颜色      | 25%  | 背景色、文字色、边框色与 token 对应 |
-| 间距      | 25%  | padding/margin/gap 与设计一致       |
-| 字体      | 20%  | 字号、字重、行高、字间距            |
-| 尺寸      | 15%  | 组件宽高、图标尺寸                  |
-| 圆角/阴影 | 10%  | border-radius、box-shadow           |
-| 响应式    | 5%   | 各断点布局正确                      |
+| Color | 25% | Background color, text color, and border color correspond to token |
+| Spacing | 25% | padding/margin/gap consistent with design |
+| Font | 20% | Font size, font weight, line height, font spacing |
+| Size | 15% | Component width and height, icon size |
+| rounded corners/shadow | 10% | border-radius, box-shadow |
+| Responsive | 5% | Each breakpoint is laid out correctly |
 
-若任务不是设计稿还原，而是产品化 UI 质量检查，还需要补充评估：
+If the task is not to restore the design draft, but to inspect the quality of the productized UI, additional evaluation is required:
 
-- 首屏主体是否明确，是否直接支撑核心任务
-- 视觉锚点是否贴合业务，而不是通用装饰
-- 字体层级、色彩角色、动效节奏和背景质感是否一致
-- 是否存在默认紫色渐变、空泛 hero、卡片堆叠、单一色相或无语境字体等模板化痕迹
-- 是否忽略 `design-system/MASTER.md` 或页面 override 中已定义的行业风险、图表选择、状态覆盖和交付前 QA
+- Whether the subject of the first screen is clear and whether it directly supports the core tasks
+- Whether the visual anchor is relevant to the business rather than a general decoration
+- Whether the font level, color roles, animation rhythm and background texture are consistent
+- Are there any traces of templating such as default purple gradient, empty hero, card stacking, single hue or non-contextual fonts?
+- Whether to ignore industry risks, chart selection, status overrides and pre-delivery QA defined in `design-system/MASTER.md` or page override
 
-## 输出格式
+## Output format
 
 ```
-# 设计还原度报告
+# Design restoration report
 
-> 生成时间: 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
 
-**总体得分**: XX/100
+**Overall Score**: XX/100
 
-## 颜色 (XX/25)
-✅ 背景色: --color-bg-primary 正确
-❌ 按钮色: 使用了 #3B82F6，应为 --color-brand-500
+## Color (XX/25)
+✅ Background color: --color-bg-primary correct
+❌ Button color: used #3B82F6, should be --color-brand-500
 
-## 间距 (XX/25)
+## Spacing (XX/25)
 ...
 
-## 字体 (XX/20)
+## Font (XX/20)
 ...
 
-## 尺寸 (XX/15)
+## Size (XX/15)
 ...
 
-## 圆角/阴影 (XX/10)
+## Rounded Corners/Shadow (XX/10)
 ...
 
-## 响应式 (XX/5)
+## Responsive (XX/5)
 ...
 
-## 需要调整的项目（按优先级）
+## Items that need adjustment (by priority)
 1. ...
 ```
 
-## 报告文件输出
+## Report file output
 
-检查完成后，必须将报告内容使用 Write 工具保存为 Markdown 文件：
+After the check is completed, the report content must be saved as a Markdown file using the Write tool:
 
-- 目录：项目根目录下的 `reports/`（如不存在则创建）
-- 文件名：`ui-fidelity-review-YYYY-MM-DD-HHmmss.md`（使用当前时间戳）
-- 保存后告知用户报告文件路径
+- Directory: `reports/` in the project root directory (create it if it does not exist)
+- Filename: `ui-fidelity-review-YYYY-MM-DD-HHmmss.md` (use current timestamp)
+- Inform the user of the report file path after saving

package/commands/fec-debug.md

@@ -1,30 +1,30 @@
 ---
 name: fec-debug
-description: 前端问题诊断与修复：覆盖构建失败、运行时错误、UI 异常、接口问题，使用统一诊断框架按类型分流。
+description: "Front-end problem diagnosis and repair: covering build failures, runtime errors, UI exceptions, and interface problems, using a unified diagnostic framework to classify problems by type."
 ---
 
-按 `fec-debug-framework` 执行前端问题诊断与修复。先分类问题类型（build / runtime / ui / api），再进入对应诊断模块执行 5 步法（分类→收集→假设→验证→修复）。复杂或跨类型问题可委托 **`fec-debugger`** 子代理。
+Press `fec-debug-framework` to perform front-end problem diagnosis and repair. First classify the problem type (build/runtime/ui/api), and then enter the corresponding diagnosis module to perform the 5-step method (classification → collection → hypothesis → verification → repair). Complex or cross-type issues can be delegated to the **`fec-debugger`** subagent.
 
-## 问题类型速查
+## Question type quick check
 
-| 类型    | 典型场景                                        |
+| Type | Typical Scenario |
 | ------- | ----------------------------------------------- |
-| build   | lint/type-check/test/build/CI 失败              |
-| runtime | JS 异常、白屏、组件渲染错误、路由异常、状态丢失 |
-| ui      | 样式错位、交互异常、动画卡顿、响应式问题        |
-| api     | 请求失败、超时、数据不一致、CORS、缓存问题      |
+| build | lint/type-check/test/build/CI failed |
+| runtime | JS exception, white screen, component rendering error, routing exception, state loss |
+| ui | style misalignment, abnormal interaction, animation lag, responsiveness issues |
+| api | Request failure, timeout, data inconsistency, CORS, cache issues |
 
-## 执行步骤
+## Execution steps
 
-1. 读取用户描述的问题，按 `fec-debug-framework` Step 1 分类问题类型。
-2. 进入对应诊断模块，执行 Step 2 收集证据。
-3. 基于证据提出假设（Step 3），逐一验证（Step 4）。
-4. 确认根因后执行最小修复（Step 5），运行受影响验证命令。
-5. 输出诊断报告到 `reports/debug-YYYY-MM-DD-HHmmss.md`。
+1. Read the problems described by users and classify the problem types according to `fec-debug-framework` Step 1.
+2. Enter the corresponding diagnostic module and perform Step 2 to collect evidence.
+3. Propose hypotheses based on evidence (Step 3) and verify them one by one (Step 4).
+4. After confirming the root cause, perform minimal repair (Step 5) and run the affected verification command.
+5. Output the diagnostic report to `reports/debug-YYYY-MM-DD-HHmmss.md`.
 
-## 强约束
+##Strong constraints
 
-- 不通过关闭规则、删除测试或降低类型安全来「修复」问题
-- 不顺手重构无关代码
-- 不在缺少证据时猜测根因
-- 修复后必须验证，不能只改不测
+- Don't "fix" the problem by turning off rules, removing tests, or reducing type safety
+- Not easily refactoring irrelevant code
+- Don't guess at root cause when evidence is lacking
+- It must be verified after repairing, you cannot just change it for accidents

package/commands/fec-doc-sync.md

@@ -1,19 +1,19 @@
 ---
 name: fec-doc-sync
-description: 从代码和项目事实源同步 README、docs、环境变量、脚本、API/路由/组件说明和部署说明。
+description: Sync README, docs, environment variables, scripts, API/routing/component descriptions and deployment instructions from code and project sources of truth.
 ---
 
-按 `fec-doc-sync` 同步前端工程文档。复杂多语言更新可委托 **`fec-doc-updater`**。
+Press `fec-doc-sync` to synchronize front-end project documents. Complex multi-language updates can be delegated to **`fec-doc-updater`**.
 
-## 执行步骤
+## Execution steps
 
-1. 读取事实来源：`package.json`、lockfile、config、`.env.example`、路由、API clients/server routes、types/schemas、组件、测试、CI、build/deploy config。
-2. 比对 README、docs、ADR、changelog、example prompts、setup/deploy/env docs。
-3. 更新稳定的命令、环境变量、路由/API 行为、组件说明、部署步骤、版本约束和迁移说明。
-4. 多语言文档保持关键信息一致。
-5. 当目标仓库本身是 skill/agent/command 分发仓库时，也同步能力表、metadata、runtime docs 和 marketplace 描述。
-6. 运行文档一致性、typecheck、测试、构建或相关打包检查。
+1. Read sources of truth: `package.json`, lockfile, config, `.env.example`, routes, API clients/server routes, types/schemas, components, tests, CI, build/deploy config.
+2. Compare README, docs, ADR, changelog, example prompts, setup/deploy/env docs.
+3. Update stable commands, environment variables, routing/API behavior, component descriptions, deployment steps, version constraints, and migration instructions.
+4. Keep key information consistent across multi-language documents.
+5. When the target warehouse itself is a skill/agent/command distribution warehouse, the capability table, metadata, runtime docs and marketplace description are also synchronized.
+6. Run document consistency, typecheck, test, build or related packaging checks.
 
-## 输出要求
+## Output requirements
 
-总结更新范围、事实来源、验证命令和仍需人工校对的翻译风险。
+Summarize update scope, sources of fact, verification orders and translation risks that still require manual proofreading.

package/commands/fec-init.md

@@ -1,40 +1,40 @@
 ---
 name: fec-init
-description: 按当前 AI runtime 初始化 frontend-craft 项目模板、rules 或降级说明。
+description: Initialize frontend-craft project template, rules or downgrade instructions according to the current AI runtime.
 ---
 
-将 frontend-craft 提供的项目模板复制到当前项目对应 runtime 的配置目录中。优先根据当前目录已有配置判断 runtime；无法判断时，按用户正在使用的工具选择。
+Copy the project template provided by frontend-craft to the configuration directory corresponding to the runtime of the current project. Priority will be given to judging the runtime based on the existing configuration in the current directory; if it cannot be judged, it will be selected based on the tool the user is using.
 
-## 执行步骤
+## Execution steps
 
-1. 检测 runtime：
-   - 存在 `.claude/` 或 Claude Code 插件环境 → `claude`
-   - 存在 `.codex/` 或 `AGENTS.md` → `codex`
-   - 存在 `.openclaw/`、`OPENCLAW-CONFIG.md` 或 `openclaw.plugin.json` → `openclaw`
-   - 存在 `.qoder/`、`.qoder/settings.json`、`.qoder/rules/` 或 `.qoder/skills/` → `qoder`
-   - 存在 `.cursor/` → `cursor`
-   - 存在 `.windsurf/` → `windsurf`
-   - 存在 `.opencode/` → `opencode`
-   - 存在 `.kilo/` → `kilo`
-   - 存在 `.gemini/` 或 `GEMINI.md` → `gemini`
-   - 存在 `.github/copilot-instructions.md` 或 `.github/instructions/` → `copilot`
-   - 存在 `.trae/`、`.augment/`、`.codebuddy/`、`.clinerules` 时按对应 runtime 处理
-   - 仍无法判断时，询问用户当前要初始化的 runtime。
+1. Detect runtime:
+   - Existence of `.claude/` or Claude Code plug-in environment → `claude`
+   - `.codex/` or `AGENTS.md` exists → `codex`
+   - Existence of `.openclaw/`, `OPENCLAW-CONFIG.md` or `openclaw.plugin.json` → `openclaw`
+   - Existence of `.qoder/`, `.qoder/settings.json`, `.qoder/rules/` or `.qoder/skills/` → `qoder`
+   - exists `.cursor/` → `cursor`
+   - exists `.windsurf/` → `windsurf`
+   - exists `.opencode/` → `opencode`
+   - exists `.kilo/` → `kilo`
+   - exists `.gemini/` or `GEMINI.md` → `gemini`
+   - Exist `.github/copilot-instructions.md` or `.github/instructions/` → `copilot`
+   - When `.trae/`, `.augment/`, `.codebuddy/`, `.clinerules` exist, they will be processed according to the corresponding runtime
+   - When still unable to determine, ask the user for the runtime currently to be initialized.
 
-2. 按 runtime 初始化，不要在未确认时覆盖已有文件：
-   - `claude`：复制 Claude 模板、hooks、commands、agents、skills 与 shared rules 到 `.claude/`；如 `.claude/CLAUDE.md` 已存在，先确认。
-   - `codex`：复制 `templates/codex/AGENTS.md` 到项目根目录（如不存在）、`templates/codex/config.toml` 到 `.codex/config.toml`、shared rules 到 `.codex/rules/`；skills/agents 应由 CLI 安装流程负责。
-   - `openclaw`：复制 `templates/openclaw/*.md` 到项目根目录、commands/skills 到 `.openclaw/`；如文件已存在，先确认。
-   - `qoder`：复制 skills 到 `.qoder/skills/`、commands 到 `.qoder/commands/`、agents 到 `.qoder/agents/`、shared rules 到 `.qoder/rules/`、hook scripts 到 `.qoder/hooks/`，并生成或合并 `.qoder/settings.json` 的 hooks 配置。
-   - `cursor`：复制 shared rules 到 `.cursor/rules/*.mdc`，保留 `fec-` skills 目录；说明 Cursor 不支持本插件 hooks。
-   - `windsurf`：复制 commands 到 `.windsurf/workflows/`、shared rules 到 `.windsurf/rules/`、skills 到 `.windsurf/skills/`。
-   - `opencode` / `kilo`：复制 commands 到 `.opencode/command/` 或 `.kilo/command/`，skills 到对应 `skills/`；OpenCode 可补 `.opencode/opencode.jsonc`。
-   - `gemini`：复制 skills 到 `.gemini/extensions/frontend-craft/skills/`，如无 `GEMINI.md` 则由 Claude 模板改写生成。
-   - `copilot`：合并 shared rules 到 `.github/instructions/frontend-craft.instructions.md`，commands 到 `.github/prompts/`。
-   - `trae` / `cline`：只写入规则 bundle，并明确这是 rules-only 降级模式。
-   - `antigravity` / `augment` / `codebuddy`：只安装 skills；输出“此 runtime 当前无 commands/hooks 原生适配”。
+2. Initialize by runtime, do not overwrite existing files without confirmation:
+   - `claude`: Copy Claude templates, hooks, commands, agents, skills and shared rules to `.claude/`; if `.claude/CLAUDE.md` already exists, confirm first.
+   - `codex`: Copy `templates/codex/AGENTS.md` to the project root (if it does not exist), `templates/codex/config.toml` to `.codex/config.toml`, shared rules to `.codex/rules/`; skills/agents should be taken care of by the CLI installation process.
+   - `openclaw`: Copy `templates/openclaw/*.md` to the project root directory and commands/skills to `.openclaw/`; if the file already exists, confirm first.
+   - `qoder`: Copy skills to `.qoder/skills/`, commands to `.qoder/commands/`, agents to `.qoder/agents/`, shared rules to `.qoder/rules/`, hook scripts to `.qoder/hooks/`, and generate or merge the hooks configuration of `.qoder/settings.json`.
+   - `cursor`: Copy shared rules to `.cursor/rules/*.mdc`, retain the `fec-` skills directory; Note that Cursor does not support hooks of this plug-in.
+   - `windsurf`: Copy commands to `.windsurf/workflows/`, shared rules to `.windsurf/rules/`, and skills to `.windsurf/skills/`.
+   - `opencode` / `kilo`: Copy commands to `.opencode/command/` or `.kilo/command/`, and skills to the corresponding `skills/`; OpenCode can complement `.opencode/opencode.jsonc`.
+   - `gemini`: Copy skills to `.gemini/extensions/frontend-craft/skills/`. If there is no `GEMINI.md`, it will be generated by rewriting the Claude template.
+   - `copilot`: merge shared rules into `.github/instructions/frontend-craft.instructions.md`, commands into `.github/prompts/`.
+   - `trae` / `cline`: Write only rules bundles, and make it clear that this is rules-only downgrade mode.
+   - `antigravity` / `augment` / `codebuddy`: only install skills; output "This runtime currently has no commands/hooks native adaptation".
 
-3. Claude runtime 下，将以下模板文件从插件的 `${FRONTEND_CRAFT_ROOT}/templates/claude/` 与 `${FRONTEND_CRAFT_ROOT}/templates/shared/rules/` 复制到项目根目录的 `.claude/`：
+3. Under Claude runtime, copy the following template files from the plug-in's `${FRONTEND_CRAFT_ROOT}/templates/claude/` and `${FRONTEND_CRAFT_ROOT}/templates/shared/rules/` to `.claude/` in the project root directory:
    - `templates/claude/CLAUDE.md` → `.claude/CLAUDE.md`
    - `templates/claude/settings.json` → `.claude/settings.json`
    - `templates/shared/rules/fec-vue.md` → `.claude/rules/fec-vue.md`
@@ -48,8 +48,7 @@ description: 按当前 AI runtime 初始化 frontend-craft 项目模板、rules
    - `templates/shared/rules/fec-responsive-design.md` → `.claude/rules/fec-responsive-design.md`
    - `templates/shared/rules/fec-rendering-patterns.md` → `.claude/rules/fec-rendering-patterns.md`
    - `templates/shared/rules/fec-api-layer.md` → `.claude/rules/fec-api-layer.md`
-   - `templates/shared/rules/fec-state-management.md` → `.claude/rules/fec-state-management.md`
-   - `templates/shared/rules/fec-error-handling.md` → `.claude/rules/fec-error-handling.md`
+   - `templates/shared/rules/fec-state-management.md` → `.claude/rules/fec-state-management.md`- `templates/shared/rules/fec-error-handling.md` → `.claude/rules/fec-error-handling.md`
    - `templates/shared/rules/fec-naming-conventions.md` → `.claude/rules/fec-naming-conventions.md`
    - `templates/shared/rules/fec-typescript.md` → `.claude/rules/fec-typescript.md`
    - `templates/shared/rules/fec-code-comments.md` → `.claude/rules/fec-code-comments.md`
@@ -58,13 +57,13 @@ description: 按当前 AI runtime 初始化 frontend-craft 项目模板、rules
    - `templates/shared/rules/fec-agent-workflow.md` → `.claude/rules/fec-agent-workflow.md`
    - `templates/shared/rules/fec-working-modes.md` → `.claude/rules/fec-working-modes.md`
 
-4. 复制完成后，不要只输出提醒。先检查项目根目录中的 `package.json`、常见框架配置文件和 `.github/workflows/`，推断适用规则，然后向用户提供初始化后配置选项：
-   - 推荐：自动检测并裁剪规则（默认推荐项）。根据检测结果展示建议保留和建议移除的规则，用户确认后再修改 `.claude/CLAUDE.md` 底部的规则导入部分。
-   - 手动选择要保留的规则。列出已复制的规则文件，让用户选择要保留的规则，再按选择更新 `.claude/CLAUDE.md`。
-   - 暂不调整，仅输出清单。保持复制结果不变，只输出初始化完成信息、文件清单和后续建议。
+4. Don’t just output a reminder after copying is complete. First check `package.json`, common framework configuration files and `.github/workflows/` in the project root directory, infer applicable rules, and then provide post-initialization configuration options to the user:
+   - Recommendation: Automatically detect and tailor rules (default recommendation). The rules recommended to be retained and recommended to be removed are displayed based on the detection results. The user can modify the rule import section at the bottom of `.claude/CLAUDE.md` after confirmation.
+   - Manually select rules to keep. List the copied rule files, let the user select the rules to keep, and then press Select to update `.claude/CLAUDE.md`.
+   - No adjustments for now, only output list. Keep the copy results unchanged and only output the initialization completion information, file list and follow-up suggestions.
 
-   推荐项的判断应保持保守：只自动建议移除明显不匹配的规则，例如纯 React 项目移除 `@./rules/fec-vue.md`、纯 Vue 项目移除 `@./rules/fec-react.md`、无 TypeScript/JavaScript 源码时移除 `@./rules/fec-typescript.md`。对 `@./rules/fec-i18n.md`、`@./rules/fec-ci-cd.md`、`@./rules/fec-refactoring.md` 这类依赖项目上下文的规则，优先展示为建议项并说明依据；无法确定时默认保留。
+   The judgment of recommended items should be conservative: only automatically recommend the removal of obviously mismatched rules, such as removing `@./rules/fec-vue.md` for pure React projects, removing `@./rules/fec-react.md` for pure Vue projects, and removing `@./rules/fec-typescript.md` when there is no TypeScript/JavaScript source code. For rules such as `@./rules/fec-i18n.md`, `@./rules/fec-ci-cd.md`, and `@./rules/fec-refactoring.md` that depend on the project context, priority is given to displaying them as suggestions and explaining the basis; if they cannot be determined, they are retained by default.
 
-   如果当前运行环境支持结构化提问工具，使用选择题形式提问，并明确标注推荐项；否则使用编号选项。用户选择并确认前，不要修改 `.claude/CLAUDE.md` 的规则导入部分。完成裁剪或用户选择暂不调整后，再提醒用户根据项目实际情况修改 `CLAUDE.md` 的项目基础信息、常用命令、`rules/fec-react.md` 或 `rules/fec-vue.md` 中的技术栈配置，并检查 `settings.json` 中的权限列表是否符合项目需求。
+   If the current operating environment supports structured questioning tools, use multiple-choice questions and clearly mark recommended items; otherwise, use numbered options. Do not modify the rule import part of `.claude/CLAUDE.md` before the user selects and confirms it. After the trimming is completed or the user chooses not to adjust it temporarily, the user is reminded to modify the basic project information, common commands, `rules/fec-react.md` or `rules/fec-vue.md` according to the actual situation of the project, and check whether the permission list in `settings.json` meets the project requirements.
 
-5. 输出初始化完成的确认信息和文件清单。
+5. Output the confirmation information and file list of initialization completion.

package/commands/fec-plan.md

@@ -1,94 +1,94 @@
 ---
 name: fec-plan
-description: 统一前端规划入口——实现/架构计划或测试策略。默认走实施路径；当用户明确要测试计划、覆盖矩阵、测试分层、risk-to-test 等时，输出完整测试策略。
+description: Unified front-end planning entrance - implementation/architecture plan or testing strategy. The implementation path is taken by default; when the user clearly wants test plan, coverage matrix, test layering, risk-to-test, etc., the complete test strategy is output.
 ---
 
-在改代码前创建前端计划。根据用户意图自动分流到实施规划或测试规划。
+Create a front-end plan before changing the code. Automatically divert traffic to implementation planning or test planning based on user intent.
 
-## 意图识别
+## Intent recognition
 
-- **实施规划**（默认）：用户要拆组件、设计数据流、安排目录结构、迁移步骤、架构方案。
-- **测试规划**：用户明确说"测试计划"、"测试策略"、"覆盖矩阵"、"测试分层"、"测什么"、"risk-to-test"等。
-- **混合**：用户同时有实施和测试诉求。
+- **Implementation Planning** (default): Users need to dismantle components, design data flows, arrange directory structures, migration steps, and architecture plans.
+- **Test Planning**: The user clearly states "test plan", "test strategy", "coverage matrix", "test layering", "what to test", "risk-to-test", etc.
+- **Mixed**: Users have both implementation and testing requirements.
 
-若意图不清，先问用户想看实施计划还是测试策略。
+If the intention is unclear, first ask the user if they want to see the implementation plan or test strategy.
 
-## 实施规划路径
+## Implementation planning path
 
-1. 重述用户目标、成功标准和不在范围内的内容。
-2. 阅读相关代码、模板、规则、配置、测试和已有实现，避免脱离项目现状。
-3. 若涉及页面拆分、状态流、目录结构、数据流或大型重构，委托 **`fec-architect`**。
-4. 输出计划：
-   - 影响范围
-   - 关键文件或模块
-   - 架构与模块边界
-   - 数据流 / 状态流 / API 交互
-   - 实施阶段
-   - 回滚或渐进迁移策略
-   - 风险与缓解
-   - 最小验证门禁（lint、type-check、test、build、E2E 或人工验收）
-5. 对版本敏感、依赖升级或外部库相关决策，列出事实来源、版本范围、迁移影响和需要查证的文档。
-6. 在用户确认前不执行实现。
+1. Restate user goals, success criteria, and out-of-scope content.
+2. Read relevant codes, templates, rules, configurations, tests and existing implementations to avoid deviating from the current status of the project.
+3. If it involves page splitting, state flow, directory structure, data flow or large-scale reconstruction, entrust **`fec-architect`**.
+4. Output plan:
+   - Scope of influence
+   - Key files or modules
+   - Architecture and module boundaries
+   - Data flow/state flow/API interaction
+   - Implementation phase
+   - Rollback or gradual migration strategy
+   - Risks and Mitigation
+   - Minimal verification access (lint, type-check, test, build, E2E or manual acceptance)
+5. For decisions related to version sensitivity, dependency upgrades or external libraries, list the source of fact, version range, migration impact and documents that need to be verified.
+6. Implementation is not performed until user confirmation.
 
-实施规划保存到 `reports/architecture-proposal-YYYY-MM-DD-HHmmss.md`。
+The implementation plan is saved to `reports/architecture-proposal-YYYY-MM-DD-HHmmss.md`.
 
-## 测试规划路径
+## Test planning path
 
-1. 确定范围：
-   - 用户指定功能、PR、文件或业务流程时，以该范围为准。
-   - 用户未指定时，查看最近变更并推断主要风险面。
-   - 若用户要的是模块拆分、状态流、目录结构或迁移步骤，回到实施规划路径。
+1. Determine the scope:
+   - When users specify functions, PRs, files or business processes, this scope shall prevail.
+   - When not specified by the user, view recent changes and infer the main risk areas.
+   - If the user wants module splitting, state flow, directory structure or migration steps, return to the implementation planning path.
 
-2. 使用 `fec-testing-strategy` Skill 建立测试分层矩阵：
-   - 静态检查
-   - 单元测试
-   - 组件测试
-   - 轻量集成测试
-   - E2E 测试
-   - 视觉 / Storybook / interaction
-   - a11y / 安全 / 性能等专项质量验证
+2. Use the `fec-testing-strategy` Skill to create a test layering matrix:
+   - Static checking
+   - unit testing
+   - Component testing
+   - Lightweight integration testing
+   - E2E testing
+   - Visual/Storybook/interaction
+   - a11y / safety / performance and other special quality verification
 
-3. 对每个风险给出建议测试层、优先级、建议命令、责任 skill 和失败定位证据。
+3. Provide recommended test layers, priorities, recommended commands, responsibility skills and failure location evidence for each risk.
 
-4. 标明哪些风险只需要现有门禁覆盖，哪些需要新增测试，哪些暂不覆盖并说明原因。
+4. Indicate which risks only need to be covered by existing access control, which ones need new testing, and which ones are not covered yet and explain the reasons.
 
-5. 必要时委托 **`fec-test-planner`** 子代理生成独立测试计划。
+5. Delegate the **`fec-test-planner`** subagent to generate independent test plans when necessary.
 
-6. 将计划保存到 `reports/test-plan-YYYY-MM-DD-HHmmss.md`：
+6. Save the plan to `reports/test-plan-YYYY-MM-DD-HHmmss.md`:
 
    ```markdown
-   # 前端测试计划
+   # Front-end test plan
 
-   > 生成时间: YYYY-MM-DD HH:mm
-   > 范围: ...
+   > Generation time: YYYY-MM-DD HH:mm
+   > Scope: ...
 
-   ## 风险概览
+   ## Risk Overview
 
    | Risk | Impact | Suggested Layer | Priority | Evidence |
    | ---- | ------ | --------------- | -------- | -------- |
 
-   ## 覆盖矩阵
+   ## Covering matrix
 
    | Layer | What to Cover | Tooling / Command | Skill |
-   | ----- | ------------- | ----------------- | ----- |
+   | ----- | ------------- | ------------------ | ----- |
 
-   ## 执行顺序
+   ## Execution order
 
-   ## 不覆盖项与原因
+   ## Items not covered and reasons
    ```
 
-7. 若用户要求继续实现测试，按矩阵分流到对应专项 skill 或 agent。
+7. If the user requires to continue to implement the test, it will be diverted to the corresponding special skill or agent according to the matrix.
 
-## 混合路径
+## Mixed paths
 
-当用户同时需要实施计划和测试策略时：
+When users need to implement plans and test strategies at the same time:
 
-1. 先输出完整实施规划。
-2. 在实施规划末尾追加"测试策略"章节，列出关键风险对应的测试层级和验证门禁。
-3. 只有用户明确要求完整覆盖矩阵时，才额外生成 `test-plan-*` 独立报告。
+1. First output the complete implementation plan.
+2. Add a "Testing Strategy" chapter to the end of the implementation plan to list the testing levels and verification access controls corresponding to key risks.
+3. Additional `test-plan-*` independent reports will only be generated if the user explicitly requests complete coverage matrix.
 
-## 边界
+## Boundary
 
-- 不在计划阶段直接写代码，除非用户明确要求继续实现。
-- 不默认要求补齐完整测试金字塔，只按风险和维护成本选择覆盖。
-- 不负责大规模编写测试文件；用户明确要求落地时再分流到专项测试 skill。
+- Do not write code directly in the planning stage unless the user explicitly requests to continue implementation.
+- It is not required by default to complete the complete test pyramid, and coverage is only selected based on risk and maintenance cost.
+- Not responsible for large-scale writing of test files; when users clearly require implementation, they will be diverted to special testing skills.

package/commands/fec-refactor-clean.md

@@ -1,19 +1,19 @@
 ---
 name: fec-refactor-clean
-description: 在验证保护下识别并清理前端死代码、未使用导出、过期组件、样式和依赖。
+description: Identify and clean up front-end dead code, unused exports, outdated components, styles and dependencies under validation protection.
 ---
 
-按 `fec-refactor-clean` 执行安全清理。复杂清理可委托 **`fec-refactor-cleaner`**。
+Press `fec-refactor-clean` to perform a safe clean. Complex cleanup can be delegated to **`fec-refactor-cleaner`**.
 
-## 执行步骤
+## Execution steps
 
-1. 建立当前验证基线。
-2. 使用仓库已有工具或 `rg` 收集未使用候选项。
-3. 检查动态引用、路由、barrel export、Storybook、测试和样式入口。
-4. 将候选项分为 SAFE、CAUTION、DANGER。
-5. 仅清理 SAFE 项；其他项输出建议和证据。
-6. 每批清理后重新运行受影响验证命令。
+1. Establish the current verification baseline.
+2. Use existing tools in the warehouse or `rg` to collect unused candidates.
+3. Check dynamic references, routing, barrel export, Storybook, test and style entry.
+4. Divide the candidates into SAFE, CAUTION, and DANGER.
+5. Only clean SAFE items; other items output suggestions and evidence.
+6. Rerun the affected verification commands after each batch cleanup.
 
-## 输出要求
+## Output requirements
 
-将清理报告保存到 `reports/refactor-clean-YYYY-MM-DD-HHmmss.md`。
+Save the clean report to `reports/refactor-clean-YYYY-MM-DD-HHmmss.md`.

package/commands/fec-refactor-plan.md

@@ -0,0 +1,17 @@
+---
+name: fec-refactor-plan
+description: Build an ordered behavior-preserving frontend refactoring plan from evidence without editing business code.
+---
+
+This command is **PLAN ONLY**. Do not edit business code.
+
+## Workflow
+
+1. Validate current project facts and any supplied smell diagnosis.
+2. Record the observable behavior contract and available verification baseline.
+3. Select the smallest candidate technique whose preconditions fit each diagnosed cause.
+4. Order only necessary prerequisites and keep each step independently verifiable.
+5. Classify every step `SAFE`, `CAUTION`, or `DANGER`.
+6. For every step include: target, technique, intent, dependency/order reason, preconditions, risk, expected files/functions, expected observable behavior change (`NONE`), verification command/method, and rollback boundary.
+7. Include a Diff Budget and stop conditions.
+8. Save the result to `reports/refactoring/plan-YYYY-MM-DD-HHmmss.md`.

package/commands/fec-refactor.md

@@ -0,0 +1,18 @@
+---
+name: fec-refactor
+description: Execute controlled behavior-preserving frontend refactoring with small steps, verification, rollback, and proof reporting.
+---
+
+Execute a pure structural refactoring under a recorded behavior contract.
+
+## Workflow
+
+1. Classify the request and redirect feature work, unknown bugs, migrations, dead-code cleanup, or general review when they own the task.
+2. Discover project facts and establish the existing validation baseline.
+3. If no plan is supplied, diagnose evidence and build an ordered plan first. If a plan is supplied, revalidate it against the current code.
+4. Record risk and Diff Budget. `DANGER` stops for explicit approval unless the specific compatibility plan is already authorized.
+5. Execute **one refactoring step** with one primary structural intent.
+6. Immediately run the narrowest sufficient verification and inspect actual scope.
+7. If the step causes a new regression, revert that step before attempting a smaller or different transformation.
+8. Repeat only after the current step is green and within budget.
+9. Run final broad validation and save `reports/refactoring/refactoring-YYYY-MM-DD-HHmmss.md` with a `PASS`, `PARTIAL`, or `NOT PROVEN` behavior-preservation verdict.