@bovinphang/frontend-craft 2.7.0 → 2.8.0

package/skills/fec-tailwind-design-system/SKILL.md

@@ -1,34 +1,34 @@
 ---
 name: fec-tailwind-design-system
-description: Use when designing, implementing, or reviewing Tailwind CSS design systems, token mapping, theme extension, utility class governance, component variants, dark mode, responsive utilities, safelists, or maintainable class composition; Chinese triggers include Tailwind, 设计 Token, 组件变体, 暗色模式, class 管理.
+description: Use when designing, implementing, or reviewing Tailwind CSS design systems, token mapping, theme extension, utility class governance, component variants, dark mode, responsive utilities, safelists, or maintainable class composition; Chinese triggers include Tailwind, design Token, component variants, dark mode, class management.
 ---
 
-# Tailwind 设计系统
+#Tailwind Design System
 
-适用于用 Tailwind CSS 承载产品设计系统、组件变体和主题规则的前端任务。需要具体配置、variant、class 组织和迁移细节时加载 [references/tailwind-system-patterns.md](references/tailwind-system-patterns.md)。
+Suitable for front-end tasks hosting product design systems, component variations, and theme rules with Tailwind CSS. Load [references/tailwind-system-patterns.md](references/tailwind-system-patterns.md) when specific configuration, variant, class organization and migration details are needed.
 
 ## Purpose
 
-让 Tailwind 项目中的 token、主题、组件变体和响应式样式可维护，而不是把一次性 utility class 散落到业务代码里。
+Make the tokens, themes, component variations, and responsive styles in the Tailwind project maintainable instead of scattering one-off utility classes into business code.
 
 ## Procedure
 
-1. 识别现状：确认 Tailwind 版本、配置位置、暗色模式策略、组件库、CSS 变量、设计 token 和 class 合并工具。
-2. 建立 token 边界：颜色、间距、圆角、阴影、字体、z-index 和断点优先从项目 token 或 `theme.extend` 派生。
-3. 设计组件变体：按钮、输入框、卡片、弹窗、表格等基础组件用集中 variant API 表达尺寸、语义、状态和密度。
-4. 控制 class 复杂度：重复组合沉淀为组件、slot、variant 或局部 helper；不要把长 class 字符串复制到多个页面。
-5. 处理主题和暗色模式：明确 `class`、`data-theme` 或 CSS 变量方案，避免首次渲染闪烁和对比度回归。
-6. 接入响应式：移动优先组织 utility；复杂布局交给响应式布局工作流，不要只靠堆叠断点前缀碰运气。
-7. 验证样式结果：检查 hover、active、focus-visible、disabled、loading、selected、invalid、dark 和不同断点。
+1. Identify the current situation: Confirm Tailwind version, configuration location, dark mode strategy, component library, CSS variables, design token and class merging tool.
+2. Establish token boundaries: color, spacing, rounded corners, shadow, font, z-index and breakpoints are first derived from the project token or `theme.extend`.
+3. Design component variants: Basic components such as buttons, input boxes, cards, pop-up windows, and tables use centralized variant APIs to express size, semantics, status, and density.
+4. Control class complexity: Repeated combinations are precipitated into components, slots, variants or local helpers; do not copy long class strings to multiple pages.
+5. Handle themes and dark modes: Explicit `class`, `data-theme` or CSS variable schemes to avoid first render flickering and contrast regression.
+6. Access responsiveness: mobile-first organization utility; leave complex layouts to responsive layout workflow, don’t just rely on stacked breakpoint prefixes to try your luck.
+7. Verify style results: check hover, active, focus-visible, disabled, loading, selected, invalid, dark and different breakpoints.
 
 ## Constraints
 
-- 不把 Tailwind class 当作设计系统本身；真正的系统是 token、组件 API、状态矩阵和使用约束。
-- 不为单个页面随意扩展全局 token；新增 token 必须有语义名称和复用场景。
-- 不使用拼接的动态 class 破坏构建扫描；必要时使用 safelist、映射表或 variant 工具。
-- 不在组件外部覆盖基础组件内部结构来实现变体。
-- 不让暗色模式只靠反色；状态色、边框、阴影、图表和图片都要重新检查。
+- Don't think of the Tailwind class as the design system itself; the real system is the token, component API, state matrix, and usage constraints.
+- Do not expand global tokens arbitrarily for a single page; new tokens must have semantic names and reuse scenarios.
+- Do not use spliced dynamic classes to break build scans; use safelist, mapping table or variant tools when necessary.
+- Do not override base component internals outside the component to implement variations.
+- Don't let dark mode rely solely on inverse colors; status colors, borders, shadows, charts, and images are all re-examined.
 
 ## Expected Output
 
-输出 Tailwind token 映射、主题配置边界、组件 variant 设计、class 复用策略、暗色模式和响应式验证结果。完成后样式应能被项目组件复用、可搜索、可测试，并与设计系统规则一致。
+Output Tailwind token mapping, theme configuration boundaries, component variant design, class reuse strategy, dark mode and responsive validation results. After completion, the style should be reusable by project components, searchable, testable, and consistent with the design system rules.

