@bovinphang/frontend-craft 2.7.0 → 2.9.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"
@@ -751,5 +755,269 @@
       "performance",
       "main-thread"
     ]
+  },
+  "fec-refactoring": {
+    "relatedSkills": [
+      "fec-code-smells",
+      "fec-refactoring-catalog",
+      "fec-refactoring-validation",
+      "fec-refactor-clean",
+      "fec-code-review",
+      "fec-tdd-workflow",
+      "fec-debug-framework",
+      "fec-validation-fix",
+      "fec-testing-strategy"
+    ],
+    "boundaryWorkflows": [
+      "Use dead-code cleanup for proven unused code, exports, styles, routes, fixtures, or dependencies.",
+      "Use TDD when adding new observable behavior or fixing a behavior-changing defect.",
+      "Use debugging first when the failure cause is unknown.",
+      "Use validation repair for understood lint, typecheck, test, or build failures that predate the refactoring step.",
+      "Use code review for merge-readiness review rather than structure-changing execution.",
+      "Use migration or architecture planning for dependency, framework, router, state-library, or platform replacements."
+    ],
+    "capabilityTags": [
+      "refactoring",
+      "behavior-preservation",
+      "workflow",
+      "validation"
+    ]
+  },
+  "fec-code-smells": {
+    "relatedSkills": [
+      "fec-refactoring",
+      "fec-refactoring-catalog",
+      "fec-code-review"
+    ],
+    "boundaryWorkflows": [
+      "Use dead-code cleanup for proven unused code, exports, styles, routes, fixtures, or dependencies.",
+      "Use TDD when adding new observable behavior or fixing a behavior-changing defect.",
+      "Use debugging first when the failure cause is unknown.",
+      "Use validation repair for understood lint, typecheck, test, or build failures that predate the refactoring step.",
+      "Use code review for merge-readiness review rather than structure-changing execution.",
+      "Use migration or architecture planning for dependency, framework, router, state-library, or platform replacements."
+    ],
+    "capabilityTags": [
+      "code-smells",
+      "diagnosis",
+      "maintainability",
+      "evidence"
+    ]
+  },
+  "fec-refactoring-catalog": {
+    "relatedSkills": [
+      "fec-refactoring",
+      "fec-code-smells",
+      "fec-refactoring-functions",
+      "fec-refactoring-encapsulation",
+      "fec-refactoring-move-features",
+      "fec-refactoring-data",
+      "fec-refactoring-control",
+      "fec-refactoring-api",
+      "fec-refactoring-inheritance",
+      "fec-refactoring-validation"
+    ],
+    "boundaryWorkflows": [
+      "Use dead-code cleanup for proven unused code, exports, styles, routes, fixtures, or dependencies.",
+      "Use TDD when adding new observable behavior or fixing a behavior-changing defect.",
+      "Use debugging first when the failure cause is unknown.",
+      "Use validation repair for understood lint, typecheck, test, or build failures that predate the refactoring step.",
+      "Use code review for merge-readiness review rather than structure-changing execution.",
+      "Use migration or architecture planning for dependency, framework, router, state-library, or platform replacements."
+    ],
+    "capabilityTags": [
+      "refactoring",
+      "catalog",
+      "selection",
+      "composition"
+    ]
+  },
+  "fec-refactoring-functions": {
+    "relatedSkills": [
+      "fec-refactoring",
+      "fec-code-smells",
+      "fec-refactoring-catalog",
+      "fec-refactoring-validation",
+      "fec-typescript-project-standard"
+    ],
+    "boundaryWorkflows": [
+      "Use dead-code cleanup for proven unused code, exports, styles, routes, fixtures, or dependencies.",
+      "Use TDD when adding new observable behavior or fixing a behavior-changing defect.",
+      "Use debugging first when the failure cause is unknown.",
+      "Use validation repair for understood lint, typecheck, test, or build failures that predate the refactoring step.",
+      "Use code review for merge-readiness review rather than structure-changing execution.",
+      "Use migration or architecture planning for dependency, framework, router, state-library, or platform replacements."
+    ],
+    "capabilityTags": [
+      "refactoring",
+      "functions",
+      "parameters",
+      "decomposition"
+    ]
+  },
+  "fec-refactoring-encapsulation": {
+    "relatedSkills": [
+      "fec-refactoring",
+      "fec-code-smells",
+      "fec-refactoring-catalog",
+      "fec-refactoring-validation",
+      "fec-state-management"
+    ],
+    "boundaryWorkflows": [
+      "Use dead-code cleanup for proven unused code, exports, styles, routes, fixtures, or dependencies.",
+      "Use TDD when adding new observable behavior or fixing a behavior-changing defect.",
+      "Use debugging first when the failure cause is unknown.",
+      "Use validation repair for understood lint, typecheck, test, or build failures that predate the refactoring step.",
+      "Use code review for merge-readiness review rather than structure-changing execution.",
+      "Use migration or architecture planning for dependency, framework, router, state-library, or platform replacements."
+    ],
+    "capabilityTags": [
+      "refactoring",
+      "encapsulation",
+      "delegation",
+      "value-object"
+    ]
+  },
+  "fec-refactoring-move-features": {
+    "relatedSkills": [
+      "fec-refactoring",
+      "fec-code-smells",
+      "fec-refactoring-catalog",
+      "fec-refactoring-validation",
+      "fec-refactor-clean"
+    ],
+    "boundaryWorkflows": [
+      "Use dead-code cleanup for proven unused code, exports, styles, routes, fixtures, or dependencies.",
+      "Use TDD when adding new observable behavior or fixing a behavior-changing defect.",
+      "Use debugging first when the failure cause is unknown.",
+      "Use validation repair for understood lint, typecheck, test, or build failures that predate the refactoring step.",
+      "Use code review for merge-readiness review rather than structure-changing execution.",
+      "Use migration or architecture planning for dependency, framework, router, state-library, or platform replacements."
+    ],
+    "capabilityTags": [
+      "refactoring",
+      "move-function",
+      "ownership",
+      "loops"
+    ]
+  },
+  "fec-refactoring-data": {
+    "relatedSkills": [
+      "fec-refactoring",
+      "fec-code-smells",
+      "fec-refactoring-catalog",
+      "fec-refactoring-validation",
+      "fec-state-management",
+      "fec-typescript-project-standard"
+    ],
+    "boundaryWorkflows": [
+      "Use dead-code cleanup for proven unused code, exports, styles, routes, fixtures, or dependencies.",
+      "Use TDD when adding new observable behavior or fixing a behavior-changing defect.",
+      "Use debugging first when the failure cause is unknown.",
+      "Use validation repair for understood lint, typecheck, test, or build failures that predate the refactoring step.",
+      "Use code review for merge-readiness review rather than structure-changing execution.",
+      "Use migration or architecture planning for dependency, framework, router, state-library, or platform replacements."
+    ],
+    "capabilityTags": [
+      "refactoring",
+      "data",
+      "derived-state",
+      "identity"
+    ]
+  },
+  "fec-refactoring-control": {
+    "relatedSkills": [
+      "fec-refactoring",
+      "fec-code-smells",
+      "fec-refactoring-catalog",
+      "fec-refactoring-validation",
+      "fec-typescript-project-standard"
+    ],
+    "boundaryWorkflows": [
+      "Use dead-code cleanup for proven unused code, exports, styles, routes, fixtures, or dependencies.",
+      "Use TDD when adding new observable behavior or fixing a behavior-changing defect.",
+      "Use debugging first when the failure cause is unknown.",
+      "Use validation repair for understood lint, typecheck, test, or build failures that predate the refactoring step.",
+      "Use code review for merge-readiness review rather than structure-changing execution.",
+      "Use migration or architecture planning for dependency, framework, router, state-library, or platform replacements."
+    ],
+    "capabilityTags": [
+      "refactoring",
+      "conditionals",
+      "guard-clauses",
+      "polymorphism"
+    ]
+  },
+  "fec-refactoring-api": {
+    "relatedSkills": [
+      "fec-refactoring",
+      "fec-code-smells",
+      "fec-refactoring-catalog",
+      "fec-refactoring-validation",
+      "fec-api-integration",
+      "fec-typescript-project-standard"
+    ],
+    "boundaryWorkflows": [
+      "Use dead-code cleanup for proven unused code, exports, styles, routes, fixtures, or dependencies.",
+      "Use TDD when adding new observable behavior or fixing a behavior-changing defect.",
+      "Use debugging first when the failure cause is unknown.",
+      "Use validation repair for understood lint, typecheck, test, or build failures that predate the refactoring step.",
+      "Use code review for merge-readiness review rather than structure-changing execution.",
+      "Use migration or architecture planning for dependency, framework, router, state-library, or platform replacements."
+    ],
+    "capabilityTags": [
+      "refactoring",
+      "api",
+      "parameters",
+      "dependencies"
+    ]
+  },
+  "fec-refactoring-inheritance": {
+    "relatedSkills": [
+      "fec-refactoring",
+      "fec-code-smells",
+      "fec-refactoring-catalog",
+      "fec-refactoring-validation",
+      "fec-typescript-project-standard",
+      "fec-legacy-to-modern-migration"
+    ],
+    "boundaryWorkflows": [
+      "Use dead-code cleanup for proven unused code, exports, styles, routes, fixtures, or dependencies.",
+      "Use TDD when adding new observable behavior or fixing a behavior-changing defect.",
+      "Use debugging first when the failure cause is unknown.",
+      "Use validation repair for understood lint, typecheck, test, or build failures that predate the refactoring step.",
+      "Use code review for merge-readiness review rather than structure-changing execution.",
+      "Use migration or architecture planning for dependency, framework, router, state-library, or platform replacements."
+    ],
+    "capabilityTags": [
+      "refactoring",
+      "inheritance",
+      "delegation",
+      "composition"
+    ]
+  },
+  "fec-refactoring-validation": {
+    "relatedSkills": [
+      "fec-refactoring",
+      "fec-testing-strategy",
+      "fec-tdd-workflow",
+      "fec-validation-fix",
+      "fec-debug-framework",
+      "fec-code-review"
+    ],
+    "boundaryWorkflows": [
+      "Use dead-code cleanup for proven unused code, exports, styles, routes, fixtures, or dependencies.",
+      "Use TDD when adding new observable behavior or fixing a behavior-changing defect.",
+      "Use debugging first when the failure cause is unknown.",
+      "Use validation repair for understood lint, typecheck, test, or build failures that predate the refactoring step.",
+      "Use code review for merge-readiness review rather than structure-changing execution.",
+      "Use migration or architecture planning for dependency, framework, router, state-library, or platform replacements."
+    ],
+    "capabilityTags": [
+      "refactoring",
+      "validation",
+      "behavior-preservation",
+      "rollback"
+    ]
   }
 }

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"