@bovinphang/frontend-craft 2.7.0 → 2.9.0

package/skills/fec-debug-framework/SKILL.md

@@ -1,157 +1,157 @@
 ---
 name: fec-debug-framework
-description: Use when diagnosing frontend build failures, runtime errors, UI anomalies, API/data problems, white screens, request failures, or unexplained production exceptions; Chinese triggers include 调试, debug, 排查, 定位, 报错, 异常, 白屏, 请求失败.
+description: Use when diagnosing frontend build failures, runtime errors, UI anomalies, API/data problems, white screens, request failures, or unexplained production exceptions; Chinese triggers include debugging, debug, troubleshooting, positioning, error reporting, exceptions, white screens, request failures.
 ---
 
-# 前端诊断框架
+# Front-end diagnostic framework
 
 ## Purpose
 
-用证据驱动的分类、收集、假设、验证和修复流程定位前端故障，避免凭直觉扩大改动范围。
+Use an evidence-driven triage, collection, hypothesis, verification, and remediation process to locate front-end faults and avoid relying on intuition to expand the scope of changes.
 
 ## Procedure
 
-所有前端问题诊断遵循统一流程：
+All front-end problem diagnosis follows a unified process:
 
-### Step 1: 分类（Classify）
+### Step 1: Classify
 
-识别问题类型和影响范围：
+Identify problem type and scope of impact:
 
-| 类型    | 判断依据                     | 诊断入口       |
+| Type | Judgment basis | Diagnosis entrance |
 | ------- | ---------------------------- | -------------- |
-| build   | 命令退出非零、stderr 有错误  | → Build 模块   |
-| runtime | 控制台异常、白屏、功能不可用 | → Runtime 模块 |
-| ui      | 视觉偏差、交互不符预期       | → UI 模块      |
-| api     | 请求状态码异常、数据不一致   | → API 模块     |
+| build | Command exit is non-zero, stderr has error | → Build module |
+| runtime | Console exception, white screen, function unavailable | → Runtime module |
+| ui | Visual deviation, interaction not as expected | → UI module |
+| api | Request status code exception, data inconsistency | → API module |
 
-跨类型问题（如 API 失败导致 UI 异常）从最表层症状入手，逐层深入。
+Cross-type problems (such as API failure leading to UI exceptions) start with the most superficial symptoms and drill down layer by layer.
 
-### Step 2: 收集（Collect）
+### Step 2: Collect
 
-按类型收集证据（各模块有具体策略，见下方）。
+Collect evidence by type (specific strategies for each module, see below).
 
-### Step 3: 假设（Hypothesize）
+### Step 3: Hypothesize
 
-基于证据提出可能根因，按可能性排序：
+Propose possible root causes based on evidence, ranked by likelihood:
 
-- 每个假设必须可测试（有明确的验证方法）
-- 最多保留 3 个假设，避免发散
-- 格式：「因为 X，导致 Y，可通过 Z 验证」
+- Every hypothesis must be testable (have clear verification methods)
+- Keep at most 3 hypotheses to avoid divergence
+- Format: "Because X leads to Y, which can be verified by Z"
 
-### Step 4: 验证（Verify）
+### Step 4: Verify
 
-逐一测试假设：
+Test the hypotheses one by one:
 
-- 从最可能的假设开始
-- 每次只改一个变量
-- 验证结果记录：证实 / 证伪 / 待定
-- 假设全部证伪时回到 Step 2 重新收集
+- Start with the most likely hypothesis
+- Only change one variable at a time
+- Verification result record: confirmed / falsified / pending
+- If all assumptions are falsified, return to Step 2 and collect again.
 
-### Step 5: 修复与确认（Fix & Validate）
+### Step 5: Fix & Validate
 
-- 应用最小修复
-- 运行受影响验证命令
-- 确认无回归
-- 输出修复报告
+- Apply minimal fixes
+- Run affected verification commands
+- Confirmed no regression
+- Output repair report
 
 ---
 
-## 诊断模块
+## Diagnostic module
 
-### Build 模块
+### Build module
 