package/skills/fec-tailwind-design-system/references/tailwind-system-patterns.md

@@ -1,28 +1,28 @@
-# Tailwind 系统模式
+# Tailwind system mode
 
-## Token 映射
+## Token mapping
 
-优先使用语义化名称：
+Prefer using semantic names:
 
-| 需求 | 推荐 | 避免 |
+| Need | Recommend | Avoid |
 | ---- | ---- | ---- |
-| 品牌色 | `brand.600`, `--color-brand-primary` | 到处复制 `blue-600` |
-| 表面层级 | `surface.canvas`, `surface.panel` | 一次性灰色值 |
-| 圆角 | `radius.control`, `radius.panel` | 随意重复的具体值 |
-| 阴影 | `shadow.floating`, `shadow.focus` | 没有状态含义的装饰阴影 |
+| Brand color | `brand.600`, `--color-brand-primary` | Copy everywhere `blue-600` |
+| Surface level | `surface.canvas`, `surface.panel` | One-time gray value |
+| rounded corners | `radius.control`, `radius.panel` | optionally repeated specific values |
+| Shadow | `shadow.floating`, `shadow.focus` | Decorative shadow with no state meaning |
 
-如果项目已有 CSS 变量，把 Tailwind token 映射到这些变量，而不是重复维护字面量。
+If the project already has CSS variables, map Tailwind tokens to these variables instead of repeatedly maintaining literals.
 
-## Variant 归属
+## Variant Attribution
 
-长 class 组合应收敛到以下位置之一：
+Long class combinations should converge to one of the following locations:
 
-- 带 `variant`、`size`、`tone`、`density`、`state` props 的共享组件。
-- 复合组件的 slot 映射表。
-- CVA、tailwind-variants 或本地 `classNames` 映射等类型化 helper。
-- 只在一个模块内复用时，使用局部常量。
+- Shared components with `variant`, `size`, `tone`, `density`, `state` props.
+- Slot mapping table of composite components.
+- Typed helpers such as CVA, tailwind-variants or local `classNames` mappings.
+- Use local constants when reusing them within only one module.
 
-不要根据不受控的用户输入拼接 class 名。使用显式映射：
+Don't splice class names based on uncontrolled user input. Use explicit mapping:
 
 ```ts
 const toneClass = {
@@ -32,28 +32,28 @@ const toneClass = {
 } as const;
 ```
 
-## 暗色模式
+## Dark mode
 
-- 优先选择单一的项目级策略：`class`、`data-theme` 或 CSS 变量。
-- 如果应用支持手动切换主题，在 body 绘制前初始化已选主题，避免首屏先亮后暗或先暗后亮的主题闪烁。
-- 在亮色和暗色主题下都测试 disabled、focus、selected、invalid、chart 和 skeleton 状态。
-- 不要把降低透明度作为 disabled 的唯一提示；要保留对比度和可感知性。
-- Tailwind 项目使用 `darkMode: "class"` 或等价配置时，主题切换逻辑应同时维护根节点 class / data attribute，并持久化用户偏好。
-- CSS 变量方案中，Tailwind token 应引用语义变量；不要为亮色和暗色分别散落两套工具类字面量。
-- 在 `<head>` 或框架等价入口中放置极小同步初始化脚本时，只读取本地主题偏好和系统偏好，不执行业务逻辑、不访问服务端数据。
-- 暗色模式需复核图片亮度、阴影层级、表单控件、第三方组件、图表色板和 focus ring；不要只补背景色。
+- Prefer a single project-level strategy: `class`, `data-theme` or CSS variables.
+- If the application supports manual theme switching, initialize the selected theme before the body is drawn to avoid flickering of the first screen that first lights up and then darkens or first darkens and then lights up.
+- Test disabled, focus, selected, invalid, chart and skeleton states in both light and dark themes.
+- Don't use lowering transparency as the only hint of disabled; preserve contrast and perceptibility.
+- When the Tailwind project uses `darkMode: "class"` or equivalent configuration, the theme switching logic should maintain the root node class / data attribute and persist user preferences.
+- In the CSS variable scheme, Tailwind token should refer to semantic variables; do not scatter two sets of utility literals for light and dark colors.
+- When placing a minimal synchronization initialization script in `<head>` or a framework equivalent entry, only local theme preferences and system preferences are read, no business logic is executed, and no server-side data is accessed.
+- In dark mode, you need to review the image brightness, shadow level, form controls, third-party components, chart color palette and focus ring; don't just add the background color.
 
-## 响应式工具类
+## Responsive tool class
 
-- 默认 class 列表从移动端布局开始。
-- 只有信息架构变化时，才增加更大断点前缀。
-- 重复出现的响应式区块应沉淀为布局组件或 CSS 容器查询，不要反复复制同一串断点。
-- 控件、标签页、看板和数据单元格使用稳定尺寸，避免 hover 和 loading 状态造成布局跳动。
+- The default class list starts with mobile layout.
+- Only add larger breakpoint prefixes when the information architecture changes.
+- Recurring responsive blocks should be precipitated into layout components or CSS container queries, and do not duplicate the same string of breakpoints repeatedly.
+- Controls, tabs, dashboards and data cells use stable sizes to avoid layout jumps caused by hover and loading states.
 
