pandax 0.0.1

package/skills/pandax-frontend-component-review/SKILL.md

@@ -0,0 +1,114 @@
+---
+name: "pandax-frontend-component-review"
+category: "frontend"
+description: "审查 Vue/React 组件代码。Invoke when 用户要求审查组件、review component、或组件代码涉及命名、Props、样式隔离、可访问性等场景。"
+---
+
+# Pandax 组件规范审查
+
+本 skill 用于审查前端组件是否符合 Pandax 前端团队的组件开发约定。
+
+## 触发条件
+
+- 用户说"帮我 review 这个组件"
+- 用户要求"检查组件规范"
+- 新增、修改或重构 Vue/React 组件时
+- 组件涉及 props 设计、事件命名、样式隔离、可访问性等议题
+
+## 审查前置
+
+审查前先读取 `.trae/skills/pandax-frontend-standards/SKILL.md` 中的组件规范，特别是 Vue3 组件结构约定。
+
+## 审查维度
+
+### 1. 文件与命名
+
+- 组件文件名使用大驼峰（PascalCase），如 `UserProfile.vue`
+- 目录结构按功能模块组织，避免扁平堆砌
+- 单一组件文件行数不宜超过 300 行，复杂组件应拆分
+
+#### Vue3 组件结构审查
+
+如果项目是 Vue3，组件目录必须采用以下结构：
+
+```text
+app-register/                 # 目录名：全小写 + 短横线
+├── index.vue                 # 默认入口
+├── Prop.ts                   # Props 定义
+├── Type.ts                   # TS 类型定义
+└── index.module.scss         # CSS Modules 样式
+```
+
+检查点：
+
+- 组件目录名是否全小写 + 短横线？
+- 是否存在 `index.vue` 作为默认入口？
+- Props 是否抽离到 `Prop.ts`？
+- 类型是否抽离到 `Type.ts`？
+- 样式文件是否为 `index.module.scss`？
+- 子组件是否放在 `components/` 下并遵循同样结构？
+- 组件是否足够原子化？可复用片段是否已拆分为子组件？
+
+#### Vue3 代码组织审查
+
+如果是 Vue3 组件，检查 `index.vue` 内部：
+
+- 是否使用 `<script setup lang="ts">`？
+- `import` 语句是否放在顶部，没有包 region？
+- 是否按 `Props → Types → State → Computed → Watch → Lifecycle → Methods → Expose` 顺序组织？
+- 从 `Props` 开始是否使用 `// #region` 和 `// #endregion` 包裹每个区域？
+- 每个生命周期钩子（`onBeforeMount`、`onMounted`、`onBeforeUpdate`、`onUpdated`、`onBeforeUnmount`、`onUnmounted`）是否都有对应的 region？
+- 未使用的生命周期 region 是否用 `// 当前组件未使用` 占位，而不是空函数调用？
+- 已使用的生命周期是否有一句话用途说明？
+- 生命周期是否按执行顺序排列？
+
+#### Vue3 页面结构审查
+
+如果审查对象是 `views/` 下的页面组件，检查：
+
+- 页面模块目录是否全小写 + 短横线，如 `user-management/`？
+- 列表页是否有 `index.vue` 作为默认入口？
+- 子页面是否放在 `pages/` 目录下？
+- `pages/` 下的子页面命名是否简洁（如 `create/`、`edit/`、`detail/`）？
+- 新增/编辑 UI 相似时，是否合并为 `pages/form/` 共用页？
+- 页面内私有组件是否放在当前页面目录的 `components/` 下？
+- 新增/编辑复用页是否通过路由参数 `id` 判断模式？
+
+### 2. Props 设计
+
+- Props 必须声明类型与默认值（TypeScript 优先使用 interface/type）
+- 避免过多的 props（>7 个）导致组件职责不清
+- boolean 类型 props 命名应为形容词，如 `disabled`、`visible`
+- 事件名使用 `onXxx` 或 `xxxChange`，保持语义清晰
+
+### 3. 样式隔离
+
+- Vue 单文件组件使用 `scoped` 或 CSS Modules
+- React 优先使用 CSS Modules / styled-components，避免全局污染
+- 禁止使用 `!important` 覆盖样式，除非有明确注释说明原因
+
+### 4. 可访问性（a11y）
+
+- 图片必须有有意义的 `alt` 属性
+- 表单控件必须关联 `<label>`
+- 交互元素必须可通过键盘访问
+
+### 5. 性能
+
+- 避免在渲染函数中创建新的对象/数组/函数引用
+- 大数据列表使用虚拟滚动或分页
+- 合理使用 `memo` / `computed` 避免不必要的重渲染
+
+## 输出格式
+
+审查结果按三级标注：
+
+- **必须修复**：阻塞性问题，必须修改
+- **建议修改**：影响可维护性或体验，建议修改
+- **仅供参考**：风格或偏好问题，可讨论
+
+每个问题需给出：
+1. 具体问题描述
+2. 所在文件与行号（如适用）
+3. 修改建议或示例代码
+4. 依据的 Pandax 规范条目

package/skills/pandax-frontend-requirement/SKILL.md