-**收集**：运行最小失败命令，捕获完整 stderr/stdout
-**假设**：按错误类型分组（类型错误、导入失败、配置解析、依赖缺失），匹配已知模式
-**验证**：修一类根因 → 重跑命令 → 确认错误减少
-**特殊处理**：
+**Collect**: Run minimal failing commands, capture full stderr/stdout
+**Assumptions**: Grouped by error type (type error, import failure, configuration resolution, missing dependency), match known patterns
+**Verification**: Fix a type of root cause → rerun the command → confirm that errors are reduced
+**Special handling**:
 
-- 依赖版本、peer dependency、ESM/CJS、lockfile 相关失败先作为 build 兼容性问题收集证据
-- 记录 package manager、Node 版本、lockfile diff、相关包版本和完整错误日志
-- 不在缺少证据时升级依赖、手工编辑 lockfile，或把依赖迁移与普通调试修复混在同一批改动
-- 若任务目标本身是版本升级、CVE 修复或 lockfile 风险评审，应转入依赖升级工作流
-- CI 专属失败检查 Node 版本、包管理器、环境变量差异
+- Collect evidence for dependency version, peer dependency, ESM/CJS, and lockfile related failures first as build compatibility issues
+- Log package manager, Node version, lockfile diff, related package version and full error log
+- No longer upgrade dependencies, manually edit lockfiles when evidence is lacking, or mix dependency migrations with normal debug fixes in the same batch of changes
+- If the task goal itself is version upgrade, CVE repair or lockfile risk review, it should be transferred to the dependency upgrade workflow
+- CI exclusive failure check Node version, package manager, environment variable differences
 
-### Runtime 模块
+### Runtime module
 
-**收集**：
+**Collect**:
 
-- 复现路径（用户操作序列）
-- 控制台错误和堆栈
-- 组件渲染树状态（检查关键组件是否正确挂载）
-- 相关 store/state 快照
+- Recurrence path (sequence of user operations)
+- Console errors and stack
+- Component rendering tree status (check whether key components are mounted correctly)
+- Relevant store/state snapshot
 
-**假设**：
+**Assumptions**:
 
-- 堆栈反向追踪：从异常位置回溯到触发源
-- 状态流分析：检查 state 变化是否符合预期
-- 生命周期分析：是否在错误的时机访问了未初始化的数据
+- Stack reverse tracing: trace back from the exception location to the trigger source
+- State flow analysis: Check whether state changes are as expected
+- Life cycle analysis: whether uninitialized data is accessed at the wrong time
 
-**验证**：
+**Verification**:
 
-- 添加临时日志确认状态值
-- 在可疑路径添加断言
-- 复现路径验证修复
+- Add temporary log confirmation status value
+- Add assertions on suspicious paths
+- Recurrence path verification fix
 
-### UI 模块
+### UI module
 
-**收集**：
+**Collect**:
 
-- 当前截图 vs 期望效果
-- DOM 结构检查（元素是否存在、层级是否正确）
-- 计算样式检查（实际应用的 CSS 值）
-- 响应式断点测试
+- Current screenshot vs desired effect
+- DOM structure check (whether the element exists and whether the level is correct)
+- Computed style checks (actual applied CSS values)
+- Responsive breakpoint testing
 
-**假设**：
+**Assumptions**:
 
-- CSS 特异性冲突（选择器权重不够被覆盖）
-- 组件状态不匹配（props/state 未正确传递）
-- 布局模型问题（flex/grid 配置错误）
-- 响应式断点遗漏
+- CSS specificity conflict (selector weight is not enough to be overridden)
+- Component state mismatch (props/state not passed correctly)
+- Layout model problem (flex/grid configuration error)
+- Missing responsive breakpoints
 
-**验证**：
+**Verification**:
 
-- 浏览器 DevTools 实时调整验证
-- 隔离组件测试（排除外部样式干扰）
-- 多断点逐一验证
+- Browser DevTools real-time adjustment verification
+- Isolated component testing (excluding external style interference)
+- Multiple breakpoints to verify one by one
 
-### API 模块
+### API module
 
-**收集**：
+**Collect**:
 
-- 请求 URL、method、headers、body
-- 响应 status、headers、body
-- 网络瀑布时序
-- 相关 store/state 中的缓存数据
+- Request URL, method, headers, body
+- Respond to status, headers, body
+- Network waterfall timing
+- Cache data in related store/state
 
