自己留用，搜罗出来的skill。
---
name: security-audit
description: 扫描代码中是否存在明显的安全风险与敏感信息泄露，包括硬编码密钥、不安全的 SQL/命令拼接等
---
# 安全与敏感信息扫描
## 扫描范围
- 是否存在硬编码的密钥、密码、Token、AK/SK
- 是否存在 SQL/命令拼接（拼接字符串而非参数化查询）
- 是否存在默认账号密码、测试账号残留
- 是否存在敏感日志输出（如打印身份证号、银行卡号）
## 输出格式
- 对每个问题，按「风险等级（高/中/低）」标注
- 指出具体文件和行号
- 给出修复建议（如移至环境变量、使用参数化查询、脱敏日志）
## 注意事项
- 误报难免，请对每条进行人工确认
- 不要对已经明确标注为「测试/示例」的代码做过于严格的要求，但仍需提醒
---
name: java-spring-boot-expert
description: 在创建或修改 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-style
description: 强制所有生成/修改的 Python 代码必须使用中文注释，并在每个函数上方添加中文功能说明。
---
# 代码注释规范（中文）
## 注释语言
- 所有 Python 代码的注释必须使用中文
## 函数级注释
- 每个函数上方必须有中文说明：
- 函数是做什么的
- 参数含义和类型
- 返回值含义
## 行内注释
- 对复杂逻辑行，在右侧或上方添加中文解释，说明「为什么」而不是「做了什么」
## 检查步骤
1. 扫描所有函数定义
2. 确认是否存在中文注释
3. 如缺失，自动补齐
4. 确保注释语言为中文
---
name: doc-writer
description: 根据当前项目或选中文件生成/更新 README 或技术文档，包含项目简介、快速开始、结构说明、示例代码等。
---
# 技术文档 / README 生成器
## 文档结构
- 项目简介（1~2 段话）
- 主要功能列表
- 技术栈（语言、框架、关键依赖）
- 快速开始（安装、运行、验证）
- 目录结构说明
- 使用示例（可包含代码片段）
- 常见问题（可选）
## 信息来源
- 优先从 package.json / pom.xml / requirements.txt 提取依赖
- 从项目主要入口文件提取关键 API 和使用方式
- 如已有 README，则在原有基础上增量更新，不覆盖已有手动内容
## 输出方式
- 默认输出为 Markdown
- 如目标文件存在，采用「更新模式」：新增段落前给出对比摘要
- 如涉及变更多个文件，先用列表说明将要修改的文件清单
---
name: unit-test-generator
description: 根据选中的函数或类，自动生成完整、可运行的单元测试用例，覆盖正常、边界和异常情况。
---
# 单元测试生成器
## 测试框架选择
- 默认使用项目现有测试框架（如：Jest、Vitest、JUnit、PyTest）
- 如果检测不到，先询问用户确认框架
## 覆盖策略
对每个函数/方法：
- 至少 1 条正常路径用例
- 至少 2 条边界/异常情况用例
- 如有分支逻辑，每条分支至少一个用例
## 输出格式
- 按文件组织测试代码，与源码目录结构保持一致
- 为每个测试用例添加简短中文注释说明测试意图
- 如涉及 Mock，使用项目已有的 Mock 库和风格
## 步骤
1. 读取目标函数/类及其依赖
2. 列出关键路径和可能的异常
3. 生成测试代码
4. 标注哪些用例需要用户补充业务数据
---
name: frontend-vue-style-guide
description: 当为 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-reviewer
description: 用于对代码进行系统化审查和重构建议：检查安全性、可读性、性能、是否遵循团队规范，并给出可执行的修改方案。
---
# 代码审查与重构专家
## 审查范围
- 逻辑正确性
- 潜在安全风险（SQL 注入、XSS、敏感信息泄露等）
- 可读性与命名规范
- 性能瓶颈（N+1 查询、大循环中的重操作）
- 异常处理与边界条件
## 输出要求
- 先用 3~5 条「要点」列出问题（按优先级排序）
- 对每个问题：
- 说明风险/影响
- 给出修改后的代码片段或重构建议
- 如涉及团队规范（如命名风格），引用对应的规范条目
## 注意事项
- 优先修复安全与正确性问题
- 不要做过度优化，只点出真正影响性能的瓶颈
- 尽量保持原有接口签名，避免破坏调用方
)