-## 评审清单
+## Review Checklist
 
-- Token 值有语义角色，并且没有分叉既有设计规则。
-- 组件 variants 覆盖 loading、disabled、selected、invalid、focus-visible 和暗色模式。
-- 动态 class 可被静态扫描识别，或已安全加入 safelist。
-- Tailwind 工具类没有破坏可访问性、点击目标或 reduced-motion 要求。
-- 最终 UI 已在移动端、平板和桌面宽度检查过。
+- Token values have semantic roles and do not fork existing design rules.
+- Component variants cover loading, disabled, selected, invalid, focus-visible and dark mode.
+- Dynamic classes can be recognized by static scans, or have been safely added to the safelist.
+- Tailwind utility classes have no accessibility-breaking, click-targeting, or reduced-motion requirements.
+- Final UI checked in mobile, tablet and desktop widths.

package/skills/fec-tdd-workflow/SKILL.md

@@ -1,52 +1,52 @@
 ---
 name: fec-tdd-workflow
-description: Use when implementing new frontend behavior, fixing bugs, or refactoring logic where tests can describe the expected behavior first. Apply to components, hooks/composables, utilities, API clients, route guards, or user workflows; Chinese triggers include TDD, 测试驱动, 先写测试, 红绿重构, 回归测试.
+description: Use when implementing new frontend behavior, fixing bugs, or refactoring logic where tests can describe the expected behavior first. Apply to components, hooks/composables, utilities, API clients, route guards, or user workflows; Chinese triggers include TDD, test-driven, write tests first, red-green refactoring, regression testing.
 ---
 
-# 前端 TDD 工作流
+# Front-end TDD workflow
 
 ## Purpose
 
-用“先写失败测试，再实现最小代码，再重构”的节奏交付前端功能，避免只在实现后补覆盖率。
+Use the rhythm of "write failing tests first, then implement the minimum code, and then refactor" to deliver front-end functions to avoid supplementing coverage only after implementation.
 
 ## Procedure
 
-1. 识别可观察行为：用户能看到的 UI、组件契约、hook/composable 返回值、路由守卫结果、API client 输出或错误状态。
-2. 先写一个最小失败测试：
-   - 纯逻辑优先单元测试。
-   - 组件交互优先 Testing Library / Vue Test Utils。
-   - 跨页关键流程优先 Playwright / Cypress。
-3. 运行该测试并确认失败原因正确，失败应来自行为尚未实现，而不是语法、导入或测试环境错误。
-4. 写刚好能通过测试的最小实现，不顺手扩大范围。
-5. 重新运行测试，确认变绿。
-6. 在测试保持通过的前提下重构命名、边界和重复逻辑。
-7. 对 bug 修复，保留能复现问题的回归测试。
-8. 每轮只扩大一个可观察行为；新需求、新边界和新异常路径各自进入下一轮。
+1. Identify observable behaviors: UI, component contracts, hook/composable return values, route guard results, API client output or error status that users can see.
+2. First write a minimum failure test:
+   - Pure logic first unit testing.
+   - Prioritize component interaction Testing Library / Vue Test Utils.
+   - Prioritize critical processes across pages Playwright/Cypress.
+3. Run the test and confirm that the failure reason is correct and should come from behavior that has not yet been implemented, rather than a syntax, import, or test environment error.
+4. Write the minimum implementation that can just pass the test, and do not expand the scope easily.
+5. Rerun the test and confirm it turns green.
+6. Refactor naming, boundaries and duplication logic while keeping tests passing.
+7. Fix bugs and retain regression tests that can reproduce the problem.
+8. Only one observable behavior is expanded in each round; new requirements, new boundaries and new abnormal paths enter the next round respectively.
 
 ## Prove-It Pattern
 
-修复缺陷时先让测试失败，再让它通过。若无法先失败，说明测试没有覆盖原始问题，需要收窄输入、断言或测试层级。
+When fixing a defect, make the test fail first, then make it pass. If it cannot fail first, it means that the test does not cover the original problem, and the input, assertion or test level needs to be narrowed.
 
 ## Frontend Test Selection
 
 | Risk | Preferred Test |
 | ---- | -------------- |
-| utils、schema、状态计算 | 单元测试 |
-| hooks / composables | 单元或轻量集成测试 |
-| 组件 props、emits、交互、状态 | 组件测试 |
-| Router、Provider、Store 协作 | 轻量集成测试 |
-| 登录、支付、权限、关键 CRUD | E2E 测试 |
+| utils, schema, status calculation | unit testing |
+| hooks / composables | unit or lightweight integration testing |
+| Component props, emits, interactions, status | Component testing |
+| Router, Provider, Store collaboration | Lightweight integration testing |
+| Login, payment, permissions, key CRUD | E2E testing |
 
 ## Constraints
 