-**假设**：
+**Assumptions**:
 
-- 请求链路逐跳检查（URL → 中间件 → 拦截器 → 服务端）
-- 数据转换检查（响应解析、类型映射）
-- 缓存策略检查（过期、失效、竞态）
-- 并发请求竞态（race condition）
+- Request link hop-by-hop inspection (URL → Middleware → Interceptor → Server)
+- Data conversion checks (response parsing, type mapping)
+- Cache policy check (expiration, invalidation, race condition)
+- Concurrent request race condition (race condition)
 
-**验证**：
+**Verification**:
 
-- curl 独立复现（排除前端干扰）
-- 逐层 mock 定位问题层级
-- 端到端请求验证修复
+- curl independent reproduction (excluding front-end interference)
+- Mock layer by layer to locate the problem level
+- End-to-end request validation fixes
 
 ---
 
-## 详细参考
+## Detailed reference
 
-撰写诊断报告时，加载 [references/report-template.md](references/report-template.md)。
+When writing a diagnostic report, load [references/report-template.md](references/report-template.md).
 
 ## Constraints
 
-- 不在缺少证据时猜测根因
-- 不通过关闭规则、删除测试或降低类型安全来「修复」
-- 每次只改一个变量来验证假设
-- 不在验证前扩大改动范围
-- 同一假设连续 3 次验证失败，停止并报告阻塞
+- Don't guess at root cause when evidence is lacking
+- Not "fixed" by turning off rules, removing tests, or reducing type safety
+- Change only one variable at a time to test your hypothesis
+- Do not expand the scope of changes before verification
+- The same hypothesis fails verification 3 times in a row, stops and reports blocking
 
 ## Expected Output
 
-- 诊断报告保存为 `reports/debug-YYYY-MM-DD-HHmmss.md`
-- 报告包含问题类型、关键证据、假设验证记录、根因、修复内容、验证结果和剩余风险
-- build/runtime/ui/api 问题均能说明复现路径、验证命令或下一步阻塞点
+- The diagnostic report is saved as `reports/debug-YYYY-MM-DD-HHmmss.md`
+- The report includes issue type, key evidence, hypothesis verification records, root cause, fix content, verification results and remaining risk
+- Build/runtime/ui/api problems can explain the reproduction path, verification command or next blocking point

package/skills/fec-debug-framework/references/report-template.md

@@ -1,58 +1,58 @@
-# 诊断报告模板
+# Diagnostic report template
 
 ```markdown
-# 前端诊断报告
+# Front-end diagnostic report
 
-> 生成时间: YYYY-MM-DD HH:mm
-> 问题类型: build / runtime / ui / api
-> 影响范围: 页面、功能、用户群或环境
+> Generation time: YYYY-MM-DD HH:mm
+> Question type: build/runtime/ui/api
+> Scope of influence: page, feature, user group or environment
 
-## 问题描述
+## Problem description
 
-- 用户报告或观察到的现象
-- 首次出现时间、环境、分支或版本
+- Phenomenon reported or observed by users
+- First appearance time, environment, branch or version
 
-## 复现路径
+## Reproduction path
 
-1. 操作步骤或触发命令
-2. 期望结果
-3. 实际结果
+1. Operation steps or trigger commands
+2. Desired results
+3. Actual results
 
-## 收集的证据
+## Evidence collected
 
-- 日志 / stderr / console stack
-- 截图、DOM、样式、网络请求或 trace
-- 相关配置、依赖版本、环境变量或状态快照
+- log/stderr/console stack
+- Screenshot, DOM, style, network request or trace
+- Related configurations, dependency versions, environment variables or status snapshots
 
-## 假设与验证
+## Hypothesis and Verification
 
-| 假设 | 验证方法 | 结果 |
+| Hypothesis | Verification Method | Results |
 | --- | --- | --- |
-| 因为 X，导致 Y | 通过 Z 验证 | 证实 / 证伪 / 待定 |
+| Because X, causes Y | Verified by Z | Confirmed / Falsified / Pending |
 
-## 根因
+## Root cause
 
-- 最终确认的根本原因
-- 为什么已有证据能支持该结论
+- Final confirmed root cause
+- Why the existing evidence supports this conclusion
 
-## 修复内容
+## Fix content
 
-- 修改的文件和行为
-- 为什么这是最小有效修复
+- Modified files and behavior
+- Why this is a minimal effective fix
 
-## 验证结果
+## Verification results
 
-- 执行的命令、手工路径或浏览器验证
-- 修复后观察到的结果
+- Executed command, manual path or browser verification
+- Observed results after fix
 
-## 剩余风险
+## Residual risk
 
-- 未覆盖的边界
-- 可能回归的区域
+- Uncovered borders
+- Areas of possible return
 
-## 下一步
+## Next step
 
-- 需要用户决策、后续任务或监控项
+- Requires user decisions, follow-up tasks or monitoring items
 ```
 
