做前端需求总结出的非常好用的skill

在开发中多去拆分步骤，SOP化，拆成一个一个小skill，有助于帮助自己处理一些比较繁琐的任务

代码梳理

这是一个非常屌的代码梳理技能，可以帮助你在调研阶段快速了解代码逻辑会从页面、逻辑两个角度，从宏观到局部

例如筛选块、表格，然后比如说操作栏里面编辑按钮展示逻辑，都会梳理清楚
如果是复杂逻辑会放在逻辑里面
如果你们项目里面有某个文件专门放接口，像我们项目是service/index.js；这个技能会梳理出调用这个接口所有的入参出参，中文意思

shell 复制代码

---
name: deal-with-code-to-fontend-logic
description: 这是一个梳理前端具体逻辑的技能。
---


## 目标

把代码整理成前端逻辑，用前端语言，中文，放到.docs/代码逻辑梳理
## 触发使用技能
- 用户提到放到".docs/代码逻辑梳理"
- 重新梳理
- 代码梳理
- 逻辑梳理

## 适用边界

- 帮助ai或者人快速了解具体完整的前端逻辑细节
## 强制要求
必须先读取案例再结合步骤进行执行，只理解步骤，会导致理解会不准确，案例就是代码步骤的最准确意思
## 原则
如果字段能通过项目上下文得知什么意思，必须列出什么意思，案例：是否展示（isShow）


## 执行流程
1. 读取文件，或者通过中文识别用户输入的业务是哪个文件下，先区分是梳理整块业务还是单个文件，假设用户说的是整理短信工具，则用户的意思是整理message_tools的所有文件，那么需要根据一个一个文件来进行梳理，假设用户说的是梳理某个单独的组件，则仅仅只需要梳理当前的组件文件
2. 根据每个文件去整理，忽略css
3. 整理成简要逻辑
4. service文件查看案例，根据这个模版来输出，结合以service的url为纲，根据项目上下文，梳理出出参和入参

## 文档规范（强制检查输出文档）
参考./案例/文档规范案例.md
- 不要出现过多代码（代码只能是辅助，重要是用中文梳理逻辑细节，例如禁止条件：status==2）
- 必须包含（页面、逻辑）title
    - 逻辑：必须保留具体逻辑，例如禁止，权限等
- 先整体后细节：先列模块（例如：查询/筛选、列表、详情、弹窗、抽屉等），再进入每个模块内部。
- 如果同一页面存在多种"展示场景/模式"（比如不同 tab、不同业务类型、不同入口），要按"场景"分别列字段顺序（不能合并写"字段A/字段B"）
### 页面
应该先整体到细节列出页面展示情况，如果某个按钮有简单逻辑逻辑，在这个部分必须列出，如果太复杂则在逻辑列出
#### 筛选
- 每个字段需要展示接口字段+表单类型（input、select等）+枚举，例如：
- 短信任务id（id）
- 人群圈选（字段：cordType）（下拉）  
   - 全部  
   - 种子（值 1）  
   - 强相关（2）  
   - 潜在兴趣（3）  
   - 泛化人群（4）
#### 列表
- 如果有列表应该列出所有的字段、如果有表单应该保留表单字段（字段名字一个字不能错，必须按照顺序），列表就是从左到右，表单有可能是从上到下或者从左到右
- 每个字段需要展示接口字段
- 每个列表列，如果有逻辑，则需要展示逻辑明细，例如禁止、因为某个if分支才展示等，但是禁止展示简单的兜底，例如为空时兜底"-"，如果没有特殊逻辑，只有获取接口字段，以及简单兜底，则禁止出现逻辑明细
- 除了字段能用代码，其他禁止出现代码，只能用中文逻辑
- 禁止出现枚举的英文字段引用，只能用中文枚举
- 使用方法才能把逻辑放到"逻辑"模块里面，如果在react-dom里面做判断，这部分逻辑都应该放到"页面"模块
##### if else应该分别说明
案例：
if(noShow){
    return '-'
}
return 首推用户
分析：
这里完整逻辑应该是
if(noShow){
    return '-'
}else{
    return 首推用户
}
错误输出：
如果无需展示，兜底'-'；返回首推用户
正确输出：
如果无需展示，出现'-'，否则展示首推用户
##### 模版
根据这个模版来输出
- 短信任务ID（id)
- 人群圈选
    - 如果是城市用户，用字段"cityName"
    - 如果是xx，用字段"fileName"
    - 如果是定制模版
        - 第一行，接口fileName
        - 第二行，接口crowdTaskName、新标签（具体逻辑看xxx）、大演定制标签



