@bovinphang/frontend-craft 2.7.0 → 2.9.0

package/skills/fec-responsive-layout/references/responsive-layout-patterns.md

@@ -1,16 +1,16 @@
-# 响应式布局模式
+# Responsive layout mode
 
-## 策略选择
+## Strategy selection
 
-| 场景 | 策略 |
+| Scenario | Strategy |
 | ---- | ---- |
-| 页面级结构 | 移动优先断点 |
-| 会被放进未知父容器的复用组件 | 容器查询 |
-| 卡片网格 | `repeat(auto-fit, minmax())`，并设置合理最小宽度 |
-| 数据表格 | 列优先级、横向滚动或移动端摘要行 |
-| 编辑器 / 画布 / dashboard | 稳定外壳 + 可滚动工作区 |
+| Page-level structure | Mobile-first breakpoints |
+| Reused components that will be put into unknown parent containers | Container query |
+| Card grid | `repeat(auto-fit, minmax())` and set a reasonable minimum width |
+| Data tables | Column priority, horizontal scrolling, or mobile summary rows |
+| Editor / canvas / dashboard | Stable shell + scrollable workspace |
 
-## CSS 模式
+## CSS Patterns
 
 ```css
 .card-grid {
@@ -32,39 +32,39 @@
 }
 ```
 
-当 grid/flex 子项包含长文本、表格、代码、图表或媒体时，给子项设置 `min-width: 0`。
+When grid/flex items contain long text, tables, code, charts, or media, set `min-width: 0` to the items.
 
-## 数据密集型界面
+## Data-intensive interface
 
-- 编码前先确定移动端列优先级。
-- 主标识、状态和主要操作保持可见。
-- 低优先级元数据移入详情行、抽屉或可展开面板。
-- 小屏仍要保留排序、筛选、分页和选择能力。
-- 虚拟滚动只解决 DOM 数量问题，不能解决信息层级问题。
-- 表格可以局部横向滚动，但页面整体不应出现无意水平溢出。
+- Prioritize mobile columns before coding.
+- The main logo, status and main actions remain visible.
+- Low priority metadata moved to details row, drawer or expandable panel.
+- Small screens must still retain the ability to sort, filter, paging, and select.
+- Virtual scrolling only solves the problem of DOM quantity, but cannot solve the problem of information hierarchy.
+- The table can be partially scrolled horizontally, but the page as a whole should not have unintentional horizontal overflow.
 
-## 响应式媒体
+## Responsive media
 
-- 图片和视频要有稳定尺寸、`aspect-ratio` 或容器约束，避免加载后推挤布局。
-- 需要多尺寸资源时使用 `srcset`、`sizes` 或 `<picture>`，不要让移动端下载桌面大图。
-- 非首屏图片默认懒加载；首屏主体图按框架能力设置明确优先级。
-- 媒体裁切必须保留主体信息；不要为了填满卡片裁掉产品、人物、图表关键区域。
+- Images and videos must have stable size, `aspect-ratio` or container constraints to avoid pushing the layout after loading.
+- Use `srcset`, `sizes` or `<picture>` when you need multi-size resources, and do not let the mobile client download desktop large images.
+- Non-first-screen images are lazy-loaded by default; first-screen main images are prioritized clearly based on frame capabilities.
+- Media cropping must retain the main information; do not crop key areas of products, people, or charts just to fill the card.
 
-## 触控与视口检查
+## Touch and viewport inspection
 
-- 空间允许时，交互目标至少 44x44px。
-- 移动端输入框字号避免低于 16px。
-- 固定底部栏和操作条必须考虑 `env(safe-area-inset-bottom)`。
-- 对话框和抽屉需要适配虚拟键盘导致的视口变化。
-- 只在 hover 时出现的内容必须提供点击、焦点或常驻可见替代方案。
-- iOS/Android 横竖屏切换后，主操作、焦点位置和滚动容器仍应可达。
-- 需要局部滚动的区域应明确最大高度和滚动边界，避免页面和内部容器互相抢滚动。
+- Interactive targets should be at least 44x44px, space permitting.
+- Avoid lowering the font size of the mobile input box below 16px.
+- Fixed bottom bars and action bars must consider `env(safe-area-inset-bottom)`.
+- Dialog boxes and drawers need to adapt to viewport changes caused by the virtual keyboard.
+- Content that only appears on hover must provide click, focus, or permanently visible alternatives.
+- After switching between horizontal and vertical screens on iOS/Android, the main operation, focus position and scroll container should still be accessible.
+- Areas that require partial scrolling should have a clear maximum height and scrolling boundary to prevent the page and internal containers from competing for scrolling.
 