-- 不为了 TDD 引入项目没有使用且收益不清晰的新测试框架。
-- 不测试实现细节、私有状态或脆弱 DOM 结构。
-- 不把 E2E 当作所有风险的默认答案；优先选择离风险最近的测试层。
-- 如果现有仓库没有测试基础设施，先输出最小测试落地建议，再请求用户确认是否引入。
-- 不在红灯阶段同时重构；先证明问题，再最小修复，再整理结构。
+- Do not introduce new testing frameworks for the sake of TDD that are not used by the project and whose benefits are not clear.
+- Does not test implementation details, private state, or fragile DOM structures.
+- Don’t treat E2E as the default answer for all risks; prioritize the test layer closest to the risk.
+- If the existing warehouse does not have testing infrastructure, output the minimum test implementation suggestions first, and then ask the user to confirm whether to introduce it.
+- Do not refactor at the same time during the red light stage; prove the problem first, then make minimal repairs, and then organize the structure.
 
 ## Expected Output
 
-- 至少一个先失败后通过的测试覆盖新增或修复行为。
-- 实现保持最小范围，重构只在测试通过后进行。
-- 总结运行过的测试命令、覆盖的行为和未覆盖风险。
+- At least one fail-then-pass test covering the new or fixed behavior.
+- Implementation is kept to a minimum scope and refactoring is done only after the tests pass.
+- Summarize the test commands run, behaviors covered, and risks not covered.

package/skills/fec-testing-strategy/SKILL.md

@@ -1,45 +1,45 @@
 ---
 name: fec-testing-strategy
-description: Use when planning or reviewing a frontend testing strategy, selecting the right test layer by risk, mapping coverage across static checks, unit tests, component tests, integration tests, E2E, Storybook/visual regression, a11y, security, performance, or CI gates. Do not use to write individual component/E2E tests or merely run existing validation commands; Chinese triggers include 测试策略, 测试分层, 测试计划, 覆盖矩阵.
+description: Use when planning or reviewing a frontend testing strategy, selecting the right test layer by risk, mapping coverage across static checks, unit tests, component tests, integration tests, E2E, Storybook/visual regression, a11y, security, performance, or CI gates. Do not use to write individual component/E2E tests or merely run existing validation commands; Chinese triggers include test strategy, test layering, test plan, coverage matrix.
 ---
 
-# 前端测试策略
+# Front-end testing strategy
 
 ## Purpose
 
-按“离代码多近 / 覆盖风险层级”选择测试方法，避免把所有风险都塞进组件测试或 E2E。
+Choose your testing approach by “closeness to code/level of risk coverage” to avoid cramming all risks into component tests or E2E.
 
 ## Procedure
 
-1. 识别改动类型：纯逻辑、UI 组件、跨模块流程、浏览器能力、视觉稳定性、专项质量风险或发布门禁。
-2. 建立测试层级矩阵，至少区分：
-   - 静态检查：TypeScript、ESLint、格式、依赖安全、构建。
-   - 单元测试：utils、hooks/composables、状态逻辑、schema、纯函数。
-   - 组件测试：props/emits、用户交互、loading/error/empty、mock 边界。
-   - 轻量集成测试：表单 + API mock + 路由/Store/Provider 上下文。
-   - E2E：真实浏览器、跨页面关键旅程、鉴权、支付、权限、CI artifacts。
-   - 视觉/交互文档：Storybook interaction、Chromatic、视觉回归基线。
-   - 专项质量：a11y、安全、性能、兼容性。
-3. 按风险分配覆盖：高频核心路径优先 E2E，复杂组件状态优先组件测试，纯逻辑优先单元测试，跨 provider 协作用轻量集成测试。
-4. 用测试金字塔控制维护成本：
-   - 越靠近纯逻辑，测试越多、越快、越稳定。
-   - E2E 只覆盖用户关键旅程和真实浏览器风险，不覆盖每个分支。
-   - 视觉、a11y、安全和性能属于专项质量层，不塞进普通组件测试。
-5. 检查是否已有命令、测试框架、目录约定和 CI 门禁；沿用项目现状，不为策略文档引入不必要工具。
-6. 规划失败证据：每个高风险项要说明失败时如何定位，例如断言、截图、trace、coverage、日志或报告。
-7. 设计测试数据与 mock 策略：共享 fixture 表达业务场景，测试数据 builder 只封装噪声字段，避免每个测试手写随机对象。
-8. 管理 flaky 风险：把时间、网络、动画、随机数、并发和外部服务标为不稳定来源，并指定隔离、重试和证据产物。
-9. 输出可执行的最小测试计划：每层覆盖什么、不覆盖什么、优先级、建议命令和责任 skill。
+1. Identify the type of change: pure logic, UI components, cross-module processes, browser capabilities, visual stability, dedicated quality risks, or release gates.
+2. Establish a test level matrix, at least distinguish:
+   - Static checking: TypeScript, ESLint, format, dependency security, build.
+   - Unit testing: utils, hooks/composables, state logic, schema, pure functions.
+   - Component testing: props/emits, user interaction, loading/error/empty, mock boundaries.
+   - Lightweight integration testing: form + API mock + routing/Store/Provider context.
+   - E2E: real browser, cross-page key journeys, authentication, payments, permissions, CI artifacts.
+   - Visual/interactive documentation: Storybook interaction, Chromatic, visual regression baseline.
+   - Special quality: a11y, security, performance, compatibility.
+3. Allocate coverage by risk: high-frequency core paths prioritize E2E, complex component status prioritizes component testing, pure logic prioritizes unit testing, and lightweight integration testing is used for cross-provider collaboration.
+4. Use the testing pyramid to control maintenance costs:
+   - The closer to pure logic, the more tests, the faster, and the more stable it is.
+   - E2E only covers key user journeys and real browser risks, not every branch.
+   - Vision, a11y, safety and performance belong to dedicated quality layers and are not included in ordinary component tests.
+5. Check whether commands, test frameworks, directory conventions, and CI gates already exist; use the current status of the project and do not introduce unnecessary tools to the policy document.
+6. Plan failure evidence: Each high-risk item should describe how to locate it when it fails, such as assertions, screenshots, traces, coverage, logs, or reports.
+7. Design test data and mock strategies: share fixtures to express business scenarios, and the test data builder only encapsulates noise fields to avoid handwriting random objects for each test.
+8. Manage flaky risks: Mark time, network, animation, nonce, concurrency, and external services as sources of instability, and specify isolation, retries, and evidence artifacts.
+9. Output the minimum executable test plan: what is covered by each layer, what is not covered, priority, recommended commands and responsibility skills.
 
 ## Constraints
 
