@bovinphang/frontend-craft 2.7.0 → 2.9.0

package/commands/fec-review.md

@@ -1,66 +1,96 @@
 ---
 name: fec-review
-description: 对指定文件或最近变更的前端代码进行规范化评审，输出分级评审报告并保存为 Markdown 文件。
+description: Conduct a standardized review of the frontend changes, specified files/directories, or the whole project, output a graded review report and save it as a Markdown file.
 ---
 
-对前端代码进行全面评审。先读项目现状和 diff，再输出有证据的发现；不把猜测写成阻塞项。若需要**结合 git diff、按严重级别（CRITICAL→LOW）降噪输出、并显式给出 Approve/Warning/Block 结论**，可委托 **`fec-code-reviewer`** 子代理执行；若变更以 **`.ts` / `.tsx` / `.js` / `.jsx`** 为主且需先跑 **typecheck/eslint**、PR 合并就绪检查与 TS/JS 惯用法专项结论，可委托 **`typescript-reviewer`**（报告为 `typescript-review-*.md`）。否则继续按本命令与 `fec-code-review` Skill 流程即可。
+Conduct a comprehensive review of the front-end code. Read the project status and selected scope first (diffs only for change review), and then output the findings with evidence; do not write guesses as blocking items. If you need to **combine git diff, reduce noise output by severity level (CRITICAL→LOW), and explicitly give Approve/Warning/Block conclusions**, you can entrust the **`fec-code-reviewer`** subagent to execute; if the changes are mainly **`.ts` / `.tsx` / `.js` / `.jsx`** and you need to run **typecheck/eslint**, PR merge readiness check and Special conclusions on TS/JS idioms can be delegated to **`fec-typescript-reviewer`** (reported as `typescript-review-*.md`). Otherwise, continue to press this command and the `fec-code-review` Skill process.
 
-## 执行步骤
+## Review modes and coverage
 
-1. 确定评审范围：
+User-specified scope takes precedence over the default. Follow the three modes in `fec-code-review`:
 
-   - 如果用户指定了文件路径，评审指定文件
-   - 如果用户没有指定文件，运行 `git diff --name-only HEAD` 获取最近变更的文件列表
-   - 如果没有 git 变更记录，提示用户指定需要评审的文件或目录
+- **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.
 
-2. 过滤只保留前端相关文件（`.ts`, `.tsx`, `.vue`, `.js`, `.jsx`, `.css`, `.scss`, `.less`, `.html`）
+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.
 
-3. 使用 `fec-code-review` Skill 的评审维度逐项检查：
+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.
 
-   - 架构（组件边界、职责分离）
-   - 类型安全（any 使用、props 类型）
-   - 渲染与状态（重复渲染、key 稳定性）
-   - 样式（Token 使用、响应式）
-   - Tailwind / 设计系统（token、variant、暗色模式、动态 class）
-   - 可访问性（语义化、ARIA、键盘操作）
-   - 可维护性（文件体积、命名、重复逻辑）
-   - 测试（关键覆盖、测试模式）
-   - 安全（XSS、敏感信息、输入校验）
-   - 性能（首屏依赖、重复请求、长任务、大列表）
-   - 依赖升级（lockfile、peer dependency、CVE、大版本迁移验证）
+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.
 