-## 验证清单
+## Verification list
 
-- 320-375px：页面级没有横向溢出。
-- 768px：布局切换后阅读顺序仍然合理。
-- 1024-1440px：内容宽度有约束，扫描路径清晰。
-- 长标签、翻译文本、数字以及 empty/error/loading 状态不会撑坏固定格式控件。
-- 横竖屏切换不会困住焦点或隐藏主操作。
-- 虚拟键盘弹出时，输入框、提交按钮和错误提示不被遮挡。
+- 320-375px: No horizontal overflow at the page level.
+- 768px: The reading order is still reasonable after the layout is switched.
+- 1024-1440px: The content width is constrained and the scanning path is clear.
+- Long labels, translated text, numbers, and empty/error/loading states will not break fixed format controls.
+- Switching between horizontal and vertical screens will not trap focus or hide the main operation.
+- When the virtual keyboard pops up, the input box, submit button and error prompt are not blocked.

package/skills/fec-route-protection/SKILL.md

@@ -1,24 +1,24 @@
 ---
 name: fec-route-protection
-description: Use when implementing or reviewing frontend route protection, auth guards, RBAC, permission routes, login state handling, redirects, middleware, React Router, Next.js, Vue Router, or Nuxt route middleware; Chinese triggers include 路由保护, 权限路由, 登录态.
+description: Use when implementing or reviewing frontend route protection, auth guards, RBAC, permission routes, login state handling, redirects, middleware, React Router, Next.js, Vue Router, or Nuxt route middleware; Chinese triggers include route protection, permission routing, login state.
 ---
 
-# 路由保护
+#Route protection
 
 ## Purpose
 
-为前端应用建立清晰的认证、授权和重定向边界，避免越权访问与闪烁渲染。
+Establish clear authentication, authorization and redirection boundaries for front-end applications to avoid unauthorized access and flickering rendering.
 
 ## When to Use
 
-- 页面需要登录后访问，或不同角色看到不同路由。
-- 需要实现 React Router、Next.js、Nuxt 或 Vue Router 的路由守卫。
-- 登录过期、权限不足、组织/租户切换需要统一处理。
-- 不用于替代服务端授权；前端路由保护只能改善体验，不能作为唯一安全边界。
+- The page needs to be logged in to access, or different roles can see different routes.
+- Requires implementing route guards for React Router, Next.js, Nuxt or Vue Router.
+- Login expiration, insufficient permissions, and organization/tenant switching need to be handled uniformly.
+- Not used to replace server-side authorization; front-end routing protection can only improve the experience and cannot be used as the only security boundary.
 
 ## Procedure
 
-### 1. 定义认证与授权状态
+### 1. Define authentication and authorization status
 
 ```ts
 export type AuthStatus = "loading" | "anonymous" | "authenticated";
@@ -34,7 +34,7 @@ export function canAccess(user: CurrentUser, required: string[]) {
 }
 ```
 
-### 2. React Router 使用布局守卫
+### 2. React Router uses layout guards
 
 ```tsx
 import { Navigate, Outlet, useLocation } from "react-router-dom";
@@ -68,7 +68,7 @@ const router = createBrowserRouter([
 ]);
 ```
 
-### 3. Next.js 优先在服务端边界处理
+### 3. Next.js prioritizes processing at the server boundary
 
 ```ts
 // middleware.ts
@@ -92,9 +92,9 @@ export const config = {
 };
 ```
 
-对需要精细权限的 App Router 页面，在 server component 或 server action 中重新校验权限，不依赖客户端状态。
+For App Router pages that require fine-grained permissions, re-verify permissions in the server component or server action, regardless of client status.
 
-### 4. Vue Router / Nuxt 使用导航守卫
+### 4. Vue Router / Nuxt uses navigation guards
 
 ```ts
 router.beforeEach(async (to) => {
@@ -112,24 +112,24 @@ router.beforeEach(async (to) => {
 });
 ```
 
-### 5. 统一失败与跳转体验
+### 5. Unify failure and jump experience
 