-- 不把测试策略写成泛泛的“多写测试”；每个建议必须对应具体风险。
-- 不要求所有项目都补齐完整测试金字塔；按业务风险和团队维护能力裁剪。
-- 不把 E2E 当作单元/组件测试的替代品；不把组件测试当作真实浏览器兼容保证。
-- 不为小改动强制引入新框架；优先复用仓库已有工具和脚本。
-- 不追求没有风险说明的覆盖率数字；覆盖率只能辅助判断，不能替代场景覆盖。
-- 不把随机 fixture、共享全局状态或依赖执行顺序的测试纳入主干门禁。
+- Don't write the test strategy as a general "write more tests"; each suggestion must correspond to a specific risk.
+- All projects are not required to complete the complete testing pyramid; they are tailored according to business risks and team maintenance capabilities.
+- Do not consider E2E as a replacement for unit/component testing; do not consider component testing as a guarantee of true browser compatibility.
+- Do not force the introduction of new frameworks for small changes; give priority to reusing existing tools and scripts in the warehouse.
+- Do not pursue coverage figures without risk explanation; coverage can only assist judgment and cannot replace scene coverage.
+- Do not include random fixtures, shared global state, or tests that depend on execution order into trunk gates.
 
 ## Expected Output
 
-输出测试分层建议、风险到测试层的映射、优先级、建议命令、需新增或调整的测试文件范围，以及明确分流到哪些专项 skill 或 agent。
+Output test layering recommendations, mapping of risks to test layers, priorities, recommended commands, the scope of test files that need to be added or adjusted, and the specific skills or agents that need to be clearly diverted.

package/skills/fec-typescript-project-standard/SKILL.md

@@ -1,54 +1,54 @@
 ---
 name: fec-typescript-project-standard
-description: Use when creating, configuring, reviewing, or debugging TypeScript project standards across frontend apps, libraries, SDKs, CLIs, monorepo packages, tsconfig, strictness, module/moduleResolution, path aliases, project references, declaration files, package exports, public API types, DTOs, advanced generics, discriminated unions, type guards, type narrowing, or type-level regressions. Prefer framework project skills for React/Vue/Next/Nuxt component architecture; Chinese triggers include TypeScript 项目规范, TS 项目规范, TypeScript 类型安全, 类型建模, 泛型, 判别联合, 类型收窄, tsconfig, 声明文件.
+description: Use when creating, configuring, reviewing, or debugging TypeScript project standards across frontend apps, libraries, SDKs, CLIs, monorepo packages, tsconfig, strictness, module/moduleResolution, path aliases, project references, declaration files, package exports, public API types, DTOs, advanced generics, discriminated unions, type guards, type narrowing, or type-level regressions. Prefer framework project skills for React/Vue/Next/Nuxt component architecture; Chinese triggers include TypeScript project specification, TS project specification, TypeScript type safety, type modeling, generics, discriminative unions, type narrowing, tsconfig, declaration files.
 ---
 
-# TypeScript 项目规范
+# TypeScript project specifications
 
 ## Purpose
 
-统一 TypeScript 层的工程配置、类型边界和发布产物规则。适用于前端应用、组件库、SDK、CLI、monorepo package 和纯 TypeScript 工具库，但不接管 React、Vue、Next.js、Nuxt 或 Vite 的框架架构职责。
+Unify project configuration, type boundaries, and release product rules for the TypeScript layer. Works with front-end applications, component libraries, SDKs, CLIs, monorepo packages, and pure TypeScript tool libraries, but does not take over the framework architecture responsibilities of React, Vue, Next.js, Nuxt, or Vite.
 
 ## Procedure
 
