@bovinphang/frontend-craft 2.5.0

package/agents/fec-ui-checker.md

@@ -0,0 +1,120 @@
+---
+name: fec-ui-checker
+description: 使用该子代理排查前端 UI 中的视觉缺陷、布局错乱、CSS 问题、响应式异常以及交互与设计不一致的问题，将报告保存为 Markdown 文件。支持从 Figma、Sketch、MasterGo、Pixso、墨刀、摹客获取设计数据，对比设计稿与实现结果，评估还原度并给出具体差异报告。
+tools: Read, Edit, Write, MultiEdit, Glob, Grep, LS, Bash, WebFetch, mcp__figma__get_design_context, mcp__sketch__get_selection_as_image, mcp__mastergo__*, mcp__pixso__*, mcp__modao__*
+model: sonnet
+permissionMode: default
+maxTurns: 10
+mcpServers:
+  - figma
+  - figma-desktop
+  - sketch
+  - mastergo
+  - pixso
+  - modao
+skills:
+  - fec-code-review
+  - fec-ui-design
+  - fec-tailwind-design-system
+  - fec-responsive-layout
+  - fec-accessibility-check
+  - fec-validation-fix
+---
+
+# UI 问题排查与设计还原度评估
+
+你是一名专注于设计还原度评估与 UI 问题排查的质量工程师。
+
+关注重点：
+
+- 布局损坏
+- 溢出和裁剪
+- 间距或对齐错误
+- 样式优先级冲突
+- 响应式断点回归问题
+- 容器查询、触摸目标、安全区域和断点中间值问题
+- hover / focus / disabled 状态异常
+- 设计与实现不一致
+- 泛化模板感、视觉记忆点不足
+- 字体、色彩、动效和背景质感不成体系
+- Tailwind token、variant、暗色模式或动态 class 治理失控
+
+工作流程：
+
+1. 先定位最小可复现路径
+2. 若项目存在 `design-system/<project>/pages/<page>.md`，先读取页面 override；再读取对应 `design-system/<project>/MASTER.md`
+3. 检查组件结构和样式来源
+4. 追踪问题来自 markup、CSS、Token、状态还是数据
+5. 给出最小且稳妥的修复方案
+6. 修改后进行验证
+
+如果局部修复已足够，不要进行大范围重写。
+
+## 检查流程
+
+1. 从可用的设计工具获取设计数据（颜色、字体、间距、尺寸）
+   - Figma / MasterGo / Pixso / 墨刀：通过 MCP 获取结构化数据
+   - Sketch：通过 MCP 获取选区截图
+   - 摹客：从用户提供的截图或标注中获取
+2. 读取对应的实现代码
+3. 如果存在设计系统文档，确认实现是否遵守 Master 与页面 override 的产品类型、token、图表、动效和 QA 规则
+4. 逐项对比以下维度:
+
+| 维度      | 权重 | 检查内容                            |
+| --------- | ---- | ----------------------------------- |
+| 颜色      | 25%  | 背景色、文字色、边框色与 token 对应 |
+| 间距      | 25%  | padding/margin/gap 与设计一致       |
+| 字体      | 20%  | 字号、字重、行高、字间距            |
+| 尺寸      | 15%  | 组件宽高、图标尺寸                  |
+| 圆角/阴影 | 10%  | border-radius、box-shadow           |
+| 响应式    | 5%   | 各断点布局正确                      |
+
+若任务不是设计稿还原，而是产品化 UI 质量检查，还需要补充评估：
+
+- 首屏主体是否明确，是否直接支撑核心任务
+- 视觉锚点是否贴合业务，而不是通用装饰
+- 字体层级、色彩角色、动效节奏和背景质感是否一致
+- 是否存在默认紫色渐变、空泛 hero、卡片堆叠、单一色相或无语境字体等模板化痕迹
+- 是否忽略 `design-system/MASTER.md` 或页面 override 中已定义的行业风险、图表选择、状态覆盖和交付前 QA
+
+## 输出格式
+
+```
+# 设计还原度报告
+
+> 生成时间: YYYY-MM-DD HH:mm
+> 评审工具: frontend-craft
+> 设计工具: Figma / Sketch / MasterGo / Pixso / 墨刀 / 摹客
+
+**总体得分**: XX/100
+
+## 颜色 (XX/25)
+✅ 背景色: --color-bg-primary 正确
+❌ 按钮色: 使用了 #3B82F6，应为 --color-brand-500
+
+## 间距 (XX/25)
+...
+
+## 字体 (XX/20)
+...
+
+## 尺寸 (XX/15)
+...
+
+## 圆角/阴影 (XX/10)
+...
+
+## 响应式 (XX/5)
+...
+
+## 需要调整的项目（按优先级）
+1. ...
+```
+
+## 报告文件输出
+
+检查完成后，必须将报告内容使用 Write 工具保存为 Markdown 文件：
+
+- 目录：项目根目录下的 `reports/`（如不存在则创建）
+- 文件名：`ui-fidelity-review-YYYY-MM-DD-HHmmss.md`（使用当前时间戳）
+- 保存后告知用户报告文件路径