-- `401`：清理过期会话，跳转登录页并保留 `redirect`。
-- `403`：进入无权限页，不反复重试。
-- `loading`：渲染稳定骨架屏，避免先显示私有内容再跳转。
-- 登录成功：只跳转到同源且允许的路径，防止 open redirect。
-- RBAC：权限矩阵来自可信会话或后端返回；前端只用于路由体验和 UI 裁剪，不能替代接口授权。
-- 会话刷新：401 刷新失败后统一清理状态；避免多个并发请求各自触发跳转或刷新风暴。
+- `401`: Clean up expired sessions, jump to the login page and keep `redirect`.
+- `403`: Enter the unauthorized page, do not try again.
+- `loading`: Render a stable skeleton screen to avoid displaying private content first and then jumping.
+- Successful login: only jump to the same origin and allowed path to prevent open redirect.
+- RBAC: The permission matrix is returned from the trusted session or backend; the frontend is only used for routing experience and UI tailoring, and cannot replace interface authorization.
+- Session refresh: Uniformly clean up status after 401 refresh failure; avoid multiple concurrent requests from triggering jumps or refresh storms.
 
 ## Constraints
 
-- 前端路由保护不是安全边界；API、SSR loader、server action 必须重复做授权校验。
-- 不要在组件渲染后用 `useEffect` 才跳转私有页面，否则会出现敏感内容闪烁。
-- redirect 参数必须限制为站内路径，不能直接信任 URL 输入。
-- 权限信息应来自可信会话或后端响应，不要只依赖 localStorage 中的角色字段。
-- 多租户应用必须把 tenant/org 上下文纳入权限判断。
-- 不把菜单隐藏视为授权完成；用户直接访问 URL、刷新页面、篡改 localStorage 和替换 tenant 都必须验证。
+- Front-end routing protection is not a security boundary; API, SSR loader, and server actions must undergo repeated authorization verification.
+- Do not use `useEffect` to jump to the private page after the component is rendered, otherwise sensitive content will flicker.
+- The redirect parameter must be restricted to within-site paths and URL input cannot be trusted directly.
+- Permission information should come from a trusted session or backend response, don't rely solely on role fields in localStorage.
+- Multi-tenant applications must incorporate the tenant/org context into permission determinations.
+- Menu hiding is not considered authorization completion; users must authenticate when accessing the URL directly, refreshing the page, tampering with localStorage, and replacing tenants.
 
 ## Expected Output
 
-产出一套路由守卫实现，覆盖 loading、未登录、权限不足、登录后回跳和会话过期。验证时直接访问私有 URL、刷新页面、切换角色、篡改 redirect 参数，确认行为稳定且 API 仍有服务端授权。
+Produce a set of routing guard implementations, covering loading, not logged in, insufficient permissions, bounce after login and session expiration. During verification, directly access the private URL, refresh the page, switch roles, and tamper with redirect parameters to confirm that the behavior is stable and the API still has server authorization.

package/skills/fec-security-review/SKILL.md

@@ -1,38 +1,54 @@
 ---
 name: fec-security-review
-description: Use when reviewing frontend security risks such as XSS, CSRF, sensitive data exposure, unsafe DOM APIs, untrusted user input, authentication/token handling, payment flows, file upload, CSP, dependency risk, or third-party scripts; Chinese triggers include 安全审查, 安全检查.
+description: Use when reviewing frontend security risks such as XSS, CSRF, sensitive data exposure, unsafe DOM APIs, untrusted user input, authentication/token handling, payment flows, file upload, CSP, dependency risk, or third-party scripts; Chinese triggers include security review, security check.
 ---
 