-1. 识别 TypeScript 上下文
-   - 应用项目：优先检查 `tsconfig` 分层、strictness、路径别名、类型检查脚本和框架生成类型。
-   - 组件库或 SDK：优先检查 public API、声明文件、package exports、peer dependencies 类型边界和发布前 pack 校验。
-   - CLI 或 Node 工具：优先检查 Node 目标版本、ESM/CJS 策略、`moduleResolution`、shebang 产物和 `process.env` 类型边界。
-   - Monorepo package：优先检查 project references、composite build、包间导入边界和 workspace 路径别名是否泄漏到发布产物。
-   - React、Vue、Next.js、Nuxt 等框架的组件架构、路由组织和状态管理归对应框架 skill；本流程只处理跨框架 TypeScript 契约和工程边界。
-
-2. 收敛 `tsconfig`
-   - 默认开启 `strict`，不要为通过构建关闭 `noImplicitAny`、`strictNullChecks` 或 `exactOptionalPropertyTypes` 等关键约束。
-   - 按运行环境选择 `target`、`lib`、`module` 和 `moduleResolution`；浏览器应用、Node 脚本、库包不要共用一份含混配置。
-   - 将基础配置、应用配置、测试配置和构建声明配置拆开，避免测试全局类型污染生产代码。
-   - 路径别名必须同时被 TypeScript、bundler、test runner 和发布产物理解；库包不得发布无法解析的源码别名。
-
-3. 设计类型边界
-   - 外部输入、DTO、领域模型、UI view model、组件 props 和工具函数 API 分层命名。
-   - public API 的参数和返回值显式标注，内部局部变量优先依赖推断。
-   - 外部数据先以 `unknown` 接收，再通过 schema 或 type guard 收窄。
-   - 复杂泛型、判别联合、DTO 映射、类型守卫和类型测试加载 [类型安全参考](references/type-safety.md)；需要高级模式时加载 [类型安全模式](references/type-safety-patterns.md)。
-
-4. 固定发布与声明产物
-   - 库包必须确认 `package.json` 的 `exports`、`types`、`files` 和实际构建产物一致。
-   - 不默认双包发布；只有明确消费方需要时才同时产出 ESM/CJS，并验证类型入口不分叉。
-   - 通过 `tsc --emitDeclarationOnly`、构建工具声明插件或 API extractor 产出 `.d.ts`，并在发布前检查声明文件可被消费方解析。
-   - 不把测试、fixture、内部工具、未稳定类型或私有路径暴露到 package exports。
-
-5. 验证 TypeScript 质量
-   - 优先使用仓库已有脚本，如 `typecheck`、`build`、`test`、`lint` 和 package pack dry-run。
-   - Vite、Next、Nuxt 等构建不等于完整类型检查；CI 必须有独立 typecheck 或等效验证。
-   - 类型改动影响 public API 时补类型测试、编译期断言或消费方 fixture。
+1. Identify TypeScript context
+   - Application projects: Prioritize checking of `tsconfig` layering, strictness, path aliases, type checking scripts and framework generation types.
+   - Component library or SDK: Prioritize checking public API, declaration files, package exports, peer dependencies type boundaries and pre-release pack verification.
+   - CLI or Node tools: Prioritize checking Node target versions, ESM/CJS policies, `moduleResolution`, shebang artifacts, and `process.env` type boundaries.
+   - Monorepo package: Prioritize checking whether project references, composite builds, inter-package import boundaries, and workspace path aliases leak into release products.
+   - The component architecture, routing organization, and state management of frameworks such as React, Vue, Next.js, and Nuxt belong to the corresponding framework skills; this process only deals with cross-framework TypeScript contracts and project boundaries.
+
+2. Convergence `tsconfig`
+   - Turn on `strict` by default, do not turn off key constraints such as `noImplicitAny`, `strictNullChecks` or `exactOptionalPropertyTypes` for pass builds.
+   - Select `target`, `lib`, `module` and `moduleResolution` according to the running environment; browser applications, Node scripts, and library packages should not share an ambiguous configuration.
+   - Separate basic configuration, application configuration, test configuration and build declaration configuration to avoid testing global types from polluting production code.
+   - Path aliases must be understood by TypeScript, bundler, test runner, and published products at the same time; library packages must not publish source code aliases that cannot be resolved.
+
+3. Design type boundaries
+   - Hierarchical naming of external input, DTO, domain model, UI view model, component props and tool function API.
+   - The parameters and return values of the public API are explicitly marked, and internal local variables are inferred first.
+   - External data is received as `unknown` first, and then narrowed by schema or type guard.
+   - Complex generics, discriminative unions, DTO mappings, type guards and type tests are loaded [Type Safety Reference](references/type-safety.md); [Type Safety Patterns](references/type-safety-patterns.md) is loaded when advanced patterns are required.
+
+4. Fixed release and announcement of products
+   - The library package must confirm that the `exports`, `types`, and `files` of `package.json` are consistent with the actual build product.
+   - Do not default to dual-package publishing; only produce ESM/CJS at the same time when the consumer clearly needs it, and verify that the type entry does not fork.
+   - Produce `.d.ts` through `tsc --emitDeclarationOnly`, build tool declaration plug-in or API extractor, and check that the declaration file can be parsed by the consumer before publishing.
+   - Do not expose tests, fixtures, internal tools, unstable types, or private paths to package exports.
+
+5. Verify TypeScript quality
+   - Prioritize the use of existing scripts in the repository, such as `typecheck`, `build`, `test`, `lint` and package pack dry-run.
+   - Vite, Next, Nuxt, etc. builds do not equal full type checking; CI must have standalone typecheck or equivalent verification.
+   - Type changes affect public API time-filling type tests, compile-time assertions, or consumer fixtures.
 
 ## Constraints
 