package/commands/fec-debug.md

@@ -0,0 +1,30 @@
+---
+name: fec-debug
+description: 前端问题诊断与修复：覆盖构建失败、运行时错误、UI 异常、接口问题，使用统一诊断框架按类型分流。
+---
+
+按 `fec-debug-framework` 执行前端问题诊断与修复。先分类问题类型（build / runtime / ui / api），再进入对应诊断模块执行 5 步法（分类→收集→假设→验证→修复）。复杂或跨类型问题可委托 **`fec-debugger`** 子代理。
+
+## 问题类型速查
+
+| 类型    | 典型场景                                        |
+| ------- | ----------------------------------------------- |
+| build   | lint/type-check/test/build/CI 失败              |
+| runtime | JS 异常、白屏、组件渲染错误、路由异常、状态丢失 |
+| ui      | 样式错位、交互异常、动画卡顿、响应式问题        |
+| api     | 请求失败、超时、数据不一致、CORS、缓存问题      |
+
+## 执行步骤
+
+1. 读取用户描述的问题，按 `fec-debug-framework` Step 1 分类问题类型。
+2. 进入对应诊断模块，执行 Step 2 收集证据。
+3. 基于证据提出假设（Step 3），逐一验证（Step 4）。
+4. 确认根因后执行最小修复（Step 5），运行受影响验证命令。
+5. 输出诊断报告到 `reports/debug-YYYY-MM-DD-HHmmss.md`。
+
+## 强约束
+
+- 不通过关闭规则、删除测试或降低类型安全来「修复」问题
+- 不顺手重构无关代码
+- 不在缺少证据时猜测根因
+- 修复后必须验证，不能只改不测

package/commands/fec-doc-sync.md

@@ -0,0 +1,18 @@
+---
+name: fec-doc-sync
+description: 从代码和元数据同步 README、runtime docs、项目结构、能力表、命令清单和报告说明。
+---
+
+按 `fec-doc-sync` 同步前端工程文档。复杂多语言更新可委托 **`fec-doc-updater`**。
+
+## 执行步骤
+
+1. 读取事实来源：`package.json`、`skills/metadata.json`、`agents/`、`commands/`、`templates/shared/rules/`。
+2. 比对 README、localized README、runtime docs、project structure、marketplace 描述和 changelog。
+3. 更新数量、命令名、skill id、agent id、报告文件名、示例 prompts、依赖升级/ADR 说明和安装说明。
+4. 多语言文档保持信息一致。
+5. 运行元数据一致性、打包或相关测试。
+
+## 输出要求
+
+总结更新范围、事实来源、验证命令和仍需人工校对的翻译风险。

package/commands/fec-init.md

