feat: v6 pre-release

Author: hooray

.agents/skills/design-taste-frontend/SKILL.md

@@ -0,0 +1,135 @@
+---
+name: fa-feedback
+description: 当用户在使用 fa-* 系列技能（如 fa-framework-settings、fa-slot-creator、fa-form-builder、fa-route-generator、fa-store-generator、fa-page-optimizer、fa-theme-customizer 等）时，在同一个目标上经历了 3 次及以上的修改仍未达到预期效果，必须触发此技能。触发信号包括：用户反复要求调整同一处配置或代码、连续说"不对"/"再改改"/"还是不行"、对同一个功能点多次提出修正意见。即使用户没有明确表示"上报"或"反馈"，只要检测到反复沟通修改的模式，就应主动触发。
+---
+
+# Fantastic-admin 问题反馈
+
+当用户在使用 fa-* 系列技能时遇到反复修改仍无法达到预期的情况，这通常意味着框架本身可能存在改进空间（比如 skill 指令不够精确、框架 API 不够直观、文档缺失等）。此时应主动询问用户是否愿意将问题反馈给框架作者。
+
+## 触发条件
+
+在当前对话中，如果满足以下任一条件，则触发此技能：
+
+1. **同一目标的修改次数 >= 3 次**：用户针对同一个功能点或配置项，已经要求修改 3 次及以上
+2. **用户表达持续不满**：用户连续使用"不对"、"还是不行"、"再试试"、"跟我说的不一样"等表述
+3. **循环修改模式**：修改 A -> 改回 -> 再改 A，出现来回反复的情况
+
+## 执行流程
+
+### 第一步：分析问题
+
+回顾当前对话历史，提炼以下信息：
+
+1. **使用的技能**：用户在使用哪个 fa-* 技能
+2. **用户的原始需求**：用户最初想要实现什么
+3. **反复修改的焦点**：哪个具体的配置项/代码/功能点在被反复调整
+4. **未达预期的原因**：为什么始终无法满足用户的需求（是 skill 指令有误？框架 API 限制？还是理解偏差？）
+
+### 第二步：询问用户
+
+用以下方式询问用户（注意语气要友好自然，不要让用户感到被指责）：
+
+```
+我注意到在 [具体功能] 上我们已经来回调整了好几次，这很可能说明框架的 [skill/文档/API] 在这方面有改进空间。
+
+你是否愿意将这个问题反馈给 Fantastic-admin 的作者？这有助于改进框架，让以后的使用体验更好。
+
+如果你同意，我会帮你整理一份精简的问题描述，然后打开 GitHub Discussions 页面，内容会自动填好，你只需要检查一下就可以提交。
+```
+
+- 如果用户**同意**，继续第三步
+- 如果用户**拒绝**，尊重用户的决定，继续协助解决当前问题，不再提及反馈
+
+### 第三步：整理反馈内容
+
+生成精简的反馈报告，格式如下：
+
+**标题**（简洁明了，一句话概括问题）：
+```
+[技能名称] 在 [场景] 下无法正确 [操作]
+```
+
+**正文**（使用 Markdown 格式）：
+```markdown
+## 问题描述
+
+[一句话说明用户想做什么，以及遇到了什么问题]
+
+## 使用的技能
+
+[fa-xxx-xxx]
+
+## 复现步骤
+
+1. [用户的原始请求]
+2. [第一次修改及结果]
+3. [后续修改及结果]
+
+## 期望行为
+
+[用户期望的结果是什么]
+
+## 实际行为
+
+[实际发生了什么，为什么不符合预期]
+
+## 可能的原因
+
+[基于分析，推测问题可能出在哪里，比如 skill 指令、框架 API、默认配置等]
+```
+
+内容整理原则：
+- **精简**：只保留关键信息，去掉对话中的冗余内容
+- **客观**：描述事实，不添加情绪化表达
+- **可操作**：让框架作者看到后能理解问题并采取行动
+
+### 第四步：生成链接并打开
+
+将整理好的标题和正文通过 URL 参数编码，拼接到 GitHub Discussions 链接中：
+
+```
+https://github.com/orgs/fantastic-admin/discussions/new?category=通用&title={编码后的标题}&body={编码后的正文}
+```
+
+使用以下方式生成并打开链接：
+
+```bash
+# 生成 URL 编码的链接并打开
+python3 -c "
+import urllib.parse
+import subprocess
+
+title = '''在此填入标题'''
+body = '''在此填入正文'''
+
+params = urllib.parse.urlencode({
+    'category': '通用',
+    'title': title,
+    'body': body
+}, quote_via=urllib.parse.quote)
+
+url = f'https://github.com/orgs/fantastic-admin/discussions/new?{params}'
+print(f'链接已生成：{url}')
+subprocess.run(['open', url])
+"
+```
+
+打开链接后，告诉用户：
+
+```
+已在浏览器中打开 GitHub Discussions 页面。请检查预填的内容是否准确，确认无误后点击提交即可。
+
+如果页面中的标题和内容没有自动填充（GitHub Discussions 可能不支持 URL 参数预填），你可以手动复制以下内容：
+
+**标题**：[标题内容]
+
+**内容**：
+[正文内容]
+```
+
+始终同时展示原文内容作为备选方案，确保用户无论 URL 参数是否生效都能顺利提交反馈。
+
+### 第五步：继续协助
+
+反馈流程完成后，继续协助用户解决当前的问题，不要因为反馈流程中断用户的工作。