##### 操作按钮必须拆两层写（强制）
页面-操作栏：只写"按钮是否展示"的条件
条件写法：中文可读的状态/原因 +（括号里写代码条件）
对于无法推断含义的"权限位/标记位数字"，只写代码条件本身，不要硬翻译

#### 弹窗
必须写 标题 + 核心文案/关键字段（不能只写"有弹窗"）
有动态文案时，必须写清楚 变量取值规则（例如 planName 怎么算）
### 逻辑
#### 列表-操作
逻辑-操作行为：写"点了按钮发生什么"
必须落到具体动作：跳转到哪（路径 + query/params）、请求哪个接口（method + url）、是否二次确认、成功后如何刷新/回跳/提示
如果按钮只是触发上层回调，必须继续向上追踪到页面/模型/服务层，直到能写出"跳转/接口/弹窗"的真实行为


## 输出示例

### 案例1
流程：1. 读取文件，或者通过中文识别用户输入的业务是哪个文件下
输入：短信工具
读取：message_tool下
### 案例2
流程：3. 整理成简要逻辑
#### 短信工具或者message_tool
#### 输出
案例3
流程：3.整理成简要逻辑
输入：src/pages/message_tool/components/message整理成前端逻辑
错误输入：./案例/案例3-错误.md
正确输入：./案例/案例3-正确.md
## 限制
- 允许写代码，但只能"最小代码"
- 文档里不贴大段代码；只允许在括号里放关键判断（例如 status == 1），或列举映射（value→name）。
重点是中文解释"为什么"，不是复述实现细节（例如不要展开 props 列表、不要写分页参数这种细节）。
- 禁止写props、向父组件派发的事件这种技术方面的梳理
- 禁止在文档出现"本文档根据deal-with-code-to-fontend-logic梳理"

## 检查
- 字段自检：列表字段是否与 title 文案逐字一致？顺序是否从左到右？
- 场景自检：是否把不同场景的字段/规则混写在一起？
- 映射自检：所有 value→name 是否逐条列出？是否遗漏某个值？
- 展示条件是否都在"页面-操作栏"？
- 点击后的跳转/接口/确认/刷新是否都在"逻辑-操作行为"？
- 动态文案自检：弹窗/页面上出现的关键文案是否遗漏？动态变量取值规则是否写清？

找出页面入口

这个在梳理影响范围的非常好用，比如说修改公共组件，梳理影响范围的时候就可以找到所有使用公共组件的业务组件，再用这个skill找到页面入口，可以直接贴在文档让测试看，自己在页面进行点击找起来也相当方便

yaml 复制代码

---
name: find-component-entry
description: 从界面操作路径反查「怎么点进某个 Vue/React 组件所在页面」；用户问进入方式、菜单路径、路由入口、如何打开某页面时使用。
---

# 查找组件在界面上的进入方式

## 这个 Skill 是干什么的

当你拿着**源码里的某个组件文件**（例如 `src/views/xxx.vue`、`src/components/xxx.vue`），想知道在**真实产品界面上**要**点哪些菜单、Tab、按钮**才能进到用这个组件的页面------就用本 Skill。

产出物应是**可照做的点击路径**（必要时带上测试环境可点的 hash 链接），而不是只贴一行路由配置。

---

## 用户一般怎么问

- 「这个组件从哪进？」「菜单路径是什么？」
- 「怎么在测试环境打开这个页面？」
- 「帮我找 `xxx.vue` 的入口」

---

## 你需要用户提供什么

组件路径，例如：

- `src/components/theatre/information.vue`
- `src/views/user/profile.jsx`

---

## 分析步骤（AI 照着做）

### 1. 找谁引用了这个组件

全仓库搜 import / 动态 import。**必须**同时尝试两种写法：

**写法 A：带扩展名**

- `from '@/components/foo/bar.vue'`
- `import('@/components/foo/bar.vue')`

**写法 B：省略 `.vue`（很常见，漏搜会找不到）**

- `from '@/components/foo/bar'`
- `import('@/components/foo/bar')`

> 许多人不写 `.vue`，编辑器「查找引用」可能不完整，所以两种都要搜。

### 2. 锁定父级页面

- 看 `src/views/**`、`src/pages/**` 里谁 import 了它
- 若有 `router-view`、异步组件，再往上追到「页面级」Vue 文件