-诊断完成后，将报告保存到 `reports/debug-YYYY-MM-DD-HHmmss.md`，并告知用户报告路径。
+After the diagnosis is completed, save the report to `reports/debug-YYYY-MM-DD-HHmmss.md` and inform the user of the report path.

package/skills/fec-dependency-upgrade/SKILL.md

@@ -1,34 +1,34 @@
 ---
 name: fec-dependency-upgrade
-description: Use when planning, implementing, or reviewing frontend dependency upgrades, package migrations, lockfile changes, major framework version bumps, CVE remediation, peer dependency conflicts, ESM/CJS shifts, build-tool compatibility, or CI verification matrices; Chinese triggers include 依赖升级, 版本升级, lockfile, peer dependency, CVE 修复, 大版本迁移.
+description: Use when planning, implementing, or reviewing frontend dependency upgrades, package migrations, lockfile changes, major framework version bumps, CVE remediation, peer dependency conflicts, ESM/CJS shifts, build-tool compatibility, or CI verification matrices; Chinese triggers include dependency upgrades, version upgrades, lockfile, peer dependency, CVE fixes, major version migrations.
 ---
 
-# 依赖升级
+# Dependency upgrade
 
-适用于前端依赖升级、漏洞修复、大版本迁移和 lockfile 风险评审。需要具体流程和检查清单时加载 [references/dependency-upgrade-workflow.md](references/dependency-upgrade-workflow.md)。
+Suitable for front-end dependency upgrades, bug fixes, major version migrations and lockfile risk reviews. Load [references/dependency-upgrade-workflow.md](references/dependency-upgrade-workflow.md) when you need specific processes and checklists.
 
 ## Purpose
 
-用来源驱动和小批验证的方式升级依赖，降低破坏性变更、供应链风险和 CI 回归。
+Reduce disruptive changes, supply chain risks, and CI regressions by upgrading dependencies in a provenance-driven and small-batch verification manner.
 
 ## Procedure
 
-1. 建立事实基线：读取 package manager、lockfile、Node 版本、workspace 范围、CI 命令和当前验证状态。
-2. 分类升级目标：安全修复、补丁升级、小版本升级、大版本迁移、框架迁移、构建工具迁移或依赖清理。
-3. 查证来源：对版本敏感的库读取官方 release notes、migration guide、peer dependency、Node/browser 支持和弃用项。
-4. 拆小批次：安全补丁可集中处理；大版本、构建工具、框架和测试工具必须单独批次验证。
-5. 处理兼容边界：检查 ESM/CJS、TypeScript 类型、CSS 处理、SSR/RSC、插件 API、peer dependency 和 polyfill 变化。
-6. 运行验证矩阵：至少覆盖 install、typecheck、unit/component tests、build；关键应用补 E2E、Storybook 或手工冒烟。
-7. 同步文档：记录升级原因、版本、破坏性变更、迁移命令、回滚方式和仍需人工验证的路径。
+1. Establish a baseline of truth: Read package manager, lockfile, Node version, workspace scope, CI commands, and current verification status.
+2. Classified upgrade goals: security fixes, patch upgrades, minor version upgrades, major version migrations, framework migrations, build tool migrations, or dependency cleanup.
+3. Verify sources: For version-sensitive libraries, read official release notes, migration guide, peer dependency, Node/browser support and deprecation items.
+4. Split into smaller batches: Security patches can be processed centrally; large versions, build tools, frameworks and testing tools must be verified in separate batches.
+5. Address compatibility boundaries: Check for ESM/CJS, TypeScript types, CSS handling, SSR/RSC, plugin APIs, peer dependencies, and polyfill changes.
+6. Run the verification matrix: at least cover install, typecheck, unit/component tests, and build; for key applications, add E2E, Storybook, or manual smoke.
+7. Synchronization documentation: Record upgrade reasons, versions, destructive changes, migration commands, rollback methods, and paths that still require manual verification.
 
 ## Constraints
 