-4. 按以下格式输出评审报告：
+## Execution steps
+
+1. Select one of the three modes above and inventory target files. Default to project review when no scope or change context is specified; an incremental request with no changes must not trigger scope expansion.
+
+2. Include frontend source, related tests, configuration and dependency declarations, rather than filtering only by source extensions; record default exclusions.
+
+3. Use the review dimensions of `fec-code-review` Skill to check item by item:
+
+   - Architecture (component boundaries, separation of responsibilities)
+   - Type safety (any usage, props type)
+   - Rendering and status (repeated rendering, key stability)
+   - Style (Token usage, responsiveness)
+   - Tailwind / design system (token, variant, dark mode, dynamic class)
+   - Accessibility (semantics, ARIA, keyboard operation)
+   - Maintainability (file size, naming, repetitive logic)
+   - Testing (critical coverage, test patterns)
+   - Security (XSS, sensitive information, input validation)
+   - Performance (first screen dependencies, repeated requests, long tasks, large lists)
+   - Dependency upgrade (lockfile, peer dependency, CVE, major version migration verification)
+
+   Each question must include file location, impact, confidence level, and recommended verification method.
+
+4. Output the review report in the following format:
 
    ```
-   # 代码审查报告
+   # Code review report
+
+   > Generation time: YYYY-MM-DD HH:mm
+   > Review tool: frontend-craft
 
-   > 生成时间: YYYY-MM-DD HH:mm
-   > 评审工具: frontend-craft
+   > 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
 
-   **评审范围**: N 个文件
+   **Review Scope**: N documents
 
-   ## 🔴 必须修改 (N项)
-   - **[文件:行号]** 问题描述 → 建议修改
+   ## 🔴 Must be modified (N items)
+   - **[File:line number]** Problem description → Suggested changes
 
-   ## 🟡 建议优化 (N项)
-   - **[文件:行号]** 问题描述 → 建议修改
+   ## 🟡 Suggested optimizations (N items)
+   - **[File:line number]** Problem description → Suggested modifications
 
-   ## 🔵 可选优化项 (N项)
-   - **[文件:行号]** 问题描述
+   ## 🔵 Optional optimization items (N items)
+   - **[File:line number]** Problem description
 
-   ## 🟢 做得好的地方
-   - ...
+   ## 🟢 Things done well
+   -...
 
-   ## 风险等级：低 / 中 / 高
+   ## Risk Level: Low / Medium / High
 
-   **总体评价**: 可合并 / 待修改后合并 / 需要重构
+   **Conclusion**: Change review: merge recommendation; targeted/project review: Low / Medium / High risk and blocking findings
    ```
 
-5. 将报告内容使用 Write 工具保存为 Markdown 文件：
-   - 目录：项目根目录下的 `reports/`（如不存在则创建）
-   - 文件名：`code-review-YYYY-MM-DD-HHmmss.md`（使用当前时间戳）
-   - 保存后告知用户报告文件路径
+5. Use the Write tool to save the report content as a Markdown file:
+   - Directory: `reports/` in the project root directory (create it if it does not exist)
+   - Filename: `code-review-YYYY-MM-DD-HHmmss.md` (use current timestamp)
+   - Inform the user of the report file path after saving
+
+6. If the user agrees to the modification, directly repair the items that can be automatically repaired in "Must Modify".
+
+## Usage examples
+
+- `/fec-review`: review the entire project by default.
+- `/fec-review review recent changes`: review only current changes.
+- `/fec-review review src/components/Button.tsx`: review the specified file, including unchanged code.
+- `/fec-review review src/features/`: review the specified directory.
+- `/fec-review review the entire project`: inventory and review project-owned frontend code by module.
 
-6. 如果用户同意修改，直接修复"必须修改"中可以自动修复的项目。
+These are natural-language instructions, not new CLI flags.

package/commands/fec-scaffold.md

@@ -1,50 +1,50 @@
 ---
 name: fec-scaffold
-description: 按项目规范创建 page、feature 或 component 的标准目录结构和样板文件。用法：/fec-scaffold <type> <Name>，如 /fec-scaffold page UserDetail
+description: "Create a standard directory structure and template files for pages, features, or components according to project specifications. Usage: /fec-scaffold <type> <Name>, such as /fec-scaffold page UserDetail"
 ---
 
-按项目约定的目录结构创建新的 page、feature 或 component。
+Create new pages, features or components according to the directory structure agreed upon by the project.
 
-## 依赖与版本
+## Dependencies and versions
 
-若本次脚手架涉及新增或建议 `package.json` 依赖，遵循项目 `.claude/rules/fec-react.md` 或 `.claude/rules/fec-vue.md` 中「版本与依赖」约定；项目中尚无对应规则时，优先采用彼此兼容的主流稳定版本（对齐官方文档、脚手架默认值或包管理器推荐）。
+If this scaffolding involves adding or recommending `package.json` dependencies, follow the "version and dependency" conventions in the project `.claude/rules/fec-react.md` or `.claude/rules/fec-vue.md`; if there is no corresponding rule in the project, priority will be given to mainstream stable versions that are compatible with each other (align with official documents, scaffolding default values or package manager recommendations).
 
-## 参数解析
+## Parameter analysis
 