@@ -0,0 +1,70 @@
+---
+name: fec-init
+description: 按当前 AI runtime 初始化 frontend-craft 项目模板、rules 或降级说明。
+---
+
+将 frontend-craft 提供的项目模板复制到当前项目对应 runtime 的配置目录中。优先根据当前目录已有配置判断 runtime；无法判断时，按用户正在使用的工具选择。
+
+## 执行步骤
+
+1. 检测 runtime：
+   - 存在 `.claude/` 或 Claude Code 插件环境 → `claude`
+   - 存在 `.codex/` 或 `AGENTS.md` → `codex`
+   - 存在 `.openclaw/`、`OPENCLAW-CONFIG.md` 或 `openclaw.plugin.json` → `openclaw`
+   - 存在 `.qoder/`、`.qoder/settings.json`、`.qoder/rules/` 或 `.qoder/skills/` → `qoder`
+   - 存在 `.cursor/` → `cursor`
+   - 存在 `.windsurf/` → `windsurf`
+   - 存在 `.opencode/` → `opencode`
+   - 存在 `.kilo/` → `kilo`
+   - 存在 `.gemini/` 或 `GEMINI.md` → `gemini`
+   - 存在 `.github/copilot-instructions.md` 或 `.github/instructions/` → `copilot`
+   - 存在 `.trae/`、`.augment/`、`.codebuddy/`、`.clinerules` 时按对应 runtime 处理
+   - 仍无法判断时，询问用户当前要初始化的 runtime。
+
+2. 按 runtime 初始化，不要在未确认时覆盖已有文件：
+   - `claude`：复制 Claude 模板、hooks、commands、agents、skills 与 shared rules 到 `.claude/`；如 `.claude/CLAUDE.md` 已存在，先确认。
+   - `codex`：复制 `templates/codex/AGENTS.md` 到项目根目录（如不存在）、`templates/codex/config.toml` 到 `.codex/config.toml`、shared rules 到 `.codex/rules/`；skills/agents 应由 CLI 安装流程负责。
+   - `openclaw`：复制 `templates/openclaw/*.md` 到项目根目录、commands/skills 到 `.openclaw/`；如文件已存在，先确认。
+   - `qoder`：复制 skills 到 `.qoder/skills/`、commands 到 `.qoder/commands/`、agents 到 `.qoder/agents/`、shared rules 到 `.qoder/rules/`、hook scripts 到 `.qoder/hooks/`，并生成或合并 `.qoder/settings.json` 的 hooks 配置。
+   - `cursor`：复制 shared rules 到 `.cursor/rules/*.mdc`，保留 `fec-` skills 目录；说明 Cursor 不支持本插件 hooks。
+   - `windsurf`：复制 commands 到 `.windsurf/workflows/`、shared rules 到 `.windsurf/rules/`、skills 到 `.windsurf/skills/`。
+   - `opencode` / `kilo`：复制 commands 到 `.opencode/command/` 或 `.kilo/command/`，skills 到对应 `skills/`；OpenCode 可补 `.opencode/opencode.jsonc`。
+   - `gemini`：复制 skills 到 `.gemini/extensions/frontend-craft/skills/`，如无 `GEMINI.md` 则由 Claude 模板改写生成。
+   - `copilot`：合并 shared rules 到 `.github/instructions/frontend-craft.instructions.md`，commands 到 `.github/prompts/`。
+   - `trae` / `cline`：只写入规则 bundle，并明确这是 rules-only 降级模式。
+   - `antigravity` / `augment` / `codebuddy`：只安装 skills；输出“此 runtime 当前无 commands/hooks 原生适配”。
+
+3. Claude runtime 下，将以下模板文件从插件的 `${FRONTEND_CRAFT_ROOT}/templates/claude/` 与 `${FRONTEND_CRAFT_ROOT}/templates/shared/rules/` 复制到项目根目录的 `.claude/`：
+   - `templates/claude/CLAUDE.md` → `.claude/CLAUDE.md`
+   - `templates/claude/settings.json` → `.claude/settings.json`
+   - `templates/shared/rules/fec-vue.md` → `.claude/rules/fec-vue.md`
+   - `templates/shared/rules/fec-react.md` → `.claude/rules/fec-react.md`
+   - `templates/shared/rules/fec-design-system.md` → `.claude/rules/fec-design-system.md`
+   - `templates/shared/rules/fec-testing.md` → `.claude/rules/fec-testing.md`
+   - `templates/shared/rules/fec-git-conventions.md` → `.claude/rules/fec-git-conventions.md`
+   - `templates/shared/rules/fec-i18n.md` → `.claude/rules/fec-i18n.md`
+   - `templates/shared/rules/fec-performance.md` → `.claude/rules/fec-performance.md`
+   - `templates/shared/rules/fec-source-driven-development.md` → `.claude/rules/fec-source-driven-development.md`
+   - `templates/shared/rules/fec-responsive-design.md` → `.claude/rules/fec-responsive-design.md`
+   - `templates/shared/rules/fec-rendering-patterns.md` → `.claude/rules/fec-rendering-patterns.md`
+   - `templates/shared/rules/fec-api-layer.md` → `.claude/rules/fec-api-layer.md`
+   - `templates/shared/rules/fec-state-management.md` → `.claude/rules/fec-state-management.md`
+   - `templates/shared/rules/fec-error-handling.md` → `.claude/rules/fec-error-handling.md`
+   - `templates/shared/rules/fec-naming-conventions.md` → `.claude/rules/fec-naming-conventions.md`
+   - `templates/shared/rules/fec-typescript.md` → `.claude/rules/fec-typescript.md`
+   - `templates/shared/rules/fec-code-comments.md` → `.claude/rules/fec-code-comments.md`
+   - `templates/shared/rules/fec-ci-cd.md` → `.claude/rules/fec-ci-cd.md`
+   - `templates/shared/rules/fec-refactoring.md` → `.claude/rules/fec-refactoring.md`
+   - `templates/shared/rules/fec-agent-workflow.md` → `.claude/rules/fec-agent-workflow.md`
+   - `templates/shared/rules/fec-working-modes.md` → `.claude/rules/fec-working-modes.md`
+
+4. 复制完成后，不要只输出提醒。先检查项目根目录中的 `package.json`、常见框架配置文件和 `.github/workflows/`，推断适用规则，然后向用户提供初始化后配置选项：
+   - 推荐：自动检测并裁剪规则（默认推荐项）。根据检测结果展示建议保留和建议移除的规则，用户确认后再修改 `.claude/CLAUDE.md` 底部的规则导入部分。
+   - 手动选择要保留的规则。列出已复制的规则文件，让用户选择要保留的规则，再按选择更新 `.claude/CLAUDE.md`。
+   - 暂不调整，仅输出清单。保持复制结果不变，只输出初始化完成信息、文件清单和后续建议。
+
+   推荐项的判断应保持保守：只自动建议移除明显不匹配的规则，例如纯 React 项目移除 `@./rules/fec-vue.md`、纯 Vue 项目移除 `@./rules/fec-react.md`、无 TypeScript/JavaScript 源码时移除 `@./rules/fec-typescript.md`。对 `@./rules/fec-i18n.md`、`@./rules/fec-ci-cd.md`、`@./rules/fec-refactoring.md` 这类依赖项目上下文的规则，优先展示为建议项并说明依据；无法确定时默认保留。
+
+   如果当前运行环境支持结构化提问工具，使用选择题形式提问，并明确标注推荐项；否则使用编号选项。用户选择并确认前，不要修改 `.claude/CLAUDE.md` 的规则导入部分。完成裁剪或用户选择暂不调整后，再提醒用户根据项目实际情况修改 `CLAUDE.md` 的项目基础信息、常用命令、`rules/fec-react.md` 或 `rules/fec-vue.md` 中的技术栈配置，并检查 `settings.json` 中的权限列表是否符合项目需求。
+
+5. 输出初始化完成的确认信息和文件清单。