### 3. 对齐路由

- 查 `src/router/**`、`src/routes/**` 等
- 把「页面组件」对应到 `path` / `name`
- 理清侧栏层级：一级菜单 → 二级 → ...（以实际路由/菜单配置为准）

### 4. 找菜单/侧栏文案

- 路由或菜单配置里的 `label`、`meta.title` 等
- 若项目有 `.docs/routes/**` 可辅助对照

### 5. 核对路由是不是「真在用」（重要）

全仓库再搜该路由是否被引用，避免告诉用户一条已废弃的路：

javascript
// 编程式跳转
router.push('/path')
this.$router.push({ name: 'routeName' })

// 声明式
<router-link to="/path">

// 配置里 redirect
redirect: '/path'

// 菜单项
{ path: '/path', label: '某某菜单' }

// 其它
@click="$router.push('/path')"


**判断表**：

| 菜单上能看见 | 代码里有人跳这段路由 | 建议标注 | 输出时注意 |
|-------------|---------------------|----------|------------|
| 是 | 是 | 正常 | 菜单路径 + 其它跳转入口都可写 |
| 是 | 否 | 主要走菜单 | 说明主要从侧栏进 |
| 否 | 是 | 跳转入口 | 说明从哪个页的哪个按钮/链接进 |
| **否** | **否** | **⚠️ 可能已废弃** | **提醒用户向业务/后端确认是否还在用** |

> 若 `sidebarShow: false`（或没有菜单）**且**完全搜不到 `push` / `router-link` / `redirect` / 菜单配置，优先标「可能已废弃」。

---

## 输出格式（建议）

用 Markdown，至少包含：

1. **进入方式（简要）**：`一级 → 二级 → Tab → ...` 一句话
2. **路由跳转链接**（如需要）：测试环境前缀 + path（见下节）
3. **进入方式（详细）**：按**真实点击顺序**写：点哪个菜单、切换到哪个 Tab、点哪个按钮；按钮/Tab **文案与线上保持一致**
4. **组件在页里干什么**（一句话，可选）

模板示例（内容替换成真实分析结果即可）：

```markdown
## 进入方式（简要）

aa管理 → xx管理 → 智慧yy馆 → 基础信息


## 进入方式（详细）

**菜单路径**：客户角色账号管理 → 企业管理 → 智慧场馆

**具体操作**：

1. 左侧进入 **客户角色账号管理** → **企业管理**（`/roleAccountMag/business/list`），默认「主办企业」Tab
2. 点 **「智慧场馆」** Tab
3. 在列表页：点 **「新建企业」** 或某行 **「编辑」**（见下表）
4. 进入页面后默认第一个 Tab **「基础信息」**，对应该组件

| 操作 | 路径 | 场景 |
|------|------|------|
| 新建企业 | `/roleAccountMag/business/newBusiness/1/0` | 新建 |
| 编辑 | `.../newBusiness/1/${companyId}` | 编辑 |

**组件功能**：......（一句话）


---



## 注意事项

- 写的是**用户怎么点**，不是只贴 `routes.js`。
- **每一步**应对应真实 UI：**菜单名 / Tab 名 / 按钮文案**要与界面一致。
- 有 Tab 切换要写清楚 Tab 名称；有「新建/编辑」两条路要分开写。
- 顶部保留**简要路径**方便复制给同事。
- **务必排查废弃路由**，避免把人带到已经不再使用的页面。

---

## 描述粒度（必须达到）

每条路径里应体现：

1. **菜单**：一级 → 二级（如有）
2. **Tab**：点 **「某某」** Tab（如有）
3. **按钮/链接**：点 **「某某」** 按钮或链接
4. **结果动作**：新建 / 编辑 / 查看 等

**合格示例**：

```text
运营xx → xx管理 → yyy → 点「zz」→ 点「hh」→ 添加/编辑


> 规则：**每一个 `→` 都必须对应界面上看得见、点对点的名字**（菜单 / Tab / 按钮 / 链接）。

自我review

这个可以在每次提交前过一遍，如果平时自己开发容易有某一类bug也可以加上去

markdown 复制代码

---
name: commit-pre-check
description: 对 git 所有改动做提交前检查，并输出问题清单（只读，不改代码）
---

# 触发场景（必须）

当用户准备提交代码，或提出「提交前检查 / commit 前检查 / review 一遍改动」时，必须执行本检查。

# 核心约束（必须遵守）