.agents/skills/fa-feedback/SKILL.md

@@ -0,0 +1,88 @@
+---
+name: fa-form-builder
+description: "为 Fantastic-admin 框架生成独立的表单页面，使用 vee-validate + zod 验证，全部使用框架内建 Fa* 组件。当用户说：'帮我做一个用户信息填写页'、'我只需要一个提交表单，不需要列表'、'做个设置页面，有几个输入框和保存按钮'、'生成一个注册/编辑/配置表单页'、'只要表单页，不需要增删改查'，即使用户只是说'做个表单页面'也应触发此技能。"
+---
+
+# 表单页面生成器
+
+在 Fantastic-admin 框架中生成独立的 Router 表单页面，使用 vee-validate + zod 完成表单验证，全部使用框架内建 Fa* 组件，不引入任何 Element Plus 组件。
+
+**生成的文件：**
+- `apps/<app>/src/views/{path}/{name}/index.vue` — 表单页面（含验证、提交骨架、固定操作栏）
+
+---
+
+## 第一步：确认工作区（必须阻塞等待用户回复）
+
+本项目是 monorepo 架构，`apps/` 目录下存放各应用。**在执行任何文件读写操作之前**，必须先确认目标应用：
+
+1. 执行 `ls apps/` 列出所有可用应用
+2. **立即向用户提问**，明确询问要在哪个应用中生成表单页面，并**停止等待回复**
+3. 收到用户明确回复后，才能继续后续步骤
+
+> **严格规则**：如果用户没有在请求中明确说明目标应用（例如"在 example 应用中"、"apps/core"），则必须提问，不得自行猜测或默认选择任何应用。
+
+确认后，后续所有文件路径均以该应用目录为根。
+
+---
+
+## 工作流程
+
+### Step 1：收集基本信息
+
+向用户询问（可合并为一次提问）：
+
+1. **模块名**（英文，用于文件路径，如 `user`、`profile`、`setting`）
+2. **模块中文名**（用于页面标题，如 `用户信息`、`个人资料`）
+3. **存放路径**（在 `apps/<app>/src/views/` 下的子目录，如 `system`、`account`，留空则直接放在 `src/views/` 下）
+
+### Step 2：收集字段信息
+
+询问用户该表单有哪些字段，每个字段需要：
+- **字段名**（英文，如 `name`、`avatar`、`status`）
+- **中文标签**（如 `姓名`、`头像`、`状态`）
+- **字段类型**（见 references/templates.md 中的字段类型映射表）
+- **是否必填**
+
+如果用户没有提供字段信息，使用默认字段 `title`（标题，string，必填）作为示例占位，并在生成后提示用户替换。
+
+### Step 3：判断布局
+
+字段较多时单列会导致页面过长，双列更紧凑。根据字段数量和复杂度判断是否询问用户布局偏好：
+
+- **单列**：`max-w-600px`，`space-y-6`（字段少、字段较长时适合）
+- **双列**：`max-w-1200px`，`grid grid-cols-1 gap-x-8 gap-y-6 items-start md:grid-cols-2`（字段多、字段较短时适合）
+
+### Step 4：确认并生成
+
+汇总信息，展示将要生成的文件，确认后写入。
+
+生成完成后提示：如需配置路由，请使用 `fa-route-generator` 技能；如需 API 模块，请手动创建。
+
+---
+
+## 命名规范
+
+给定模块名 `name` 和路径 `path`（相对于 `apps/<app>/src/views/`）：
+
+| 用途 | 规则 | 示例（path=system, name=user） |
+|------|------|-------------------------------|
+| 视图目录 | `apps/<app>/src/views/{path}/{name}/` | `apps/<app>/src/views/system/user/` |
+| 组件名 | `PascalCase({path}-{name}-form)` | `SystemUserForm` |
+
+---
+
+## 代码模板
+
+详细的代码模板和字段类型映射表见 [references/templates.md](references/templates.md)。
+
+生成代码时替换模板中的占位符：
+- `{cname}` → 模块中文名
+- `{componentName}` → PascalCase 组件名
+- `{zodSchema}` → zod 字段定义（每个必填字段对应一行 zod 规则）
+- `{initialValues}` → 字段初始值（string 默认 `''`，boolean 默认 `false`，number 默认 `0`，array 默认 `[]`）
+- `{formItems}` → 各字段对应的 FormField 代码片段
+- `{maxWidth}` → 单列 `max-w-600px` / 双列 `max-w-1200px`
+- `{gridClass}` → 双列时 `grid grid-cols-1 gap-x-8 gap-y-6 items-start md:grid-cols-2` / 单列时 `space-y-6`
+
+生成的代码是骨架：API 调用处用 `// TODO:` 注释标记，动态数据源（select options、upload action 等）用占位注释标记，用户根据实际接口替换。操作栏按钮使用 `FaButton`：取消用 `variant="outline"`，提交用默认 variant 并传 `:loading="isSubmitting"`。