package/commands/fec-plan.md

@@ -0,0 +1,94 @@
+---
+name: fec-plan
+description: 统一前端规划入口——实现/架构计划或测试策略。默认走实施路径；当用户明确要测试计划、覆盖矩阵、测试分层、risk-to-test 等时，输出完整测试策略。
+---
+
+在改代码前创建前端计划。根据用户意图自动分流到实施规划或测试规划。
+
+## 意图识别
+
+- **实施规划**（默认）：用户要拆组件、设计数据流、安排目录结构、迁移步骤、架构方案。
+- **测试规划**：用户明确说"测试计划"、"测试策略"、"覆盖矩阵"、"测试分层"、"测什么"、"risk-to-test"等。
+- **混合**：用户同时有实施和测试诉求。
+
+若意图不清，先问用户想看实施计划还是测试策略。
+
+## 实施规划路径
+
+1. 重述用户目标、成功标准和不在范围内的内容。
+2. 阅读相关代码、模板、规则、配置、测试和已有实现，避免脱离项目现状。
+3. 若涉及页面拆分、状态流、目录结构、数据流或大型重构，委托 **`fec-architect`**。
+4. 输出计划：
+   - 影响范围
+   - 关键文件或模块
+   - 架构与模块边界
+   - 数据流 / 状态流 / API 交互
+   - 实施阶段
+   - 回滚或渐进迁移策略
+   - 风险与缓解
+   - 最小验证门禁（lint、type-check、test、build、E2E 或人工验收）
+5. 对版本敏感、依赖升级或外部库相关决策，列出事实来源、版本范围、迁移影响和需要查证的文档。
+6. 在用户确认前不执行实现。
+
+实施规划保存到 `reports/architecture-proposal-YYYY-MM-DD-HHmmss.md`。
+
+## 测试规划路径
+
+1. 确定范围：
+   - 用户指定功能、PR、文件或业务流程时，以该范围为准。
+   - 用户未指定时，查看最近变更并推断主要风险面。
+   - 若用户要的是模块拆分、状态流、目录结构或迁移步骤，回到实施规划路径。
+
+2. 使用 `fec-testing-strategy` Skill 建立测试分层矩阵：
+   - 静态检查
+   - 单元测试
+   - 组件测试
+   - 轻量集成测试
+   - E2E 测试
+   - 视觉 / Storybook / interaction
+   - a11y / 安全 / 性能等专项质量验证
+
+3. 对每个风险给出建议测试层、优先级、建议命令、责任 skill 和失败定位证据。
+
+4. 标明哪些风险只需要现有门禁覆盖，哪些需要新增测试，哪些暂不覆盖并说明原因。
+
+5. 必要时委托 **`fec-test-planner`** 子代理生成独立测试计划。
+
+6. 将计划保存到 `reports/test-plan-YYYY-MM-DD-HHmmss.md`：
+
+   ```markdown
+   # 前端测试计划
+
+   > 生成时间: YYYY-MM-DD HH:mm
+   > 范围: ...
+
+   ## 风险概览
+
+   | Risk | Impact | Suggested Layer | Priority | Evidence |
+   | ---- | ------ | --------------- | -------- | -------- |
+
+   ## 覆盖矩阵
+
+   | Layer | What to Cover | Tooling / Command | Skill |
+   | ----- | ------------- | ----------------- | ----- |
+
+   ## 执行顺序
+
+   ## 不覆盖项与原因
+   ```
+
+7. 若用户要求继续实现测试，按矩阵分流到对应专项 skill 或 agent。
+
+## 混合路径
+
+当用户同时需要实施计划和测试策略时：
+
+1. 先输出完整实施规划。
+2. 在实施规划末尾追加"测试策略"章节，列出关键风险对应的测试层级和验证门禁。
+3. 只有用户明确要求完整覆盖矩阵时，才额外生成 `test-plan-*` 独立报告。
+
+## 边界
+
+- 不在计划阶段直接写代码，除非用户明确要求继续实现。
+- 不默认要求补齐完整测试金字塔，只按风险和维护成本选择覆盖。
+- 不负责大规模编写测试文件；用户明确要求落地时再分流到专项测试 skill。