- **必须仅基于 git 改动范围检查**：只检查本次 `git diff` / `git status` 涉及的文件与改动片段，禁止泛化到全仓无关代码。
- **必须输出问题清单**：如发现风险/问题，必须逐条列出（文件 + 位置/片段 + 问题类型 + 风险说明 + 建议）。
- **不得遗漏检查项**：下方清单每一条都必须被逐项对照检查（适用则检查，不适用则说明不适用）。

# 检查清单（逐条必须检查）

必须检查是否存在下列问题：边界、语法错误、全局污染，重构出错，留着调试代码，无意覆盖，场景不全，内存泄漏。
## 调试代码
- **必须去掉 console.log**：禁止提交调试 `console.log`。其他console忽略，例如console.error,这不是调试代码
- **禁止临时 try-catch**：仅包含 `console.log` 的 try-catch 视为调试残留，必须指出。因为这个就是调试代码的一种
## 捕获错误
- **await 必须 try-catch**：所有 `await` 调用必须有 `try/catch` 或等价错误处理，禁止未捕获异常。
- 不需要trycatch的场景
    - 组件库validate不需要trycatch，原因是在dom有红色字体显示

## 其他

- **必须判空**：小程序 rect、DOM 相关、API 下发字段等必须做存在性判断，禁止空引用。
- **禁止字符/模板拼接错误**：例如多写 `}`：`xxx?a=b&c=d${hhh}}`。
- **Vue scoped 必须加**：`scoped` 没加会导致全局样式污染（如项目包含 Vue 场景，必须检查）。

- **必须去掉视图中的调试代码**：例如 `<div>hhh</div>` 这类明显调试节点；而 `<div>剧目名称</div>` -> `<div>剧目英语名称</div>` 更像文案修改，只需检查其是否为调试残留。
- **必须检查消息文本调试标识**：如 `'保存成功1'`、`'操作完成2'`、`'测试'`、`'debug'`、`'temp'` 等，禁止上线残留。
- **必须检查变量名调试标识**：如 `testVar`、`debugFlag`、`tempData` 等，禁止残留。
- **必须检查硬编码测试数据**：如 `id: 123`、`name: 'test'`、`url: 'http://test.com'` 等，禁止残留。
- **必须检查未使用的 import 或变量**：禁止引入未使用依赖/变量。
- **必须检查魔法数字或硬编码字符串**：如影响可维护性或业务含义不清，必须标注风险并建议抽常量。
- **必须检查 API 是否使用测试环境 URL**：禁止将测试环境地址带入生产代码。

- **禁止临时 return**：如 `return true/false` 用于测试，必须指出并阻塞提交。
- **必须清理注释掉的临时代码块**：注释掉的代码块需检查是否为临时调试残留（并指出风险）。
- **必须检查展开覆盖风险**：`{...item,stock:1}` 需确认 `item` 是否已有 `stock` 字段，避免无意覆盖。
- **禁止 `res || 1` 误兜底**：本意是 1 兜底，但 `res` 为 0 会被强转 1，与期望不符，必须指出。
- **必须检查同步删除/引用一致性**：例如删除数组表单项但仍保留 `formRefs` 索引引用，会导致数据错乱。
- **公共代码必须确认适用范围**：公共模块改动必须确认是公共需求，而不是某子应用定制。
- **禁止用 `if ([])` 判断空**：`[]` 为 truthy，若预期为空必须检查 `length` 或更明确条件。
- **必须检查销毁清理**：销毁时 `removeEventListener`、`clearTimeout/clearInterval` 等必须清理，避免内存泄漏。
- **禁止跳转后仍 setState**：路由跳转/组件卸载后更新状态需避免。
- **必须去掉无用注释**：无意义/过时注释必须指出
- **TS 类型必须补全**：如改动涉及 TS，类型必须补全（无 TS 则忽略）。
- **必须检查其他潜在隐患**：由于修改导致的潜在问题、场景不全、边界遗漏等，必须指出。


# 输出要求（必须）

如果发现有问题，必须一一列出，并在结尾询问用户：**是否按清单直接修改，还是用户手动自行修改**。

业务梳理

这个是可以帮助你了解你到底做了什么，很多时候初级程序员开发完不知道自己做了什么业务，了解起来非常痛苦，那么这个技能会输出一篇你开发代码相关的业务逻辑，一看就非常了解

markdown 复制代码