-# 前端安全审查
+# Front-end security review
+
+## Review modes and coverage
+
+User-specified scope takes precedence over the default. Use the following three review modes:
+
+- **Change review**: only when recent changes, current edits, staged changes, a PR or a commit are explicitly requested or clearly established by the active task, review those changes and necessary context. For local changes, inspect staged and unstaged diffs and relevant untracked project files within the requested scope; a staged-only request reviews only staged changes. If there are no changes, report that there is nothing to review; do not switch to recent commits or expand scope automatically.
+- **Targeted review**: when files or directories are specified, inventory and review existing code in that scope, including unchanged code; no Git diff is required.
+- **Project review (default)**: when no scope or change context is specified, or when the entire project is requested, inventory project-owned frontend code, related tests, configuration and dependency declarations, then review in module batches, including unchanged code; no Git diff is required.
+
+Select scope before collecting diffs. A file/directory alone means full review of that scope; a path combined with an explicit change request restricts incremental review to that path. An unqualified invocation defaults to project review even if Git changes exist. At review start, state the selected mode and target scope. When automatically delegating review after edits, pass the current change scope explicitly; do not trigger project review merely because the reviewer was called.
+
+Exclude dependency directories, build outputs, caches, generated files and third-party code by default, and record exclusions. Keep the frontend responsibility boundary; this is not a backend audit. A nonexistent target or a scope with no relevant files must be reported explicitly, not replaced with another scope.
+
+Merge findings with the same root cause across batches. Report **review mode, target scope, reviewed files/modules, exclusions, unreviewed files/modules, completion status and verification commands/results**. If context or execution limits prevent completion, mark the review partial and list remaining modules; never claim complete project coverage. Reading callers for context or running project-wide lint/typecheck does not count as manual review of those files.
+
+Change reviews retain merge recommendations. Targeted and project reviews use a risk assessment (Low / Medium / High, with blocking findings), not a claim of merge readiness. Preserve severity levels, evidence requirements and report filenames. Output reports only unless repairs are explicitly requested.
 
 ## Purpose
 
-识别前端代码中的客户端安全风险，并给出可执行修复建议。
+Identify client-side security risks in front-end code and recommend actionable fixes.
 
 ## Procedure
 
-1. 先确认审查面：用户输入、动态 HTML、URL 跳转、认证态、RBAC、文件上传、支付/删除等敏感操作、第三方脚本和依赖。
-2. 搜索高危模式：`dangerouslySetInnerHTML`、`v-html`、`innerHTML`、`document.write`、动态 script、未校验 redirect、明文 token。
-3. 按风险类型审查：XSS、CSP、敏感数据、CSRF、依赖、输入校验、文件上传、开放重定向、认证授权和第三方脚本。
-4. 用边界模型判断责任：客户端只能改善体验和减少误用，鉴权、授权、上传信任和敏感操作必须由服务端最终裁决。
-5. 高危问题标记为阻塞合并；前端校验只能改善体验，不能作为唯一安全边界。
-6. 输出分级安全报告；报告格式见 [references/report-template.md](references/report-template.md)。
+1. First confirm the review areas: user input, dynamic HTML, URL jump, authentication status, RBAC, file upload, payment/deletion and other sensitive operations, third-party scripts and dependencies.
+2. Search for high-risk patterns: `dangerouslySetInnerHTML`, `v-html`, `innerHTML`, `document.write`, dynamic script, unverified redirect, and plain text token.
+3. Review by risk type: XSS, CSP, sensitive data, CSRF, dependencies, input validation, file upload, open redirection, authentication authorization and third-party scripts.
+4. Use the boundary model to determine responsibility: The client can only improve the experience and reduce misuse. Authentication, authorization, upload trust and sensitive operations must be finalized by the server.
+5. High-risk issues are marked as blocking merges; front-end verification can only improve the experience and cannot be used as the only security boundary.
+6. Output a hierarchical security report; see [references/report-template.md](references/report-template.md) for the report format.
 
-## 详细参考
+## Detailed reference
 
-- 需要 XSS、CSP、敏感数据、CSRF、依赖和输入校验细节时，加载 [references/security-checklist.md](references/security-checklist.md)。
-- 撰写安全审查报告时，加载 [references/report-template.md](references/report-template.md)。
+- Load [references/security-checklist.md](references/security-checklist.md) when XSS, CSP, sensitive data, CSRF, dependencies and input validation details are required.
+- When writing a security review report, load [references/report-template.md](references/report-template.md).
 
 ## Constraints
 
-- 不要为了方便开发而绕过安全机制。
-- 不要依赖前端校验作为唯一安全防线。
-- 不要信任任何来自客户端的数据。
-- 发现高危问题时必须标记为阻塞合并。
-- 与通用代码质量 review 分工：本 skill 关注威胁、攻击面和数据泄露。
-- 不把依赖审计结果机械等同为可利用漏洞；需要结合运行路径、暴露面和修复成本判断。
-- 不把隐藏按钮、前端路由守卫或本地角色字段当作授权边界；API、SSR loader、server action 和敏感操作必须有服务端裁决。
+- Don't bypass security mechanisms to facilitate development.
+- Don't rely on front-end validation as your only line of security.
+- Do not trust any data coming from the client.
+- High-risk issues must be marked as blocking merges when found.
+- Separated from general code quality review: This skill focuses on threats, attack surfaces, and data breaches.
+- Do not mechanically equate dependence on audit results with exploitable vulnerabilities; judgments need to be made based on the running path, exposure surface and repair cost.
+- Do not treat hidden buttons, front-end route guards, or local role fields as authorization boundaries; APIs, SSR loaders, server actions, and sensitive operations must have server-side arbitration.
 
 ## Expected Output
 
