@bovinphang/frontend-craft 2.6.0 → 2.8.0

package/skills/relations.json

@@ -25,7 +25,7 @@
       "fec-security-review",
       "fec-route-protection",
       "fec-form-handling",
-      "fec-typescript-type-safety",
+      "fec-typescript-project-standard",
       "fec-source-driven-development"
     ],
     "boundaryWorkflows": [
@@ -41,6 +41,26 @@
       "realtime"
     ]
   },
+  "fec-backend-requirements-handoff": {
+    "relatedSkills": [
+      "fec-api-integration",
+      "fec-doc-sync",
+      "fec-source-driven-development",
+      "fec-testing-strategy",
+      "fec-route-protection"
+    ],
+    "boundaryWorkflows": [
+      "Use API integration when the contract shape, typed client, auth refresh, error mapping, upload, or realtime implementation is being designed.",
+      "Use documentation sync when backend decisions change public docs, API notes, route docs, or env/config documentation.",
+      "Use route protection when the handoff centers on auth redirects, RBAC, permission routes, or middleware behavior."
+    ],
+    "capabilityTags": [
+      "backend-requirements",
+      "handoff",
+      "api-collaboration",
+      "data-needs"
+    ]
+  },
   "fec-browser-storage": {
     "relatedSkills": [
       "fec-security-review",
@@ -85,7 +105,7 @@
       "fec-e2e-testing",
       "fec-validation-fix",
       "fec-performance-optimization",
-      "fec-typescript-type-safety",
+      "fec-typescript-project-standard",
       "fec-state-management",
       "fec-source-driven-development",
       "fec-dependency-upgrade",
@@ -174,6 +194,28 @@
       "migration"
     ]
   },
+  "fec-drawio-studio": {
+    "relatedSkills": [
+      "fec-image-generation",
+      "fec-canvas-threejs",
+      "fec-svg-animation",
+      "fec-ui-design",
+      "fec-source-driven-development"
+    ],
+    "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."
+    ],
+    "capabilityTags": [
+      "drawio",
+      "editable-diagram",
+      "autolayout",
+      "shape-search",
+      "code-structure-map"
+    ]
+  },
   "fec-e2e-testing": {
     "relatedSkills": [
       "fec-testing-strategy",
@@ -210,6 +252,33 @@
       "accessibility"
     ]
   },
+  "fec-image-generation": {
+    "relatedSkills": [
+      "fec-ui-design",
+      "fec-implement-from-design",
+      "fec-canvas-threejs",
+      "fec-svg-animation",
+      "fec-responsive-layout",
+      "fec-accessibility-check",
+      "fec-web-video-presentation"
+    ],
+    "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"
+    ]
+  },
   "fec-legacy-to-modern-migration": {
     "relatedSkills": [
       "fec-legacy-web-standard",
@@ -356,7 +425,7 @@
   },
   "fec-react-project-standard": {
     "relatedSkills": [
-      "fec-typescript-type-safety",
+      "fec-typescript-project-standard",
       "fec-state-management",
       "fec-tailwind-design-system",
       "fec-responsive-layout",
@@ -530,26 +599,6 @@
       "workflow"
     ]
   },
-  "fec-typescript-type-safety": {
-    "relatedSkills": [
-      "fec-code-review",
-      "fec-api-integration",
-      "fec-react-project-standard",
-      "fec-vue3-project-standard",
-      "fec-form-handling"
-    ],
-    "boundaryWorkflows": [
-      "Use a general code review workflow when the task spans architecture, rendering, styles, tests, and maintainability beyond type contracts.",
-      "Use an API integration workflow for runtime API client boundaries, auth refresh, uploads, realtime behavior, and error mapping.",
-      "Use framework project workflows when type decisions are part of broader React, Vue, Next.js, or Nuxt module architecture."
-    ],
-    "capabilityTags": [
-      "typescript",
-      "type-safety",
-      "type-modeling",
-      "dto"
-    ]
-  },
   "fec-testing-strategy": {
     "relatedSkills": [
       "fec-component-testing",
@@ -570,14 +619,39 @@
       "quality-gate"
     ]
   },
+  "fec-typescript-project-standard": {
+    "relatedSkills": [
+      "fec-code-review",
+      "fec-api-integration",
+      "fec-react-project-standard",
+      "fec-vue3-project-standard",
+      "fec-vite-project-standard",
+      "fec-monorepo-project-standard",
+      "fec-validation-fix"
+    ],
+    "boundaryWorkflows": [
+      "Use framework project workflows for component architecture, routing, state ownership, and framework-specific module boundaries.",
+      "Use API integration when runtime API clients, auth refresh, uploads, realtime behavior, or error mapping go beyond TypeScript type contracts.",
+      "Use validation fix when the task is to repair concrete lint, typecheck, test, build, or CI failures after TypeScript changes."
+    ],
+    "capabilityTags": [
+      "typescript",
+      "project-standard",
+      "type-safety",
+      "tsconfig",
+      "declarations"
+    ]
+  },
   "fec-ui-design": {
     "relatedSkills": [
+      "fec-image-generation",
       "fec-implement-from-design",
       "fec-accessibility-check",
       "fec-code-review",
       "fec-tailwind-design-system",
       "fec-responsive-layout",
-      "fec-storybook-component-doc"
+      "fec-storybook-component-doc",
+      "fec-web-video-presentation"
     ],
     "boundaryWorkflows": [
       "Use an implementation-from-design workflow when an external design file is the source of truth.",
@@ -620,7 +694,7 @@
   },
   "fec-vue3-project-standard": {
     "relatedSkills": [
-      "fec-typescript-type-safety",
+      "fec-typescript-project-standard",
       "fec-state-management",
       "fec-tailwind-design-system",
       "fec-responsive-layout",
@@ -644,6 +718,27 @@
       "fec-architecture"
     ]
   },
+  "fec-web-video-presentation": {
+    "relatedSkills": [
+      "fec-ui-design",
+      "fec-image-generation",
+      "fec-motion-interaction",
+      "fec-responsive-layout",
+      "fec-accessibility-check"
+    ],
+    "boundaryWorkflows": [
+      "Use a UI design workflow for product-specific visual direction, asset strategy, anti-generic design, and visual QA of scenes.",
+      "Use image generation when the presentation needs custom raster assets, diagrams, storyboard frames, or generated visual references.",
+      "Use motion and responsive layout workflows when scene transitions, reduced-motion behavior, viewport scaling, or recording stability need deeper treatment."
+    ],
+    "capabilityTags": [
+      "web-video",
+      "presentation",
+      "recording",
+      "script-outline",
+      "step-driven-stage"
+    ]
+  },
   "fec-web-workers": {
     "relatedSkills": [
       "fec-canvas-threejs",

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"