@@ -0,0 +1,142 @@
+---
+name: "pandax-frontend-requirement"
+category: "frontend"
+description: "梳理前端需求并输出可执行方案。Invoke when 用户提出新前端需求、接需求任务、或需要判断有/无设计图时如何推进。"
+---
+
+# Pandax 前端需求梳理
+
+本 skill 用于规范前端工程师接到需求后的梳理流程，确保在有设计图或无设计图两种情况下都能对齐需求、明确范围，再进入执行阶段。
+
+## 触发条件
+
+- 用户提出新的前端需求
+- 用户说"帮我做个页面/组件/功能"
+- 用户给出设计图或原型，需要开始开发
+- 用户没有设计图，只有一个想法或一句话需求
+- 需求边界不清，需要先分析再动手
+
+## 执行流程
+
+### 步骤 1：调用 superpowers-zh 的 brainstorming skill 做需求分析
+
+在动手实现之前，必须先调用 `.trae/skills/brainstorming/SKILL.md`（或当前工具对应的 brainstorming skill），按照其流程：
+
+1. 检查项目当前状态（技术栈、目录结构、相关已有代码）
+2. 向用户提问，一次只问一个关键问题
+3. 探索 2-3 种可行方案并说明优劣
+4. 输出一份经过用户确认的设计文档
+
+### 步骤 2：判断是否有设计图
+
+在 brainstorming 过程中或结束后，明确以下问题：
+
+- 是否有 UI 设计稿（Figma / Sketch / PSD / 图片）？
+- 是否有交互原型（Axure / 墨刀 / 手绘稿）？
+- 是否有参考页面或竞品链接？
+- 是否只有文字描述？
+
+### 步骤 3：有设计图时的梳理
+
+如果有设计图或原型，执行以下子步骤：
+
+1. **设计图分析**
+   - 页面结构：Header / Content / Footer / Sidebar 等
+   - 视觉层次：主次信息、颜色、字体、间距
+   - 响应式要求：是否需要适配多端？断点如何定义？
+2. **组件拆分**
+   - 识别哪些组件是已有组件可复用
+   - 识别哪些组件需要新建
+   - 公共样式、主题变量是否需要调整
+3. **交互梳理**
+   - 用户操作路径（点击、输入、提交等）
+   - 状态变化（加载、空态、错误、成功）
+   - 动画/过渡效果要求
+4. **输出设计还原检查清单**
+   - 标注需要特别注意的像素、间距、颜色值
+   - 记录设计师未明确但开发中会遇到的问题
+
+### 步骤 4：无设计图时的梳理
+
+如果没有设计图，执行以下子步骤：
+
+1. **明确目标用户和使用场景**
+   - 这个功能给谁用？在什么场景下用？
+2. **确认核心信息结构**
+   - 页面上必须展示哪些信息？
+   - 用户需要完成什么操作？
+3. **提供 2-3 种低保真方案**
+   - 可用文字描述或 ASCII / Markdown 表格示意布局
+   - 说明每种方案的适用场景和取舍
+4. **与用户确认后再细化**
+   - 不要直接开始写代码
+   - 先得到用户对方向和大致布局的认可
+
+### 步骤 5：调用 pandax-frontend-standards 检查规范
+
+在制定执行计划之前，先判断本次需求是否涉及前端规范问题：
+
+- 是否需要新建组件？→ 检查组件目录、命名、Vue3 结构规范
+- 是否需要新建页面？→ 检查 `views/` 目录组织、路由规范
+- 是否需要对接 API？→ 检查 `services/`、`api/`、`types/` 分层规范
+- 是否需要弹窗/抽屉？→ 检查容器选择规则
+- 是否涉及中文文案？→ 检查文案排版规范
+
+如果涉及以上任何一项，先读取 `.trae/skills/pandax-frontend-standards/SKILL.md`，并依据其中的默认约定或项目 `docs/standards/` 文档，在后续执行计划中体现规范要求。
+
+### 步骤 6：调用 writing-plans 制定执行计划
+
+需求梳理和规范明确后，调用 `.trae/skills/writing-plans/SKILL.md`，将设计文档拆解为可执行的小任务：
+
+- 每个任务 2-5 分钟可完成
+- 明确文件路径
+- 明确验证方式
+- 明确需要遵循的 Pandax 规范条目
+
+### 步骤 7：用户确认后再执行
+
+- 将需求梳理结果、规范依据和执行计划展示给用户
+- 等待用户确认或调整
+- 确认后再调用 executing-plans / subagent-driven-development / test-driven-development 等 skill 进入实现阶段
+
+## 输出模板
+
+建议将需求梳理结果保存到 `docs/requirements/` 或项目约定的位置：
+
+```markdown
+# 需求名称
+
+## 背景与目标
+
+## 用户场景
+
+## 设计图状态
+- [ ] 有设计图（附链接/文件路径）
+- [ ] 无设计图，已确认低保真方案
+
+## 信息结构与交互
+
+## 组件拆分
+
+## 规范依据
+
+列出本次需求需要遵循的 Pandax 规范：
+
+- 组件规范：`pandax-frontend-standards` 中 Vue3 组件结构约定
+- 页面规范：`pandax-frontend-standards` 中 `views/` 目录组织约定
+- API 规范：`pandax-frontend-standards` 中 `api/` + `services/` 分层约定
+- 弹窗/抽屉规范：`pandax-frontend-standards` 中容器选择规则
+- 文案规范：`pandax-frontend-chinese-copywriting`
+
+（按实际需求勾选）
+
+## 待确认问题
+
+## 执行计划
+```
+
+## 禁止事项
+
+- 不要在需求边界不清时直接写代码
+- 不要假设设计图中的细节，不确定的要问设计师或用户
+- 不要在没有用户确认的情况下，替用户决定交互方案