-- 不在缺少来源和验证的情况下进行大版本连跳。
-- 不为了消除 audit 警告盲目升级运行时关键包；先判断可利用路径和修复影响。
-- 不手工编辑 lockfile 规避依赖冲突。
-- 不把依赖升级和无关重构混在一个批次。
-- 不移除 peer dependency 或构建插件，除非有证据证明没有被运行时、子包或 CI 使用。
+- No more big version jumps without source and verification.
+- Do not blindly upgrade critical runtime packages to eliminate audit warnings; first determine the exploitable paths and repair the impact.
+- Avoid manual editing of lockfile to avoid dependency conflicts.
+- Do not mix dependency upgrades and unrelated refactorings in one batch.
+- Do not remove peer dependencies or build plugins unless proven not to be used by runtimes, subpackages or CIs.
 
 ## Expected Output
 
-输出升级清单、风险分类、来源依据、批次策略、修改范围、验证命令、失败处理和回滚建议。完成后 lockfile 与 package 清单一致，关键验证通过，破坏性变更有记录。
+Output upgrade list, risk classification, source basis, batch strategy, modification scope, verification command, failure handling and rollback suggestions. After completion, the lockfile is consistent with the package manifest, key verification is passed, and destructive changes are recorded.

package/skills/fec-dependency-upgrade/references/dependency-upgrade-workflow.md

@@ -1,48 +1,48 @@
-# 依赖升级工作流
+# Dependency upgrade workflow
 
-## 升级类型
+##Upgrade type
 
-| 类型 | 示例 | 验证 |
+| Type | Example | Validation |
 | ---- | ---- | ---- |
-| 安全补丁 | 传递依赖 CVE、patch 版本 | 安装、audit、目标测试 |
-| 小版本升级 | 兼容性功能版本 | typecheck、测试、构建 |
-| 大版本迁移 | React/Vue/Next/Vite/Storybook 大版本 | 迁移指南、完整验证矩阵 |
-| 工具链切换 | ESLint、TypeScript、bundler、test runner | 配置 diff、CI 对齐、样例失败 |
-| 清理 | 移除未使用包 | 引用搜索、构建、测试 |
+| Security patches | Transitive dependencies CVE, patch version | Installation, audit, target testing |
+| Minor version upgrade | Compatibility feature version | typecheck, test, build |
+| Large version migration | React/Vue/Next/Vite/Storybook large version | Migration guide, complete verification matrix |
+| Tool chain switching | ESLint, TypeScript, bundler, test runner | Configuration diff, CI alignment, sample failure |
+| Cleanup | Remove unused packages | Reference search, build, test |
 
-## 来源检查清单
+## Source Checklist
 
-- 官方 release notes 或 migration guide。
-- 包管理器兼容性和 lockfile 格式。
-- Node 版本和浏览器支持范围。
-- Peer dependency 版本范围。
-- ESM/CJS 导出变化。
-- TypeScript 最低版本和类型变化。
-- SSR、RSC、edge runtime 或 browser-only 约束。
+-Official release notes or migration guide.
+- Package manager compatibility and lockfile format.
+- Node version and browser support range.
+- Peer dependency version range.
+- ESM/CJS export changes.
+- TypeScript minimum version and type changes.
+- SSR, RSC, edge runtime or browser-only constraints.
 
-## 分批策略
+## Batch strategy
 
-- 框架大版本升级与样式、测试、lint 升级分开处理。
-- 当 peer 版本范围要求时，adapter 与宿主工具放在同一批升级。
-- Monorepo 中要验证受影响包，并至少验证一个消费这些包的应用。
-- 每个成功批次都记录通过的命令，必要时单独提交或单独报告。
+- Major version upgrades of the framework are handled separately from style, test, and lint upgrades.
+- When required by the peer version range, the adapter is upgraded in the same batch as the host tool.
+- Verify affected packages in Monorepo and at least one application consuming these packages.
+- Passed commands are logged for each successful batch and submitted or reported individually if necessary.
 