-输出 CRITICAL/HIGH/MEDIUM/LOW 分级安全审查报告，每个问题关联具体文件和行号，给出修复建议；报告保存为 `reports/security-review-YYYY-MM-DD-HHmmss.md`。
+Output a CRITICAL/HIGH/MEDIUM/LOW graded security review report. Each issue is associated with a specific file and line number, and repair suggestions are given; the report is saved as `reports/security-review-YYYY-MM-DD-HHmmss.md`.

package/skills/fec-security-review/references/report-template.md

@@ -1,27 +1,37 @@
-# 安全审查报告模板
+# Security review report template
 
 ```markdown
-# 安全审查报告
+# Security Review Report
 
-> 生成时间: YYYY-MM-DD HH:mm
-> 评审工具: frontend-craft
+> Generation time: YYYY-MM-DD HH:mm
+> Review tool: frontend-craft
 
-## CRITICAL / 高危 (N项)
-- **[文件:行号]** 风险描述 -> 修复建议
+> Review mode: change / targeted / project
+> Target scope: paths or PR/commit
+> Reviewed: file or module inventory
+> Exclusions: paths and reasons
+> Unreviewed: remaining files or modules (state none if complete)
+> Completion: complete / partial
+> Verification: commands, results and reasons for skipped checks
 
-## HIGH / 中高危 (N项)
+## CRITICAL / HIGH RISK (N items)
+- **[File:line number]** Risk description -> Repair suggestions
+
+## HIGH / Medium to high risk (N items)
 - ...
 
-## MEDIUM / 中危 (N项)
+## MEDIUM / medium risk (N items)
 - ...
 
-## LOW / 低危或建议 (N项)
+## LOW / low risk or recommended (N items)
 - ...
 
-## 已通过的安全检查
+## Passed security check
 - ...
 
-**整体安全等级**: 安全 / 存在风险 / 高危需修复
+**Overall security level**: safe / risky / high risk and needs to be repaired
 ```
 
-审查完成后，将报告保存到 `reports/security-review-YYYY-MM-DD-HHmmss.md`，并告知用户报告路径。
+After the review is completed, save the report to `reports/security-review-YYYY-MM-DD-HHmmss.md` and inform the user of the report path.
+
+Retain merge recommendations for change review; use risk assessments for targeted and project reviews. For partial reviews, conclusions apply only to reviewed scope and do not establish project-wide approval.

package/skills/fec-security-review/references/security-checklist.md

@@ -1,12 +1,12 @@
-# 前端安全审查清单
+# Front-end security review checklist
 
 ## XSS
 
-- `dangerouslySetInnerHTML` 和 `v-html` 必须有明确理由和输入净化。
-- 用户输入不得直接插入 DOM、`innerHTML`、`document.write`。
-- URL 参数不得直接用于页面渲染。
-- 动态生成的 `<script>` 标签必须审查来源。
-- 富文本使用 DOMPurify 等库，并配置标签、属性、协议白名单。
+- `dangerouslySetInnerHTML` and `v-html` must have explicit reason and input sanitization.
+- User input must not be inserted directly into the DOM, `innerHTML`, `document.write`.
+- URL parameters must not be used directly in page rendering.
+- Dynamically generated `<script>` tags must be sourced.
+- Rich text uses libraries such as DOMPurify and configures tags, attributes, and protocol whitelists.
 
 ```ts
 import DOMPurify from "dompurify";
@@ -18,7 +18,7 @@ const clean = DOMPurify.sanitize(dirtyHtml, {
 });
 ```
 