-- 不用 `skipLibCheck`、`any`、无守卫非空断言或宽泛 `as` 掩盖真实边界问题。
-- 不在应用代码中依赖发布包私有深层路径。
-- 不把框架目录结构、组件分层、路由组织或状态管理决策放进本流程；这些交给对应框架或专项流程。
-- 不让生成类型、测试类型或 Node-only 类型污染浏览器运行代码。
-- 不发布只能在源码仓库内解析的路径别名、ambient 声明或隐式全局类型。
+- Don't use `skipLibCheck`, `any`, unguarded non-null assertions or the wide `as` to mask real boundary issues.
+- Do not rely on release package private deep paths in application code.
+- Do not put framework directory structure, component layering, routing organization or state management decisions into this process; these are left to the corresponding framework or dedicated process.
+- Don't pollute browser running code with generated, test, or Node-only types.
+- Do not publish path aliases, ambient declarations, or implicit global types that can only be resolved within the source code repository.
 
 ## Expected Output
 
-输出应包含 TypeScript 上下文判断、关键 `tsconfig`/package 类型入口建议、类型边界方案、声明文件或 public API 风险、验证命令。完成后项目应能独立 typecheck，公开类型可被消费方解析，类型安全问题有明确收窄或建模方案。
+The output should include TypeScript context determinations, key `tsconfig`/package type entry suggestions, type boundary schemes, declaration file or public API risks, and verification commands. After completion, the project should be able to independently typecheck, public types can be parsed by consumers, and type safety issues should have clear narrowing or modeling solutions.

package/skills/fec-typescript-project-standard/references/type-safety-patterns.md

@@ -1,15 +1,15 @@
-# 类型安全模式
+# Type safety mode
 
-## 类型边界审查清单
+## Type Boundary Review Checklist
 
-- DTO 应与外部载荷对应，并在 API 边界处进行转换。
-- 领域模型或视图模型使用前端命名和稳定的联合类型。
-- 组件 props 需命名明确，仅在该文件外复用时才导出。
-- 公开函数必须有显式的参数和返回值类型。
-- 外部输入必须从 `unknown` 开始，通过 schema 校验或类型守卫逐步收窄。
-- 配置映射表优先使用 `as const` 和 `satisfies`，避免宽泛断言。
+- DTOs should correspond to external loads and be converted at API boundaries.
+- Domain model or view model uses front-end naming and stable union types.
+- Component props need to be named clearly and exported only when reused outside this file.
+- Public functions must have explicit parameter and return value types.
+- External input must start from `unknown` and be gradually narrowed through schema verification or type guarding.
+- Configure mapping tables using `as const` and `satisfies` first to avoid broad assertions.
 
-## 使用 `satisfies` 的配置映射表
+## Use the configuration mapping table of `satisfies`
 
 ```ts
 type Tone = "neutral" | "success" | "warning" | "danger";
@@ -23,9 +23,9 @@ const STATUS_TONE = {
 type InvoiceStatus = keyof typeof STATUS_TONE;
 ```
 
-这样既保留了字面量值，又验证了映射表符合预期的值域。
+This not only preserves the literal value, but also verifies that the mapping table conforms to the expected value range.
 
-## 映射类型用于表单错误
+## Mapping type used for form errors
 
 ```ts
 type FieldErrors<TValues extends Record<string, unknown>> = {
@@ -40,7 +40,7 @@ interface ProfileFormValues {
 type ProfileFormErrors = FieldErrors<ProfileFormValues>;
 ```
 
-## 模板字面量类型用于事件命名
+## Template literal type is used for event naming
 
 ```ts
 interface AnalyticsPayloads {
@@ -52,9 +52,9 @@ type AnalyticsEventName = keyof AnalyticsPayloads;
 type AnalyticsHandlerName = `on${Capitalize<string & AnalyticsEventName>}`;
 ```
 
-当项目中已有事件命名规范时使用此模式。不要为一次性字符串引入。
+Use this pattern when there is already an event naming convention in the project. Don't introduce it for one-time strings.
 