-从 `$ARGUMENTS` 中解析两个参数：
-- **type**: `page` | `feature` | `component`（必填）
-- **name**: 模块名称，使用 PascalCase（必填）
+Parse two arguments from `$ARGUMENTS`:
+- **type**: `page` | `feature` | `component` (required)
+- **name**: module name, using PascalCase (required)
 
-如果参数缺失，提示用法示例并要求用户补充：
+If a parameter is missing, a usage example is prompted and the user is asked to add:
 ```
-用法：/fec-scaffold <type> <Name>
-示例：
+Usage: /fec-scaffold <type> <Name>
+Example:
   /fec-scaffold page UserDetail
   /fec-scaffold feature payment
   /fec-scaffold component DataTable
 ```
 
-## 执行步骤
+## Execution steps
 
-### 1. 检测项目框架
+### 1. Detection project framework
 
-检查 `package.json` 的 `dependencies`：
-- 包含 `react` → React 项目
-- 包含 `vue` → Vue 项目
-- 都不包含 → 提示用户手动指定
+Check `package.json` for `dependencies`:
+- Contains `react` → React project
+- Contains `vue` → Vue project
+- None → Prompt user to specify manually
 
-### 2. 探测项目约定并确定目标路径
+### 2. Detect project conventions and determine target paths
 
-检查 `src/`、`app/`、`pages/`、`features/`、`components/`、`__tests__/`、`tests/`、`vitest.config.*`、`jest.config.*`、`playwright.config.*` 和现有组件命名方式。优先复用项目已有目录；仅在没有现成约定时使用默认路径：
+Check `src/`, `app/`, `pages/`, `features/`, `components/`, `__tests__/`, `tests/`, `vitest.config.*`, `jest.config.*`, `playwright.config.*` and existing component naming. Give priority to reusing existing directories of the project; only use the default path when there is no existing agreement:
 - page → `src/pages/<Name>/`
-- feature → `src/features/<name>/`（name 转为 kebab-case）
+- feature → `src/features/<name>/` (name is converted to kebab-case)
 - component → `src/components/<Name>/`
 
-如果目标目录已存在，提示用户确认是否继续。
+If the target directory already exists, the user is prompted to confirm whether to continue.
 
-### 3. 创建目录和文件
+### 3. Create directories and files
 
-根据框架和类型，创建以下结构：
+Depending on the frame and type, create the following structures:
 
 #### React page
 
@@ -52,12 +52,12 @@ description: 按项目规范创建 page、feature 或 component 的标准目录
 src/pages/<Name>/
 ├── <Name>Page.tsx
 ├── components/