-## 失败分诊
+## Failed Triage
 
-1. 复现最小失败命令。
-2. 判断失败属于配置、类型表面、运行时行为还是 peer dependency。
-3. 优先采用官方迁移步骤，而不是本地临时 hack。
-4. 如果某个包阻塞当前批次，先 pin 住并记录原因；只有剩余批次仍然自洽时才继续。
+1. Reproduce the minimum failed command.
+2. Determine whether the failure belongs to configuration, type surface, runtime behavior, or peer dependency.
+3. Prioritize official migration steps over local temporary hacks.
+4. If a packet blocks the current batch, pin it first and record the reason; continue only when the remaining batches are still self-consistent.
 
-## 报告模板
+## Report template
 
 ```markdown
-## 依赖升级摘要
+## Dependency upgrade summary
 
-| 包 | 从 | 到 | 原因 | 风险 | 依据 |
+| package | from | to | reason | risk | basis |
 | -- | -- | -- | ---- | ---- | ---- |
 
-## 验证
+## Verify
 
 - install:
 - typecheck:
@@ -50,7 +50,7 @@
 - build:
 - e2e/storybook/manual:
 
-## 剩余风险
+## Residual risk
 
 - ...
 ```

package/skills/fec-doc-sync/SKILL.md

@@ -1,39 +1,39 @@
 ---
 name: fec-doc-sync
-description: Use when synchronizing frontend project documentation with source-of-truth files such as package.json, lockfiles, config, env examples, routes, API clients or server routes, schemas, components, tests, CI, build/deploy config, ADRs, changelogs, or migration notes. Do not use for general prose polishing only; Chinese triggers include 文档同步, 更新 README, docs sync, 环境变量文档, 命令清单, API 文档同步.
+description: Use when synchronizing frontend project documentation with source-of-truth files such as package.json, lockfiles, config, env examples, routes, API clients or server routes, schemas, components, tests, CI, build/deploy config, ADRs, changelogs, or migration notes. Do not use for general prose polishing only; Chinese triggers include document synchronization, update README, docs sync, environment variable documentation, command list, API Document synchronization.
 ---
 
-# 文档同步
+# Document synchronization
 
 ## Purpose
 
-从代码、配置、测试、类型、脚本和运行时模板同步前端项目文档，避免 README、docs、环境变量说明、API/路由说明、架构决策和迁移说明与实际项目行为漂移。
+Synchronize front-end project documentation from code, configuration, tests, types, scripts and runtime templates to avoid README, docs, environment variable descriptions, API/routing descriptions, architectural decisions and migration notes from drifting from actual project behavior.
 
 ## Procedure
 