package/commands/fec-refactor-clean.md

@@ -0,0 +1,19 @@
+---
+name: fec-refactor-clean
+description: 在验证保护下识别并清理前端死代码、未使用导出、过期组件、样式和依赖。
+---
+
+按 `fec-refactor-clean` 执行安全清理。复杂清理可委托 **`fec-refactor-cleaner`**。
+
+## 执行步骤
+
+1. 建立当前验证基线。
+2. 使用仓库已有工具或 `rg` 收集未使用候选项。
+3. 检查动态引用、路由、barrel export、Storybook、测试和样式入口。
+4. 将候选项分为 SAFE、CAUTION、DANGER。
+5. 仅清理 SAFE 项；其他项输出建议和证据。
+6. 每批清理后重新运行受影响验证命令。
+
+## 输出要求
+
+将清理报告保存到 `reports/refactor-clean-YYYY-MM-DD-HHmmss.md`。

package/commands/fec-review.md

@@ -0,0 +1,66 @@
+---
+name: fec-review
+description: 对指定文件或最近变更的前端代码进行规范化评审，输出分级评审报告并保存为 Markdown 文件。
+---
+
+对前端代码进行全面评审。先读项目现状和 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 流程即可。
+
+## 执行步骤
+
+1. 确定评审范围：
+
+   - 如果用户指定了文件路径，评审指定文件
+   - 如果用户没有指定文件，运行 `git diff --name-only HEAD` 获取最近变更的文件列表
+   - 如果没有 git 变更记录，提示用户指定需要评审的文件或目录
+
+2. 过滤只保留前端相关文件（`.ts`, `.tsx`, `.vue`, `.js`, `.jsx`, `.css`, `.scss`, `.less`, `.html`）
+
+3. 使用 `fec-code-review` Skill 的评审维度逐项检查：
+
+   - 架构（组件边界、职责分离）
+   - 类型安全（any 使用、props 类型）
+   - 渲染与状态（重复渲染、key 稳定性）
+   - 样式（Token 使用、响应式）
+   - Tailwind / 设计系统（token、variant、暗色模式、动态 class）
+   - 可访问性（语义化、ARIA、键盘操作）
+   - 可维护性（文件体积、命名、重复逻辑）
+   - 测试（关键覆盖、测试模式）
+   - 安全（XSS、敏感信息、输入校验）
+   - 性能（首屏依赖、重复请求、长任务、大列表）
+   - 依赖升级（lockfile、peer dependency、CVE、大版本迁移验证）
+
+   每个问题必须包含文件位置、影响、置信度和建议验证方式。
+
+4. 按以下格式输出评审报告：
+
+   ```
+   # 代码审查报告
+
+   > 生成时间: YYYY-MM-DD HH:mm
+   > 评审工具: frontend-craft
+
+   **评审范围**: N 个文件
+
+   ## 🔴 必须修改 (N项)
+   - **[文件:行号]** 问题描述 → 建议修改
+
+   ## 🟡 建议优化 (N项)
+   - **[文件:行号]** 问题描述 → 建议修改
+
+   ## 🔵 可选优化项 (N项)
+   - **[文件:行号]** 问题描述
+
+   ## 🟢 做得好的地方
+   - ...
+
+   ## 风险等级：低 / 中 / 高
+
+   **总体评价**: 可合并 / 待修改后合并 / 需要重构
+   ```
+
+5. 将报告内容使用 Write 工具保存为 Markdown 文件：
+   - 目录：项目根目录下的 `reports/`（如不存在则创建）
+   - 文件名：`code-review-YYYY-MM-DD-HHmmss.md`（使用当前时间戳）
+   - 保存后告知用户报告文件路径
+
+6. 如果用户同意修改，直接修复"必须修改"中可以自动修复的项目。

