自己留用搜罗出来的skill。---name: security-auditdescription: 扫描代码中是否存在明显的安全风险与敏感信息泄露包括硬编码密钥、不安全的 SQL/命令拼接等---# 安全与敏感信息扫描## 扫描范围- 是否存在硬编码的密钥、密码、Token、AK/SK- 是否存在 SQL/命令拼接拼接字符串而非参数化查询- 是否存在默认账号密码、测试账号残留- 是否存在敏感日志输出如打印身份证号、银行卡号## 输出格式- 对每个问题按「风险等级高/中/低」标注- 指出具体文件和行号- 给出修复建议如移至环境变量、使用参数化查询、脱敏日志## 注意事项- 误报难免请对每条进行人工确认- 不要对已经明确标注为「测试/示例」的代码做过于严格的要求但仍需提醒---name: java-spring-boot-expertdescription: 在创建或修改 Spring Boot 项目代码时按团队约定的分层结构、异常处理、日志规范进行开发。---# Java Spring Boot 开发规范## 分层结构- Controller 层只做参数校验、调用 Service、返回 DTO- Service 层业务逻辑事务边界- Repository/Mapper 层数据库访问- 禁止跨层直接访问如 Controller 直接调 Repository## 命名规范- 类名使用 PascalCase如 UserService- 方法名使用 camelCase如 getUserById- 常量全大写下划线分隔如 MAX_RETRY_COUNT## 异常处理- 不在代码中吞掉异常- 使用统一的业务异常类型如 BusinessException- 在 Controller 层统一异常处理与错误响应格式## 日志规范- 关键业务入口、出口必须记录日志INFO- 异常情况必须记录异常堆栈ERROR- 日志中避免输出敏感信息## 步骤1. 分析新增/修改涉及的类和接口2. 确保分层正确、调用路径清晰3. 检查异常处理是否符合统一规范4. 补齐必要的日志记录---name: chinese-comment-styledescription: 强制所有生成/修改的 Python 代码必须使用中文注释并在每个函数上方添加中文功能说明。---# 代码注释规范中文## 注释语言- 所有 Python 代码的注释必须使用中文## 函数级注释- 每个函数上方必须有中文说明- 函数是做什么的- 参数含义和类型- 返回值含义## 行内注释- 对复杂逻辑行在右侧或上方添加中文解释说明「为什么」而不是「做了什么」## 检查步骤1. 扫描所有函数定义2. 确认是否存在中文注释3. 如缺失自动补齐4. 确保注释语言为中文---name: doc-writerdescription: 根据当前项目或选中文件生成/更新 README 或技术文档包含项目简介、快速开始、结构说明、示例代码等。---# 技术文档 / README 生成器## 文档结构- 项目简介1~2 段话- 主要功能列表- 技术栈语言、框架、关键依赖- 快速开始安装、运行、验证- 目录结构说明- 使用示例可包含代码片段- 常见问题可选## 信息来源- 优先从 package.json / pom.xml / requirements.txt 提取依赖- 从项目主要入口文件提取关键 API 和使用方式- 如已有 README则在原有基础上增量更新不覆盖已有手动内容## 输出方式- 默认输出为 Markdown- 如目标文件存在采用「更新模式」新增段落前给出对比摘要- 如涉及变更多个文件先用列表说明将要修改的文件清单---name: unit-test-generatordescription: 根据选中的函数或类自动生成完整、可运行的单元测试用例覆盖正常、边界和异常情况。---# 单元测试生成器## 测试框架选择- 默认使用项目现有测试框架如Jest、Vitest、JUnit、PyTest- 如果检测不到先询问用户确认框架## 覆盖策略对每个函数/方法- 至少 1 条正常路径用例- 至少 2 条边界/异常情况用例- 如有分支逻辑每条分支至少一个用例## 输出格式- 按文件组织测试代码与源码目录结构保持一致- 为每个测试用例添加简短中文注释说明测试意图- 如涉及 Mock使用项目已有的 Mock 库和风格## 步骤1. 读取目标函数/类及其依赖2. 列出关键路径和可能的异常3. 生成测试代码4. 标注哪些用例需要用户补充业务数据---name: frontend-vue-style-guidedescription: 当为 Vue 项目编写或修改组件时自动按照团队约定规范进行代码风格与结构约束。---# 前端 Vue 项目编码规范## 文件命名- 组件文件使用 PascalCase如UserProfile.vue- 工具函数文件使用 kebab-case如user-utils.ts## 组件结构- 单文件组件必须包含三个块template、script、style- 在 script 中使用 Composition API 时统一将 setup 写法写在 script setup 中## CSS 类命名- 使用 kebab-case如user-profile、btn-primary- 避免用标签名作为类名## 注释要求- 对复杂业务逻辑添加中文注释说明「为什么这么做」- 公共组件必须在其文件顶部添加用途说明注释## 代码检查步骤1. 检查文件命名是否符合上述规则2. 检查组件结构是否完整3. 检查类名和函数名是否符合命名约定4. 检查是否为复杂逻辑添加了必要的注释5. 如不符合指出具体位置并给出修改建议---name: code-reviewerdescription: 用于对代码进行系统化审查和重构建议检查安全性、可读性、性能、是否遵循团队规范并给出可执行的修改方案。---# 代码审查与重构专家## 审查范围- 逻辑正确性- 潜在安全风险SQL 注入、XSS、敏感信息泄露等- 可读性与命名规范- 性能瓶颈N1 查询、大循环中的重操作- 异常处理与边界条件## 输出要求- 先用 3~5 条「要点」列出问题按优先级排序- 对每个问题- 说明风险/影响- 给出修改后的代码片段或重构建议- 如涉及团队规范如命名风格引用对应的规范条目## 注意事项- 优先修复安全与正确性问题- 不要做过度优化只点出真正影响性能的瓶颈- 尽量保持原有接口签名避免破坏调用方