-## 安全重定向
+## Safe redirection
 
 ```ts
 function safeRedirect(url: string): string {
@@ -29,36 +29,36 @@ function safeRedirect(url: string): string {
 
 ## CSP
 
-- 推荐先用 `Content-Security-Policy-Report-Only` 验证。
-- `default-src 'self'`、`object-src 'none'`、`frame-ancestors 'none'`、`base-uri 'self'` 是常见底线。
-- 避免 `'unsafe-eval'`；内联脚本优先 nonce。
+- It is recommended to verify with `Content-Security-Policy-Report-Only` first.
+- `default-src 'self'`, `object-src 'none'`, `frame-ancestors 'none'`, `base-uri 'self'` are common bottom lines.
+- Avoid `'unsafe-eval''; inline scripts take precedence over nonce.
 
 ```http
 Content-Security-Policy: default-src 'self'; script-src 'self'; object-src 'none'; frame-ancestors 'none'; base-uri 'self'; form-action 'self';
 ```
 
-## 敏感数据
+## Sensitive data
 
-- 禁止前端硬编码 API Key、Secret、密码。
-- 禁止 localStorage/sessionStorage/IndexedDB 存明文 token、密码、信用卡信息。
-- 禁止 URL query 参数传 token 或密码。
-- 禁止 console.log 或错误上报携带隐私数据。
-- Token 优先 httpOnly + Secure + SameSite cookie。
+- It is prohibited to hard-code API Key, Secret, and password on the front end.
+- LocalStorage/sessionStorage/IndexedDB is prohibited from storing plain text tokens, passwords, and credit card information.
+- Prohibit URL query parameters from passing token or password.
+- Console.log or error reports are prohibited from carrying private data.
+- Token priority httpOnly + Secure + SameSite cookie.
 
 ## CSRF
 
-- 变更操作必须携带 CSRF token 或使用同等后端防护。
-- 关键操作不要使用 GET。
-- 检查后端是否校验 `Origin` / `Referer`。
+- Change operations must carry CSRF tokens or use equivalent backend protection.
+- Do not use GET for critical operations.
+- Check whether the backend verifies `Origin` / `Referer`.
 
-## 依赖与第三方脚本
+## Dependencies and third-party scripts
 
-- 定期审查依赖安全公告。
-- 禁止从非官方 CDN 加载脚本，除非有 SRI 和来源审查。
-- 动态加载第三方脚本必须有业务必要性和降级策略。
+- Regularly review dependency security bulletins.
+- Disallow script loading from unofficial CDNs unless SRI and source vetted.
+- Dynamically loading third-party scripts must have business necessity and a downgrade strategy.
 
-## 输入校验与文件上传
+## Input verification and file upload
 
-- 前端校验不是安全边界，后端必须二次校验。
-- 文件上传校验 MIME、大小、扩展名和内容；不能只看扩展名。
-- 正则校验注意 ReDoS 风险。
+- Front-end verification is not a security boundary, and the back-end must be verified twice.
+- File uploads verify MIME, size, extension and content; don't just look at the extension.
+- Pay attention to ReDoS risks in regular verification.

package/skills/fec-source-driven-development/SKILL.md

@@ -1,87 +1,87 @@
 ---
 name: fec-source-driven-development
-description: Use when frontend decisions depend on framework, library, browser, runtime, package, API, or platform behavior that may have changed, including official documentation checks, version-sensitive patterns, migration choices, or public interface assumptions; Chinese triggers include 查官方文档, 以源码为准, source-driven, 版本差异.
+description: Use when frontend decisions depend on framework, library, browser, runtime, package, API, or platform behavior that may have changed, including official documentation checks, version-sensitive patterns, migration choices, or public interface assumptions; Chinese triggers include Check official documentation, source code shall prevail, source-driven, version differences.
 ---
 
-# 来源驱动开发
+# Source driven development
 
 ## Purpose
 
-在前端实现、评审和架构决策中优先依据项目内事实、官方文档和当前版本行为，避免沿用过时经验或未经验证的假设。
+Prioritize the use of in-project facts, official documentation, and current version behavior in front-end implementation, review, and architecture decisions, and avoid relying on outdated experience or unverified assumptions.
 
 ## Procedure
 