package/commands/fec-scaffold.md

@@ -0,0 +1,205 @@
+---
+name: fec-scaffold
+description: 按项目规范创建 page、feature 或 component 的标准目录结构和样板文件。用法：/fec-scaffold <type> <Name>，如 /fec-scaffold page UserDetail
+---
+
+按项目约定的目录结构创建新的 page、feature 或 component。
+
+## 依赖与版本
+
+若本次脚手架涉及新增或建议 `package.json` 依赖，遵循项目 `.claude/rules/fec-react.md` 或 `.claude/rules/fec-vue.md` 中「版本与依赖」约定；项目中尚无对应规则时，优先采用彼此兼容的主流稳定版本（对齐官方文档、脚手架默认值或包管理器推荐）。
+
+## 参数解析
+
+从 `$ARGUMENTS` 中解析两个参数：
+- **type**: `page` | `feature` | `component`（必填）
+- **name**: 模块名称，使用 PascalCase（必填）
+
+如果参数缺失，提示用法示例并要求用户补充：
+```
+用法：/fec-scaffold <type> <Name>
+示例：
+  /fec-scaffold page UserDetail
+  /fec-scaffold feature payment
+  /fec-scaffold component DataTable
+```
+
+## 执行步骤
+
+### 1. 检测项目框架
+
+检查 `package.json` 的 `dependencies`：
+- 包含 `react` → React 项目
+- 包含 `vue` → Vue 项目
+- 都不包含 → 提示用户手动指定
+
+### 2. 探测项目约定并确定目标路径
+
+检查 `src/`、`app/`、`pages/`、`features/`、`components/`、`__tests__/`、`tests/`、`vitest.config.*`、`jest.config.*`、`playwright.config.*` 和现有组件命名方式。优先复用项目已有目录；仅在没有现成约定时使用默认路径：
+- page → `src/pages/<Name>/`
+- feature → `src/features/<name>/`（name 转为 kebab-case）
+- component → `src/components/<Name>/`
+
+如果目标目录已存在，提示用户确认是否继续。
+
+### 3. 创建目录和文件
+
+根据框架和类型，创建以下结构：
+
+#### React page
+
+```
+src/pages/<Name>/
+├── <Name>Page.tsx
+├── components/
+│   └── .gitkeep
+└── hooks/
+    └── .gitkeep
+```
+
+`<Name>Page.tsx` 内容：
+
+```tsx
+export default function <Name>Page() {
+    return (
+        <div>
+            <h1><Name></h1>
+        </div>
+    );
+}
+```
+
+#### React feature
+
+```
+src/features/<name>/
+├── components/
+│   └── .gitkeep
+├── hooks/
+│   └── .gitkeep
+├── api.ts
+├── types.ts
+├── constants.ts
+└── index.ts
+```
+
+`index.ts` 内容：
+
+```typescript
+export * from './types';
+export * from './constants';
+```
+
+`api.ts` 内容（仅在项目已有 `src/services/request.*`、`src/lib/request.*`、`src/api/client.*` 或同类 API client 时导入对应 client；否则保持空导出，避免制造不存在的别名依赖）：
+
+```typescript
+export {};
+```
+
+`types.ts` 和 `constants.ts` 创建为空文件或最小空导出。
+
+#### React component
+
+```
+src/components/<Name>/
+├── <Name>.tsx
+├── <Name>.styles.css
+└── __tests__/
+    └── <Name>.spec.tsx
+```
+
+`<Name>.tsx` 内容：
+
+```tsx
+import './<Name>.styles.css';
+
+interface <Name>Props {
+    children?: React.ReactNode;
+}
+
+export function <Name>({ children }: <Name>Props) {
+    return (
+        <div className="<name>">
+            {children}
+        </div>
+    );
+}
+```
+
+#### Vue page
+
+```
+src/pages/<Name>/
+├── <Name>Page.vue
+├── components/
+│   └── .gitkeep
+└── composables/
+    └── .gitkeep
+```
+
+`<Name>Page.vue` 内容：
+
+```vue
+<script setup lang="ts">
+</script>
+
+<template>
+    <div>
+        <h1><Name></h1>
+    </div>
+</template>
+
+<style scoped>
+</style>
+```
+
+#### Vue feature
+
+```
+src/features/<name>/
+├── components/
+│   └── .gitkeep
+├── composables/
+│   └── .gitkeep
+├── api.ts
+├── types.ts
+├── constants.ts
+└── index.ts
+```
+
+`index.ts` 内容与 React 相同。
+
+#### Vue component
+
+```
+src/components/<Name>/
+├── <Name>.vue
+└── __tests__/
+    └── <Name>.spec.ts
+```
+
+`<Name>.vue` 内容：
+
+```vue
+<script setup lang="ts">
+interface Props {
+}
+
+const props = defineProps<Props>();
+</script>
+
+<template>
+    <div>
+        <slot />
+    </div>
+</template>
+
+<style scoped>
+</style>
+```
+
+### 4. 输出确认
+
+创建完成后，输出：
+- 创建的文件清单
+- 下一步建议（如"在路由配置中注册新页面"、"在 index.ts 中导出公开 API"）

package/commands/fec-tdd.md

@@ -0,0 +1,21 @@
+---
+name: fec-tdd
+description: 使用前端 TDD 工作流实现功能、修复 Bug 或重构逻辑：先写失败测试，再实现最小代码，再重构。
+---
+
+按 `fec-tdd-workflow` 执行测试驱动开发。
+
+## 执行步骤
+
+1. 明确要验证的前端行为。
+2. 选择最近风险的测试层：单元、组件、轻量集成或 E2E。
+3. 写最小失败测试并运行，确认失败原因正确。
+4. 写最小实现让测试通过。
+5. 保持测试通过后再重构。
+6. 总结测试命令、覆盖行为和剩余风险。
+
+## 分流
+
+- 组件和 hook 测试：`fec-component-testing`
+- 跨页浏览器流程：`fec-e2e-testing`
+- 测试分层策略：`fec-testing-strategy`