-1. 识别项目栈、文档入口和本次需要同步的范围；README 同步必须扫描根目录 `README*`、`docs/*/README*`、包、应用、部署或运行时相关 README，并排除 `node_modules`、构建产物和第三方依赖目录。
-2. 收集事实来源：`package.json`、lockfile、框架和构建配置、`.env.example`、路由、API clients 或 server routes、types/schemas、组件、测试、CI、build/deploy config。
-3. 比对 README、docs、ADR、changelog、example prompts、setup/deploy/env docs 中的命令、环境变量、路由、API 行为、部署步骤和支持矩阵。
-4. 只更新稳定的公共约定；不要把临时调试结论、一次性报告或未落地设计写入长期文档。
-5. 若仓库已有多语言文档或国际化 README，主 README 的公共事实更新后必须检查其它语言 README 是否需要同步；功能名称、命令名、脚本名、包名、组件/API 名称、报告文件名、路径、环境变量、路由/API 名称、版本约束和支持矩阵必须跨语言一致。
-6. 产品文案可保持本地化表达，但不得保留旧事实、旧默认推荐或过期示例；无法高质量翻译时，至少同步关键事实，并在输出中标出人工翻译风险。
-7. 当项目暴露插件、SDK、CLI、组件库、模板或集成能力时，同步对应的功能清单、集成说明、命令/脚本说明、公开 metadata、示例提示词或示例用法。
-8. 运行相关文档一致性、旧口径搜索、报告格式一致性、类型检查、测试、构建或打包检查。
+1. Identify the project stack, document entry and the scope that needs to be synchronized this time; README synchronization must scan the root directory `README*`, `docs/*/README*`, package, application, deployment or runtime related README, and exclude `node_modules`, build products and third-party dependency directories.
+2. Gather sources of truth: `package.json`, lockfile, framework and build configurations, `.env.example`, routes, API clients or server routes, types/schemas, components, tests, CI, build/deploy config.
+3. Compare commands, environment variables, routes, API behaviors, deployment steps and support matrix in README, docs, ADR, changelog, example prompts, setup/deploy/env docs.
+4. Only update stable public conventions; do not write temporary debugging conclusions, one-time reports or unimplemented designs into long-term documents.
+5. If the warehouse already has multilingual documents or internationalized README, after updating the public facts of the main README, you must check whether other language READMEs need to be synchronized; function names, command names, script names, package names, component/API names, report file names, paths, environment variables, routing/API names, version constraints, and support matrices must be consistent across languages.
+6. Product copy can maintain localized expression, but must not retain old facts, old default recommendations, or expired examples; when high-quality translation is not possible, at least synchronize key facts, and mark the risks of manual translation in the output.
+7. When the project exposes plug-ins, SDKs, CLIs, component libraries, templates or integration capabilities, synchronize the corresponding function list, integration instructions, command/script instructions, public metadata, example prompt words or example usage.
+8. Run relevant documentation consistency, legacy searches, report format consistency, type checks, testing, build or packaging checks.
 
 ## Constraints
 
-- 不把 README 变成完整实现细节；公开文档保留高信号摘要。
-- 不引入与事实来源不一致的命令、路径、环境变量、API 行为或能力名称。
-- 不把未确认的 TODO、草案或实验能力写成已支持行为。
-- 不修改用户项目私有文档，除非用户明确指定。
-- 多语言文档若无法完整翻译，至少保持命令名、环境变量、路由/API 名称、版本约束和报告格式一致。
-- 不把国际化 README 同步简化成只改主 README；公共事实、功能清单、报告清单、命令/脚本说明和示例用法必须检查所有语言入口。
-- 不把 ADR 当作长篇复盘；只记录背景、决策、取舍、影响范围、验证和回滚线索。
+- Do not turn README into complete implementation details; public documentation retains high-signal summaries.
+- Do not introduce command, path, environment variable, API behavior, or capability names that are inconsistent with the source of truth.
+- Do not write unconfirmed TODOs, drafts, or experimental capabilities as supported behavior.
+- Do not modify user project private documents unless explicitly specified by the user.
+- If multi-language documents cannot be fully translated, at least keep the command names, environment variables, route/API names, version constraints and report formats consistent.
+- Do not reduce internationalized README synchronization to just the main README; public facts, feature lists, report lists, command/script descriptions, and example usage must check all language entries.
+- Do not treat ADR as a long review; only record the background, decisions, trade-offs, scope of impact, verification and rollback clues.
 
 ## Expected Output
 
-- 列出已同步的 README/docs/ADR/changelog/env/setup/deploy 文档。
-- 列出已检查的 README/docs 入口，并说明哪些语言文件已同步、哪些无需同步、哪些需要人工确认。
-- 总结使用的事实来源、更新范围、验证命令和未覆盖风险。
-- 汇总旧口径搜索、报告文件名/路径/命令一致性和多语言关键事实一致性验证结果。
-- 标出仍需人工确认的产品文案、翻译、外部服务配置或发布说明。
+- List synchronized README/docs/ADR/changelog/env/setup/deploy documents.
+- List the checked README/docs entries and indicate which language files have been synchronized, which do not need to be synchronized, and which require manual confirmation.
+- Summarize the sources of truth used, update scope, verification orders, and non-coverage risks.
+- Aggregate legacy caliber searches, report filename/path/command consistency and multilingual key fact consistency verification results.
+- Highlight product copy, translations, external service configurations, or release notes that still require manual confirmation.