-1. 判断是否需要查源
-   - 涉及框架新版本、路由、渲染模式、缓存、构建工具、浏览器 API、包发布格式、鉴权协议或公共接口时必须查源。
-   - 涉及项目约定时先读本仓库 README、配置、模板、已有实现、测试和迁移记录。
-   - 只是稳定语言语法或明显局部重构时，可使用项目现有模式作为事实来源。
-
-2. 收集权威材料
-   - 首选官方文档、规范、源码、release notes、migration guide、类型定义和项目内测试。
-   - 第三方文章只能作为线索，不能作为最终依据。
-   - 对快速变化的库记录包名、版本、文档日期或页面标题。
-   - 当用户要求从本地知识库、项目资料库或 `knowledge/` 目录回答问题时，先走本地知识检索，不使用网络搜索补事实。
-
-3. 提炼决策
-   - 写清当前版本推荐做法、弃用做法、限制条件和迁移注意事项。
-   - 对多个可行方案说明选择理由、兼容性、维护成本和回退方式。
-   - 若文档和项目现状冲突，优先解释冲突并给出渐进调整，不直接推翻已运行系统。
-   - 对依赖升级、框架迁移和公共 API 变化，记录 release notes、migration guide、版本范围、破坏性变更和回滚方案。
-
-4. 落到实现
-   - 将外部行为隔离在适配层、配置层或小型工具函数中，避免在组件里散落版本假设。
-   - 公共接口变化要保持命名、错误形状、默认值和兼容策略清晰。
-   - 代码注释只记录非显而易见的来源约束，不粘贴大段文档。
-
-5. 验证假设
-   - 用类型检查、最小复现、单元测试、组件测试、E2E、构建或浏览器验证证明关键假设。
-   - 如果无法验证，报告不确定性、风险范围和需要用户或团队确认的信息。
-6. 留下轻量决策记录
-   - 当结论会影响公共接口、依赖版本、目录规范或团队工作流时，补充 ADR/变更记录或交给文档同步流程。
+1. Determine whether it is necessary to check the source
+   - Source checking is required when new versions of frameworks, routing, rendering modes, caches, build tools, browser APIs, package publishing formats, authentication protocols, or public interfaces are involved.
+   - When it comes to project commitments, read the README, configuration, templates, existing implementations, testing and migration records of this warehouse first.
+   - Use the project's existing schema as a source of truth when simply stabilizing the language syntax or significantly partial refactoring.
+
+2. Collect authoritative materials
+   - Preferred official documentation, specifications, source code, release notes, migration guide, type definitions and in-project testing.
+   - Third-party articles can only be used as clues and cannot be used as the final basis.
+   - Record package name, version, document date or page title for rapidly changing libraries.
+   - When a user asks to answer a question from a local knowledge base, project repository or `knowledge/` directory, perform local knowledge retrieval first and do not use network search to fill in the facts.
+
+3. Refine decisions
+   - Write down recommended practices, deprecated practices, limitations and migration considerations for the current version.
+   - Explain the reasons for selection, compatibility, maintenance costs and fallback methods for multiple feasible options.
+   - If there is a conflict between the document and the current status of the project, priority will be given to explaining the conflict and making incremental adjustments instead of directly overturning the running system.
+   - Record release notes, migration guide, version scope, breaking changes and rollback plans for dependency upgrades, framework migrations and public API changes.
+
+4. Fall to implementation
+- Isolate external behavior in the adaptation layer, configuration layer or small utility functions to avoid spreading version assumptions throughout the component.
+   - Public interface changes should keep naming, error shapes, default values, and compatibility policies clear.
+   - Code comments only record non-obvious source constraints and do not paste large sections of documentation.
+
+5. Test your hypothesis
+   - Prove key assumptions with type checking, minimal reproduction, unit testing, component testing, E2E, build or browser validation.
+   - If verification is not possible, report uncertainty, risk range, and information that requires confirmation by the user or team.
+6. Leave a lightweight record of decisions
+   - Supplement ADR/change records or hand off to the document sync process when conclusions impact public interfaces, dependency versions, catalog specifications or team workflows.
 
 ## Local Knowledge Retrieval
 
-当用户指定本地知识库路径，或默认 `knowledge/` 目录存在时，可用本流程回答资料库问题、抽取证据或辅助决策。
+When the user specifies the local knowledge base path, or the default `knowledge/` directory exists, this process can be used to answer database questions, extract evidence, or assist decision-making.
 
-1. 定位根目录
-   - 用户明确指定路径时使用该路径。
-   - 否则检查当前项目下 `knowledge/` 是否存在；不存在时说明未找到默认知识库并请求路径。
-   - 不用文件 glob 判断目录是否存在。
+1. Locate the root directory
+   - Use this path when the user explicitly specifies the path.
+   - Otherwise, check whether `knowledge/` under the current project exists; if it does not exist, it means that the default knowledge base is not found and the path is requested.
+   - No need to use file glob to determine whether the directory exists.
 