-## 更安全的泛型组件模式
+## Safer generic component pattern
 
 ```tsx
 interface Entity {
@@ -92,11 +92,11 @@ export function EntityPicker<TEntity extends Entity>({
 }
 ```
 
-## 类型审查反馈
+## Type Review Feedback
 
-报告类型安全问题时，需包含：
+When reporting a type safety issue, include:
 
-- 过于宽泛、过于狭窄或不合理的类型边界。
-- 尽管通过 TypeScript 但可能在运行时失败的行为。
-- 最小替换类型或守卫方案。
-- 该变更是否需要测试或类型测试。
+- Type boundaries that are too broad, too narrow, or unreasonable.
+- Behavior that may fail at runtime despite passing TypeScript.
+- Minimal replacement type or guard scheme.
+- Whether the change requires testing or type testing.

package/skills/fec-typescript-project-standard/references/type-safety.md

@@ -1,14 +1,14 @@
-# TypeScript 类型安全
+#TypeScript type safety
 
 ## Purpose
 
-为前端和 TypeScript 工程建立可演进的类型契约，减少 `any`、断言和运行时形状漂移。
+Establish evolvable type contracts for front-end and TypeScript projects, reducing `any`, assertions, and runtime shape drift.
 
 ## Procedure
 
-### 1. 先确定类型边界
+### 1. First determine the type boundary
 
-把类型分为外部输入、领域模型、UI view model、组件 props、工具函数 API。不要让后端 DTO、表单模型和 UI 展示模型互相冒充。
+Divide types into external input, domain model, UI view model, component props, and tool function API. Don't let backend DTOs, form models, and UI presentation models pretend to be each other.
 
 ```ts
 interface UserDto {
@@ -32,9 +32,9 @@ export function mapUserDto(dto: UserDto): UserViewModel {
 }
 ```
 
-### 2. 用 `unknown` 和收窄处理不可信数据
+### 2. Use `unknown` and narrowing to handle untrusted data
 
-外部输入先校验再使用。不要用 `as` 让编译器闭嘴。
+External input must be verified before use. Don't use `as` to shut up the compiler.
 
 ```ts
 interface ApiErrorBody {
@@ -55,9 +55,9 @@ export function getApiErrorMessage(value: unknown): string {
 }
 ```
 
-### 3. 用判别联合表达状态机
+### 3. Express state machine using discriminant union
 
-异步状态、权限分支、支付状态等有限状态，用判别字段让新增分支在编译期暴露。
+Limited states such as asynchronous status, permission branches, payment status, etc. use discriminant fields to expose new branches during compilation.
 
 ```ts
 type Loadable<T> =
@@ -86,9 +86,9 @@ export function renderUserState(user: Loadable<{ name: string }>): string {
 }
 ```
 
-### 4. 让泛型服务调用方，而不是炫技
+### 4. Let generics serve callers, not show off their skills
 
-泛型应减少重复并保持调用方推断清晰。复杂类型超过阅读成本时，优先拆具名类型。
+Generics should reduce duplication and keep caller inference clear. When the complex type exceeds the reading cost, the named type will be demolished first.
 
 ```ts
 interface SelectOption<TValue extends string | number> {
@@ -119,9 +119,9 @@ export function Select<TValue extends string | number>({
 }
 ```
 
-### 5. 用类型测试保护公共类型
+### 5. Protect public types with type testing
 
-公共工具类型、组件库类型和 SDK 类型，应有轻量类型测试或编译期断言。
+Public tool types, component library types, and SDK types should have lightweight type tests or compile-time assertions.
 
 ```ts
 type Equal<TLeft, TRight> =
@@ -137,12 +137,12 @@ type _UserStatusTest = Expect<Equal<UserStatus, "active" | "disabled">>;
 
 ## Constraints
 
-- 避免 `any`、无守卫的非空断言和不相关类型之间的强制 `as`。
-- 不把大型匿名类型堆在函数参数或 JSX props 上；提取具名类型表达业务含义。
-- 不为简单业务过度设计递归条件类型；类型复杂度应服务可维护性。
-- 公共 API 的输入输出必须显式标注，局部变量可依赖推断。
-- 类型建模不能替代运行时校验；外部数据仍需 schema 或 type guard。
+- Avoid `any`, unguarded non-null assertions and coercion `as` between unrelated types.
+- Don’t pile large anonymous types on function parameters or JSX props; extract named types to express business meaning.
+- Do not over-design recursive conditional types for simple business; type complexity should serve maintainability.
+- The input and output of the public API must be explicitly annotated, and local variables can be relied upon for inference.
+- Type modeling does not replace runtime validation; external data still requires schema or type guard.
 
 ## Expected Output
 
-产出清晰的类型边界、可收窄的数据模型、必要的类型测试和验证命令。评审时应列出类型风险、运行时影响、推荐建模方式和是否需要专项修复。
+Produce clear type boundaries, narrowable data models, and necessary type testing and verification commands. The review should list type risks, runtime impacts, recommended modeling methods, and whether special fixes are needed.