---
name: generate-business-docs-from-code
description: 从代码或笔记中生成稳定的中文业务文档。适用于用户要求输出业务背景/核心功能模块/关键业务规则/快速记忆卡片/常见问题，或要求"小白都能看懂/不要代码/不要技术细节/不要涉及任何代码"。适配任意页面与任意领域，重点把页面展示、用户操作流程、业务规则翻译成业务语言。
---

# Generate Business Documentation from Code

## Purpose

把技术实现/接口/页面行为，转换成**任何"小白"都能看懂**的中文业务文档，用于：
- 新同学快速理解业务
- 给产品/运营/老板做业务说明

## When to Use

Apply this skill when:
- User asks to "理解这块业务" / "分析一下业务"
- Preparing for interviews about a project
- Creating documentation for non-technical audiences
- Documenting business logic for knowledge sharing

## Hard Requirements（必须遵守）

### 1) 只写中文、只讲业务
- 输出必须是**中文**。
- 禁止输出任何代码/伪代码/接口参数结构/函数名/类名/文件路径/技术栈名词堆砌。
- 可以提到"前端展示/后端存储/保存/校验/定时任务"这种**业务能理解**的表达，但不要写实现细节。

### 2) 面向小白：一句话 + 痛点 + 解决方案
- 每个模块先用**一句话**解释"它解决什么问题"。
- 解释"为什么要做"（痛点），再解释"怎么解决"（策略/配置/规则）。

### 3) 固定结构输出（稳定）
- 必须按下面模板输出，章节不缺失，除非用户明确说不需要某章。
- 每章尽量使用短句 + 列表 + 表格（业务表格即可）。

### 4) 错误与边界只用业务语言描述
- 例如"项目不存在/重复/超过数量/格式不合法/不支持某数据类型"等，用**提示语**描述，不要写错误码、异常栈。

## How to Extract Business Facts（从代码/页面提取信息的方法）

当允许阅读代码时，重点关注并提炼为业务语言：
- 页面上有哪些表单项/开关/下拉选择/按钮（对应业务配置）
- 用户操作路径（点击顺序、保存、失败提示）
- 校验规则（为什么要校验、校验失败会怎样）
- 关键枚举/状态（用中文讲清楚含义）
- "为什么这样设计"（例如策略衰减、占比限购、特殊模式）

## Output Template（必须使用）

> 输出用 markdown，但**不要包含任何代码块**（```）。

### 一、业务背景

一句话概括：用一句话说明"这是一个什么后台/工具，用来解决什么行业问题"。

业务痛点（按需选择，列 3-6 条）：
- 黄牛抢票
- 代拍业务


解决方案（讲清"可配置"与"组合策略"）：
- 说明有多少类策略（例如 20+ 种）以及"每个项目可独立启用"的特点
- 说明运营人员的工作方式：按项目特点组合配置

### 二、核心功能模块

用"模块一/模块二/模块三 ......"组织，每个模块都要包含：
- **模块定位**：一句话
- **配置项清单**：建议用表格

表格格式（示例）：
| 配置项 | 做什么 | 适用场景/备注 |
| --- | --- | --- |
| 风控禁购 | 高风险用户直接禁止购买 | 热门项目必开 |

### 三、关键业务规则

至少覆盖：
- **什么是策略衰减？为什么要做？**（用业务语言解释）
- **特殊模式差异（如 Uutix）**：它是什么、对配置有什么影响
- **校验规则的业务意义**：为什么要这些校验，防止什么风险
- **百分比显示/存储差异（如有）**：用"展示更直观/存储更精确"解释，不写计算细节

### 四、快速记忆卡片

用"概念 → 一句话"格式，列 6-12 条：
- 风控禁购：......


### 五、常见问题

至少给出 3-8 个 QA：
- Q：讲讲某模块的业务定位？
  - A：业务定位/核心功能/关键流程/亮点
- Q：有哪些关键业务规则？
  - A：按规则点列出，并解释"为什么"
- Q：为什么要做某个限制/校验？
  - A：对应行业痛点和风险

## Style Checklist（输出前自检）
- [ ] 是否全部中文
- [ ] 是否完全不含代码块与实现细节
- [ ] 是否每个模块都有"一句话定位 + 配置项表格"
- [ ] 是否解释了"为什么要做"（痛点/收益）
- [ ] 上下文是否存在重复，如果有重复从下面往上删（下面与上面重复保留下面，例如常见问题上面有提到，则在常见问题进行删除），保证内容唯一