@bovinphang/frontend-craft 2.7.0 → 2.8.0

package/skills/relations.json

@@ -204,6 +204,7 @@
     ],
     "boundaryWorkflows": [
       "Use image generation for raster-first posters, visual concepts, product images, and PNG QA beyond editable technical diagrams.",
+      "Use image generation's HTML technical diagram route when the priority is a browser-ready themed single-file workflow, sequence, data-flow, or lifecycle diagram.",
       "Use Canvas/Three.js when the diagram becomes an interactive runtime visualization, simulation, game scene, shader, or 3D renderer.",
       "Use SVG animation for motion-specific vector micro-interactions; use drawio studio for static or editable technical SVG exports."
     ],
@@ -264,12 +265,15 @@
     "boundaryWorkflows": [
       "Use UI design for product-specific visual direction, brand tone, hierarchy, and visual QA of generated assets.",
       "Use implementation-from-design when a Figma, Sketch, MasterGo, Pixso, screenshot, or other external design source is authoritative.",
+      "Use the HTML technical diagram route for browser-ready themed workflow, sequence, data-flow, lifecycle, runbook, PII/data-lineage, and state-machine diagrams.",
+      "Use draw.io studio instead when the priority is editable .drawio source, official shape lookup, or manual diagrams.net editing.",
       "Use Canvas/Three.js or SVG animation workflows when the generated visual becomes an interactive renderer, shader, or motion asset rather than a static image."
     ],
     "capabilityTags": [
       "image-generation",
       "image-editing",
       "diagram-generation",
+      "html-diagram",
       "png-qa",
       "visual-assets",
       "autofix"

package/templates/claude/CLAUDE.md

@@ -1,91 +1,91 @@
-# 项目说明
+# Project description
 
-本仓库由前端团队维护。
+This repository is maintained by the front-end team.
 
-核心要求：
+Core requirements:
 
-- 在调整架构前，先理解现有代码
-- 优先复用，而不是重复造轮子
-- 保持改动小、清晰、便于评审
-- 先遵循项目标准，再考虑通用模式
+- Understand the existing code before adjusting the architecture
+- Prioritize reuse rather than reinventing the wheel
+- Keep changes small, clear, and easy to review
+- Follow project standards first, then consider common patterns
 
-## 项目基础信息
+##Basic project information
 
-<!-- 请根据项目实际情况修改以下配置 -->
+<!-- Please modify the following configuration according to the actual situation of the project -->
 
-- 语言：TypeScript
-- 包管理器：pnpm
-- 构建工具：Vite
-- 测试工具: Vitest + Testing Library
-- UI 体系：优先复用现有组件库和设计 Token
-- 设计实现流程：如有条件，优先使用设计工具 MCP（Figma / MasterGo / Pixso / 墨刀 / Sketch）上下文
+- Language: TypeScript
+- Package manager: pnpm
+- Build tool: Vite
+- Testing tools: Vitest + Testing Library
+- UI system: Prioritize reusing existing component libraries and design tokens
+- Design implementation process: If possible, give priority to using the design tool MCP (Figma / MasterGo / Pixso / Mo Knife / Sketch) context
 
-## 常用命令
+## Common commands
 
-优先使用仓库现有命令，不要自行发明替代命令。
+Prioritize using existing commands in the warehouse instead of inventing replacement commands.
 
-<!-- 请根据项目实际情况修改 -->
+<!-- Please modify according to the actual situation of the project -->
 
-- 安装：`pnpm install`
-- 开发：`pnpm dev`
+- Installation: `pnpm install`
+- Development: `pnpm dev`
 - Lint：`pnpm lint`
-- 类型检查：`pnpm type-check`
-- 测试：`pnpm test`
-- 构建：`pnpm build`
+- Type check: `pnpm type-check`
+- Test: `pnpm test`
+- Build: `pnpm build`
 
-如果命令缺失，先检查 `package.json`。
+If the command is missing, check `package.json` first.
 
-## 通用工作原则
+## General working principles
 
-改代码前：
+Before changing the code:
 
-1. 阅读目标模块及其周边模块
-2. 搜索已有可复用组件或工具函数
-3. 理解当前样式和 Token 约定
-4. 如果仓库里已有一套模式，不要再引入第二套
+1. Read the target module and its surrounding modules
+2. Search for existing reusable components or tool functions
+3. Understand the current style and Token convention
+4. If there is already a set of patterns in the warehouse, do not introduce a second set
 
-实现时：
+When implemented:
 
-- 保持组件职责聚焦
-- 将重复逻辑提取到 hooks / composables / utils
-- 优先使用明确类型
-- 优先使用可推导状态，避免重复维护状态
-- 除非任务明确要求破坏性变更，否则保持向后兼容
+- Keep component responsibilities focused
+- Extract duplicate logic to hooks/composables/utils
+- Prefer explicit types
+- Prioritize the use of deducible state to avoid repeated maintenance of state
+- Maintain backwards compatibility unless the mission explicitly requires breaking changes
 
-完成后：
+After completion:
 
-- 执行 lint
-- 如有类型检查则执行 type check
-- 如有测试则执行测试
-- 总结改动文件、关键决策和剩余风险
+- execute lint
+- If there is a type check, execute type check
+- If there is a test, execute the test
+- Summarize change documents, key decisions and remaining risks
 
-## Git 规范
+## Git specification
 
-- 提交前必须通过 lint 和类型检查
-- 未经我确认不要直接 commit
-- 分支命名: feature/xxx, fix/xxx, refactor/xxx
-- Commit 格式: 遵循 Conventional Commits（详见 rules/fec-git-conventions.md）
+- Must pass lint and type checking before submission
+- Don’t commit directly without my confirmation
+- Branch naming: feature/xxx, fix/xxx, refactor/xxx
+- Commit format: Follow Conventional Commits (see rules/fec-git-conventions.md for details)
 
-## 设计稿实现工作流
+## Design draft implementation workflow
 
-当存在设计上下文时：
+When a design context exists:
 
-1. 先通过 MCP 读取设计上下文（Figma / MasterGo / Pixso / 墨刀 / Sketch，摹客则使用截图/标注）
-2. 检查项目现有组件体系
-3. 先产出简短实现计划
-4. 分步骤实现
-5. 执行校验命令
-6. 总结偏差和风险
+1. First read the design context through MCP (Figma / MasterGo / Pixso / Ink Knife / Sketch, Mock uses screenshots / annotations)
+2. Check the existing component system of the project
+3. First produce a short implementation plan
+4. Implement in steps
+5. Execute the verification command
+6. Summarize biases and risks
 
-## 安全要求
+## Security requirements
 
-不要主动暴露或打印任何密钥。
-除非任务明确要求且权限允许，不要读取或修改敏感文件。
-除非明确要求并获得批准，不要执行破坏性 shell 命令。
+Do not actively expose or print any keys.
+Do not read or modify sensitive files unless explicitly required by the task and permitted by permissions.
+Do not execute destructive shell commands unless explicitly requested and approved.
 
-## 规则导入
+## Rule import
 
-<!-- 按项目技术栈选择性导入，删除不需要的行 -->
+<!-- Selectively import by project technology stack and delete unnecessary lines -->
 
 @./rules/fec-vue.md
 @./rules/fec-react.md

package/templates/codex/AGENTS.md

@@ -1,105 +1,105 @@
-# 项目说明
+# Project description
 
-本仓库由前端团队维护。
+This repository is maintained by the front-end team.
 
-核心要求：
+Core requirements:
 
-- 在调整架构前，先理解现有代码
-- 优先复用，而不是重复造轮子
-- 保持改动小、清晰、便于评审
-- 先遵循项目标准，再考虑通用模式
+- Understand the existing code before adjusting the architecture
+- Prioritize reuse rather than reinventing the wheel
+- Keep changes small, clear, and easy to review
+- Follow project standards first, then consider common patterns
 
-## 项目基础信息
+##Basic project information
 
-<!-- 请根据项目实际情况修改以下配置 -->
+<!-- Please modify the following configuration according to the actual situation of the project -->
 
-- 语言：TypeScript
-- 包管理器：pnpm
-- 构建工具：Vite
-- 测试工具: Vitest + Testing Library
-- UI 体系：优先复用现有组件库和设计 Token
-- 设计实现流程：如有条件，优先使用设计工具 MCP（Figma / MasterGo / Pixso / 墨刀 / Sketch）上下文
+- Language: TypeScript
+- Package manager: pnpm
+- Build tool: Vite
+- Testing tools: Vitest + Testing Library
+- UI system: Prioritize reusing existing component libraries and design tokens
+- Design implementation process: If possible, give priority to using the design tool MCP (Figma / MasterGo / Pixso / Mo Knife / Sketch) context
 
-## 常用命令
+## Common commands
 
-优先使用仓库现有命令，不要自行发明替代命令。
+Prioritize using existing commands in the warehouse instead of inventing replacement commands.
 
-<!-- 请根据项目实际情况修改 -->
+<!-- Please modify according to the actual situation of the project -->
 
-- 安装：`pnpm install`
-- 开发：`pnpm dev`
+- Installation: `pnpm install`
+- Development: `pnpm dev`
 - Lint：`pnpm lint`
-- 类型检查：`pnpm type-check`
-- 测试：`pnpm test`
-- 构建：`pnpm build`
+- Type check: `pnpm type-check`
+- Test: `pnpm test`
+- Build: `pnpm build`
 
-如果命令缺失，先检查 `package.json`。
+If the command is missing, check `package.json` first.
 
-## 通用工作原则
+## General working principles
 
-改代码前：
+Before changing the code:
 
-1. 阅读目标模块及其周边模块
-2. 搜索已有可复用组件或工具函数
-3. 理解当前样式和 Token 约定
-4. 如果仓库里已有一套模式，不要再引入第二套
+1. Read the target module and its surrounding modules
+2. Search for existing reusable components or tool functions
+3. Understand the current style and Token convention
+4. If there is already a set of patterns in the warehouse, do not introduce a second set
 
-实现时：
+When implemented:
 
-- 保持组件职责聚焦
-- 将重复逻辑提取到 hooks / composables / utils
-- 优先使用明确类型
-- 优先使用可推导状态，避免重复维护状态
-- 除非任务明确要求破坏性变更，否则保持向后兼容
+- Keep component responsibilities focused
+- Extract duplicate logic to hooks/composables/utils
+- Prefer explicit types
+- Prioritize the use of deducible state to avoid repeated maintenance of state
+- Maintain backwards compatibility unless the mission explicitly requires breaking changes
 
-完成后：
+After completion:
 
-- 执行 lint
-- 如有类型检查则执行 type check
-- 如有测试则执行测试
-- 总结改动文件、关键决策和剩余风险
+- execute lint
+- If there is a type check, execute type check
+- If there is a test, execute the test
+- Summarize change documents, key decisions and remaining risks
 
-## Git 规范
+## Git specification
 
-- 提交前必须通过 lint 和类型检查
-- 未经我确认不要直接 commit
-- 分支命名: feature/xxx, fix/xxx, refactor/xxx
-- Commit 格式: 遵循 Conventional Commits（详见 .codex/rules/fec-git-conventions.md）
+- Must pass lint and type checking before submission
+- Don’t commit directly without my confirmation
+- Branch naming: feature/xxx, fix/xxx, refactor/xxx
+- Commit format: Follow Conventional Commits (see .codex/rules/fec-git-conventions.md for details)
 
-## 设计稿实现工作流
+## Design draft implementation workflow
 
-当存在设计上下文时：
+When a design context exists:
 
-1. 先通过 MCP 读取设计上下文（Figma / MasterGo / Pixso / 墨刀 / Sketch，摹客则使用截图/标注）
-2. 检查项目现有组件体系
-3. 先产出简短实现计划
-4. 分步骤实现
-5. 执行校验命令
-6. 总结偏差和风险
+1. First read the design context through MCP (Figma / MasterGo / Pixso / Ink Knife / Sketch, Mock uses screenshots / annotations)
+2. Check the existing component system of the project
+3. First produce a short implementation plan
+4. Implement in steps
+5. Execute the verification command
+6. Summarize biases and risks
 
-## 安全要求
+## Security requirements
 
-不要主动暴露或打印任何密钥。
-除非任务明确要求且权限允许，不要读取或修改敏感文件。
-除非明确要求并获得批准，不要执行破坏性 shell 命令。
+Do not actively expose or print any keys.
+Do not read or modify sensitive files unless explicitly required by the task and permitted by permissions.
+Do not execute destructive shell commands unless explicitly requested and approved.
 
-## 详细规则
+## Detailed rules
 
-项目详细规则位于 `.codex/rules/` 目录，按技术栈选择性参考：
+The detailed rules of the project are located in the `.codex/rules/` directory, selective reference by technology stack:
 
-- fec-vue.md / fec-react.md - 框架组件规范
-- fec-typescript.md - TypeScript/JavaScript 规范（与 `typescript-reviewer` 子代理联动）
-- fec-design-system.md - 设计系统与 Token
-- fec-testing.md - 测试规范
-- fec-git-conventions.md - Git 提交规范
-- fec-i18n.md - 国际化规范（如需要）
-- fec-performance.md - 性能优化
-- fec-api-layer.md - API 层规范
-- fec-state-management.md - 状态管理
-- fec-error-handling.md - 错误处理
-- fec-naming-conventions.md - 命名规范
-- fec-code-comments.md - 代码注释（何时写、写什么）
-- fec-ci-cd.md - CI/CD 规范
-- fec-refactoring.md - 重构约束
-- fec-agent-workflow.md - 子代理协作边界
-- fec-working-modes.md - 调研、计划、开发、评审、收尾模式
+- fec-vue.md/fec-react.md - Framework component specification
+- fec-typescript.md - TypeScript/JavaScript specification (linked with `typescript-reviewer` subagent)
+- fec-design-system.md - Design system and Token
+- fec-testing.md - Test specification
+- fec-git-conventions.md - Git commit conventions
+- fec-i18n.md - Internationalization specification (if needed)
+- fec-performance.md - performance optimization
+- fec-api-layer.md - API layer specification
+- fec-state-management.md - State management
+- fec-error-handling.md - error handling
+- fec-naming-conventions.md - naming conventions
+- fec-code-comments.md - Code comments (when to write, what to write)
+- fec-ci-cd.md - CI/CD specification
+- fec-refactoring.md - Refactoring constraints
+- fec-agent-workflow.md - subagent collaboration boundary
+- fec-working-modes.md - research, planning, development, review, closing mode

package/templates/codex/config.toml

@@ -1,8 +1,8 @@
-# Frontend Craft - Codex 项目配置
-# 复制到 .codex/config.toml 并根据项目需要调整
+# Frontend Craft - Codex project configuration
+# Copy to .codex/config.toml and adjust according to project needs
 
-# MCP 设计工具集成（按需取消注释并配置环境变量）
-# 需要设置: FIGMA_API_KEY, SKETCH_API_KEY, MG_MCP_TOKEN, MODAO_TOKEN
+# MCP design tool integration (uncomment and configure environment variables as needed)
+# Required settings: FIGMA_API_KEY, SKETCH_API_KEY, MG_MCP_TOKEN, MODAO_TOKEN
 
 # [mcp_servers.figma]
 # command = "npx"

package/templates/openclaw/AGENTS.md

@@ -1,101 +1,101 @@
-# 项目说明
+# Project description
 
-本工作区由前端团队维护（由 **frontend-craft** OpenClaw 插件模板初始化）。
+This workspace is maintained by the frontend team (initialized by the **frontend-craft** OpenClaw plugin template).
 
-核心要求：
+Core requirements:
 
-- 在调整架构前，先理解现有代码
-- 优先复用，而不是重复造轮子
-- 保持改动小、清晰、便于评审
-- 先遵循项目标准，再考虑通用模式
+- Understand the existing code before adjusting the architecture
+- Prioritize reuse rather than reinventing the wheel
+- Keep changes small, clear, and easy to review
+- Follow project standards first, then consider common patterns
 
-## 项目基础信息
+##Basic project information
 
-<!-- 请根据项目实际情况修改以下配置 -->
+<!-- Please modify the following configuration according to the actual situation of the project -->
 
-- 语言：TypeScript
-- 包管理器：pnpm
-- 构建工具：Vite
-- 测试工具: Vitest + Testing Library
-- UI 体系：优先复用现有组件库和设计 Token
-- 设计实现流程：如有条件，优先使用设计工具 MCP（Figma / MasterGo / Pixso / 墨刀 / Sketch）上下文
+- Language: TypeScript
+- Package manager: pnpm
+- Build tool: Vite
+- Testing tools: Vitest + Testing Library
+- UI system: Prioritize reusing existing component libraries and design tokens
+- Design implementation process: If possible, give priority to using the design tool MCP (Figma / MasterGo / Pixso / Mo Knife / Sketch) context
 
-## 常用命令
+## Common commands
 
-优先使用仓库现有命令，不要自行发明替代命令。
+Prioritize using existing commands in the warehouse instead of inventing replacement commands.
 
-<!-- 请根据项目实际情况修改 -->
+<!-- Please modify according to the actual situation of the project -->
 
-- 安装：`pnpm install`
-- 开发：`pnpm dev`
+- Installation: `pnpm install`
+- Development: `pnpm dev`
 - Lint：`pnpm lint`
-- 类型检查：`pnpm type-check`
-- 测试：`pnpm test`
-- 构建：`pnpm build`
+- Type check: `pnpm type-check`
+- Test: `pnpm test`
+- Build: `pnpm build`
 
-如果命令缺失，先检查 `package.json`。
+If the command is missing, check `package.json` first.
 
-## 通用工作原则
+## General working principles
 
-改代码前：
+Before changing the code:
 
-1. 阅读目标模块及其周边模块
-2. 搜索已有可复用组件或工具函数
-3. 理解当前样式和 Token 约定
-4. 如果仓库里已有一套模式，不要再引入第二套
+1. Read the target module and its surrounding modules
+2. Search for existing reusable components or tool functions
+3. Understand the current style and Token convention
+4. If there is already a set of patterns in the warehouse, do not introduce a second set
 
-实现时：
+When implemented:
 
-- 保持组件职责聚焦
-- 将重复逻辑提取到 hooks / composables / utils
-- 优先使用明确类型
-- 优先使用可推导状态，避免重复维护状态
-- 除非任务明确要求破坏性变更，否则保持向后兼容
+- Keep component responsibilities focused
+- Extract duplicate logic to hooks/composables/utils
+- Prefer explicit types
+- Prioritize the use of deducible state to avoid repeated maintenance of state
+- Maintain backwards compatibility unless the mission explicitly requires breaking changes
 
-完成后：
+After completion:
 
-- 执行 lint
-- 如有类型检查则执行 type check
-- 如有测试则执行测试
-- 总结改动文件、关键决策和剩余风险
+- execute lint
+- If there is a type check, execute type check
+- If there is a test, execute the test
+- Summarize change documents, key decisions and remaining risks
 
-## Git 规范
+## Git specification
 
-- 提交前必须通过 lint 和类型检查
-- 未经我确认不要直接 commit
-- 分支命名: feature/xxx, fix/xxx, refactor/xxx
-- Commit 格式: 遵循 Conventional Commits（详见本文件同目录 skills 下的 `git-conventions.md`）
+- Must pass lint and type checking before submission
+- Don’t commit directly without my confirmation
+- Branch naming: feature/xxx, fix/xxx, refactor/xxx
+- Commit format: Follow Conventional Commits (for details, see `git-conventions.md` under skills in the same directory as this file)
 
-## 设计稿实现工作流
+## Design draft implementation workflow
 
-当存在设计上下文时：
+When a design context exists:
 
-1. 先通过 MCP 读取设计上下文（Figma / MasterGo / Pixso / 墨刀 / Sketch，摹客则使用截图/标注）
-2. 检查项目现有组件体系
-3. 先产出简短实现计划
-4. 分步骤实现
-5. 执行校验命令
-6. 总结偏差和风险
+1. First read the design context through MCP (Figma / MasterGo / Pixso / Ink Knife / Sketch, Mock uses screenshots / annotations)
+2. Check the existing component system of the project
+3. First produce a short implementation plan
+4. Implement in steps
+5. Execute the verification command
+6. Summarize biases and risks
 
-## 安全要求
+## Security requirements
 
-不要主动暴露或打印任何密钥。
-除非任务明确要求且权限允许，不要读取或修改敏感文件。
-除非明确要求并获得批准，不要执行破坏性 shell 命令。
+Do not actively expose or print any keys.
+Do not read or modify sensitive files unless explicitly required by the task and permitted by permissions.
+Do not execute destructive shell commands unless explicitly requested and approved.
 
-## 规则与扩展技能
+## Rules and Extended Skills
 
-OpenClaw 会从本工作区的 `skills/` 加载 Markdown 技能。初始化后规则文件位于：
+OpenClaw will load Markdown skills from `skills/` in this workspace. After initialization the rules file is located at:
 
 `skills/frontend-craft-rules/`
 
-按需阅读并在对话中引用相关片段，例如：
+Read as needed and quote relevant passages in the conversation, for example:
 
-- `skills/frontend-craft-rules/fec-vue.md` / `fec-react.md` — 框架规范
-- `skills/frontend-craft-rules/fec-typescript.md` — TypeScript/JavaScript（与 `typescript-reviewer` 剧本联动）
-- `skills/frontend-craft-rules/fec-code-comments.md` — 代码注释（何时写、写什么）
-- `skills/frontend-craft-rules/fec-testing.md`、`fec-performance.md`、`fec-design-system.md` 等
-- `skills/frontend-craft-rules/fec-agent-workflow.md` — 子代理协作边界
-- `skills/frontend-craft-rules/fec-working-modes.md` — 调研、计划、开发、评审、收尾模式
+- `skills/frontend-craft-rules/fec-vue.md` / `fec-react.md` — Framework specification
+- `skills/frontend-craft-rules/fec-typescript.md` — TypeScript/JavaScript (linked with `typescript-reviewer` script)
+- `skills/frontend-craft-rules/fec-code-comments.md` — code comments (when to write, what to write)
+- `skills/frontend-craft-rules/fec-testing.md`, `fec-performance.md`, `fec-design-system.md`, etc.
+- `skills/frontend-craft-rules/fec-agent-workflow.md` — subagent collaboration boundary
+- `skills/frontend-craft-rules/fec-working-modes.md` — research, planning, development, review, finishing modes
 
-若项目不需要某项规则，可删除对应文件或在对话中说明忽略。
+If the project does not require a certain rule, you can delete the corresponding file or explain it in the dialog to ignore it.

package/templates/openclaw/OPENCLAW-CONFIG.md

@@ -1,12 +1,12 @@
-# OpenClaw 配置说明（替代原 Claude Code settings.json）
+# OpenClaw configuration instructions (replacing the original Claude Code settings.json)
 
-本插件不再提供 `settings.json`（Claude Code 专用）。在 OpenClaw 中请使用网关配置文件，例如：
+This plugin no longer provides `settings.json` (Claude Code only). In OpenClaw please use a gateway configuration file, for example:
 
-- 用户级：`~/.openclaw/openclaw.json`（或你的 profile 路径）
-- 工作区：按 `openclaw configure` / 文档约定
+- User level: `~/.openclaw/openclaw.json` (or your profile path)
+- workspace: as per `openclaw configure`/documentation convention
 
-常用关注点：
+Common concerns:
 
-- **沙箱与执行策略**：参见官方文档 [Sandboxing](https://docs.openclaw.ai/gateway/sandboxing) 中的 `agents.defaults.sandbox` 等键
-- **插件开关**：`plugins.entries.frontend-craft` 下可覆盖本插件 `configSchema` 中的布尔项（如 `formatAfterWrite`、`notifyOnAgentEnd`）
-- **MCP**：原生插件不会自动合并仓库根目录的 `.mcp.json`；请将其中 `mcpServers` 合并到你的 embedded Pi / 网关 MCP 配置（见主 README 的 MCP 章节）
+- **Sandbox and execution strategy**: See the `agents.defaults.sandbox` and other keys in the official document [Sandboxing](https://docs.openclaw.ai/gateway/sandboxing)
+- **Plug-in switch**: `plugins.entries.frontend-craft` can override the Boolean items in the `configSchema` of this plugin (such as `formatAfterWrite`, `notifyOnAgentEnd`)
+- **MCP**: The native plug-in will not automatically merge `.mcp.json` in the warehouse root directory; please merge `mcpServers` into your embedded Pi/gateway MCP configuration (see the MCP chapter of the main README)