-2. 分层导航
-   - 优先读取根目录和子目录中的 `data_structure.md`。
-   - 根据目录说明选择最相关的少量分支，不一次性遍历整个知识库。
-   - 记录候选文件、主题、时间/版本范围和为什么相关。
+2. Hierarchical navigation
+   - Read `data_structure.md` in the root directory and subdirectories first.
+   - Select the most relevant few branches according to the directory description, without traversing the entire knowledge base at once.
+   - Document candidate files, topics, time/version range and why they are relevant.
 
-3. 渐进检索
-   - Markdown、文本、日志：先用关键词搜索，再局部读取命中上下文。
-   - PDF：处理前先确认可用工具和提取路线，优先提取到临时文本后再检索，避免把整份 PDF 打进上下文。
-   - Excel：处理前先确认读取/分析路线，先看工作表、列名和少量样例，再按字段过滤或聚合。
-   - 默认最多 5 轮关键词迭代；每轮根据已找到证据调整同义词、缩写和范围。
+3. Progressive search
+   - Markdown, text, log: first search with keywords, and then partially read the hit context.
+   - PDF: Confirm the available tools and extraction routes before processing, and prioritize extraction of temporary text before retrieval to avoid putting the entire PDF into context.
+   - Excel: Confirm the read/analysis route before processing, first look at the worksheet, column names and a few samples, and then filter or aggregate by field.
+   - Default to up to 5 rounds of keyword iteration; each round adjusts synonyms, abbreviations, and scope based on found evidence.
 
-4. 回答与溯源
-   - 先给结论，再列文件路径、章节、页码、工作表或行号附近作为依据。
-   - 证据不足时说明查过哪些路径、缺什么信息，以及用户如何缩小范围。
-   - 不把知识库外的网络信息混入答案，除非用户另行要求查外部来源。
+4. Answer and traceability
+   - Give the conclusion first, and then list the file path, chapter, page number, worksheet or line number as a basis.
+   - If there is insufficient evidence, explain which paths have been checked, what information is missing, and how the user can narrow down the scope.
+   - Do not mix online information from outside the knowledge base into answers unless the user requests otherwise to check external sources.
 
 ## Source Priority
 
 | Priority | Source | Use |
 | -------- | ------ | --- |
-| 1 | 项目内配置、测试、已有实现 | 判断本仓库真实约定 |
-| 2 | 官方文档、源码、类型定义 | 判断当前推荐行为 |
-| 3 | 标准规范、浏览器兼容数据 | 判断平台能力和兼容边界 |
-| 4 | Issue、讨论、第三方文章 | 辅助排查，不能单独定案 |
+| 1 | Configuration, testing, and implementation within the project | Determine the true agreement of this warehouse |
+| 2 | Official documents, source code, type definitions | Determine current recommended behavior |
+| 3 | Standard specifications, browser compatibility data | Determine platform capabilities and compatibility boundaries |
+| 4 | Issues, discussions, third-party articles | Auxiliary investigation, cannot be finalized alone |
 
 ## Constraints
 
-- 不凭记忆给版本敏感结论。
-- 不把过时教程当作当前最佳实践。
-- 不引用无法复核的来源作为关键依据。
-- 不为追新而改动稳定项目约定；必须说明收益和迁移成本。
-- 不在交付中复制长篇外部文档；只保留必要结论和链接或文件路径。
-- 不把“查过文档”停留在口头；版本敏感决策需要能追溯到具体版本、路径或官方页面。
+- Don't give version-sensitive conclusions from memory.
+- Do not treat outdated tutorials as current best practices.
+- Do not cite sources that cannot be reviewed as critical evidence.
+- Do not change the stable project agreement to pursue new developments; the benefits and migration costs must be explained.
+- Do not copy long external documents in the delivery; keep only necessary conclusions and links or file paths.
+- Don't just say "checked the documentation"; version-sensitive decisions need to be traceable to a specific version, path or official page.
 
 ## Expected Output
 
-输出来源清单、版本或项目事实、决策结论、实现影响、验证命令和未决风险。若修改代码，关键行为应有测试或构建验证支撑。
+Output source lists, version or project facts, decision conclusions, implementation impacts, validation orders, and open risks. If code is modified, key behaviors should be supported by tests or build verification.