-│   └── .gitkeep
+│ └── .gitkeep
 └── hooks/
     └── .gitkeep
 ```
 
-`<Name>Page.tsx` 内容：
+`<Name>Page.tsx` Content:
 
 ```tsx
 export default function <Name>Page() {
@@ -74,29 +74,29 @@ export default function <Name>Page() {
 ```
 src/features/<name>/
 ├── components/
-│   └── .gitkeep
+│ └── .gitkeep
 ├── hooks/
-│   └── .gitkeep
+│ └── .gitkeep
 ├── api.ts
 ├── types.ts
 ├── constants.ts
 └── index.ts
 ```
 
-`index.ts` 内容：
+`index.ts` content:
 
 ```typescript
 export * from './types';
 export * from './constants';
 ```
 
-`api.ts` 内容（仅在项目已有 `src/services/request.*`、`src/lib/request.*`、`src/api/client.*` 或同类 API client 时导入对应 client；否则保持空导出，避免制造不存在的别名依赖）：
+`api.ts` content (only import the corresponding client when the project already has `src/services/request.*`, `src/lib/request.*`, `src/api/client.*` or a similar API client; otherwise, keep the empty export to avoid creating non-existent alias dependencies):
 
 ```typescript
 export {};
 ```
 
-`types.ts` 和 `constants.ts` 创建为空文件或最小空导出。
+`types.ts` and `constants.ts` are created as empty files or minimally empty exports.
 
 #### React component
 
@@ -108,7 +108,7 @@ src/components/<Name>/
     └── <Name>.spec.tsx
 ```
 
-`<Name>.tsx` 内容：
+`<Name>.tsx` Content:
 
 ```tsx
 import './<Name>.styles.css';
@@ -132,12 +132,12 @@ export function <Name>({ children }: <Name>Props) {
 src/pages/<Name>/
 ├── <Name>Page.vue
 ├── components/
-│   └── .gitkeep
+│ └── .gitkeep
 └── composables/
     └── .gitkeep
 ```
 
-`<Name>Page.vue` 内容：
+`<Name>Page.vue` Content:
 
 ```vue
 <script setup lang="ts">
@@ -158,16 +158,16 @@ src/pages/<Name>/
 ```
 src/features/<name>/
 ├── components/
-│   └── .gitkeep
+│ └── .gitkeep
 ├── composables/
-│   └── .gitkeep
+│ └── .gitkeep
 ├── api.ts
 ├── types.ts
 ├── constants.ts
 └── index.ts
 ```
 
-`index.ts` 内容与 React 相同。
+`index.ts` content is the same as React.
 
 #### Vue component
 
@@ -178,7 +178,7 @@ src/components/<Name>/
     └── <Name>.spec.ts
 ```
 
-`<Name>.vue` 内容：
+`<Name>.vue` Content:
 
 ```vue
 <script setup lang="ts">
@@ -198,8 +198,8 @@ const props = defineProps<Props>();
 </style>
 ```
 
-### 4. 输出确认
+### 4. Output confirmation
 
-创建完成后，输出：
-- 创建的文件清单
-- 下一步建议（如"在路由配置中注册新页面"、"在 index.ts 中导出公开 API"）
+After creation is completed, output:
+- List of files created
+- Next step suggestions (such as "Register new page in routing configuration", "Export public API in index.ts")

package/commands/fec-smell.md

@@ -0,0 +1,17 @@
+---
+name: fec-smell
+description: Diagnose frontend code smells with evidence and candidate refactorings without changing business code.
+---
+
+Use this command for **DIAGNOSE ONLY** analysis. Do not modify business code.
+
+## Workflow
+
+1. Discover the requested scope, project/framework facts, and current diff.
+2. Collect concrete evidence about ownership, duplication, change coupling, data flow, control flow, and public boundaries.
+3. Match evidence against the 24-smell catalog and run false-positive checks.
+4. For each finding report: `Location`, `Evidence`, `Impact`, `Smell`, `Confidence`, `Candidates`, `Priority`, and `False-positive check`.
+5. LOW-confidence findings remain open questions and must not become automatic edits.
+6. Save the result to `reports/refactoring/smell-YYYY-MM-DD-HHmmss.md`.
+
+Metrics such as LOC or complexity may focus investigation but are not sufficient proof by themselves.

package/commands/fec-tdd.md

@@ -1,21 +1,25 @@
 ---
 name: fec-tdd
-description: 使用前端 TDD 工作流实现功能、修复 Bug 或重构逻辑：先写失败测试，再实现最小代码，再重构。
+description: "Use front-end TDD workflow to implement functions, fix bugs, or refactor logic: first write failing tests, then implement minimal code, and then refactor."
 ---
 
-按 `fec-tdd-workflow` 执行测试驱动开发。
+Perform test-driven development as per `fec-tdd-workflow`.
 
-## 执行步骤
+## Execution steps
 
-1. 明确要验证的前端行为。
-2. 选择最近风险的测试层：单元、组件、轻量集成或 E2E。
-3. 写最小失败测试并运行，确认失败原因正确。
-4. 写最小实现让测试通过。
-5. 保持测试通过后再重构。
-6. 总结测试命令、覆盖行为和剩余风险。
+1. Identify the front-end behavior to be verified.
+2. Select the test layer for the nearest risk: Unit, Component, Lightweight Integration, or E2E.
+3. Write a minimum failure test and run it to confirm that the failure reason is correct.
+4. Write the minimum implementation to make the test pass.
+5. Keep the tests passed before refactoring.
+6. Summarize test orders, coverage actions, and remaining risks.
 
-## 分流
+## Diversion
 
-- 组件和 hook 测试：`fec-component-testing`
-- 跨页浏览器流程：`fec-e2e-testing`
-- 测试分层策略：`fec-testing-strategy`
+- Component and hook testing: `fec-component-testing`
+- Cross-page browser process: `fec-e2e-testing`
+- Test layering strategy: `fec-testing-strategy`
+
+## Boundary
+
+Use this command for new observable behavior and behavior-changing bug fixes. For pure behavior-preserving refactoring, do not invent a RED test: characterize the already-correct behavior and keep it GREEN → REFACTOR → GREEN.