研发必装的5个Claude Code Skill——装完直接起飞，不装继续搬砖

---
name: commit
description: 
  分析当前git暂存区的变更，生成符合Conventional Commits规范的
  提交信息。自动识别变更类型(feat/fix/refactor/docs/test)，
  提取影响范围，生成中英双语描述。
argument-hint: "[可选：补充说明本次变更的背景]"
allowed-tools: Bash(git:*)
---

## 任务

分析当前 git diff --cached 的内容，生成规范的commit message。

## 步骤

1. 执行 git diff --cached --stat 查看变更概览
2. 执行 git diff --cached 查看具体变更
3. 分析变更内容，判断类型：
   - feat: 新功能
   - fix: Bug修复
   - refactor: 重构（不影响功能）
   - docs: 文档变更
   - test: 测试相关
   - chore: 构建/工具变更

4. 生成commit message，格式：

---
name: review
description: 
  审查当前分支相对于主分支的所有代码变更，从安全性、
  性能、代码质量三个维度输出结构化审查报告，标注
  严重等级(P0-P3)和具体修复建议。
allowed-tools: Bash(git:*), Read, Grep, Glob
---

## 任务

对当前分支的代码变更做全面审查。

## 步骤

1. 执行 git diff main...HEAD 获取所有变更
2. 逐文件分析，按三个维度审查：

### 维度一：安全性（权重最高）
- SQL注入、XSS、命令注入
- 硬编码的密钥/密码/Token
- 不安全的反序列化
- 路径遍历风险

### 维度二：性能
- N+1查询
- 缺少索引的数据库查询
- 内存泄漏风险（未关闭的连接/流）
- 不必要的循环内I/O操作

### 维度三：代码质量
- 重复代码（DRY违反）
- 函数过长（>50行警告）
- 魔法数字/硬编码配置
- 缺少错误处理

3. 输出格式：

**🔴 P0 — 必须修复（阻塞合并）**
- [文件:行号] 问题描述 → 修复建议

**🟡 P1 — 建议修复**
- [文件:行号] 问题描述 → 修复建议

**🟢 P2 — 可以改进**
- [文件:行号] 问题描述 → 修复建议

**💡 P3 — 锦上添花**
- [文件:行号] 问题描述 → 修复建议

## 注意
- P0问题必须给出可直接使用的修复代码
- 如果没有发现P0问题，明确说明"无阻塞性问题"
- 不要为了凑数量而列出无关紧要的问题

---
name: security
description: >
  全面扫描项目的安全风险：硬编码密钥、依赖漏洞、
  OWASP Top 10代码模式、不安全的配置文件。输出
  按严重等级排序的安全报告。
allowed-tools: Read, Grep, Glob, Bash(npm:audit*, pip:audit*, grep:*)
---

## 任务

全面审计项目安全风险。

## 扫描项目

### 1. 硬编码密钥扫描
搜索以下模式：
- API Key / Secret / Token / Password 的赋值语句
- AWS_ACCESS_KEY、GITHUB_TOKEN等环境变量的硬编码
- .env文件是否被加入版本控制（检查.gitignore）
- 私钥文件（*.pem, *.key）是否在仓库中

### 2. 依赖漏洞检查
- Node.js：npm audit --json
- Python：pip audit --format json（如果安装了pip-audit）
- 检查是否有已知CVE的依赖版本
- 检查是否有超过2年未更新的依赖

### 3. OWASP Top 10 代码模式
- SQL拼接（非参数化查询）
- eval()、exec()、newFunction()使用
- 未转义的用户输入直接渲染（XSS）
- 不安全的文件操作（路径遍历）
- 弱加密算法（MD5/SHA1用于密码哈希）
- 不安全的随机数（Math.random用于安全场景）

### 4. 配置文件检查
- CORS是否设为 *
- debug模式是否在生产配置中开启
- 数据库连接是否使用SSL
- JWT密钥是否硬编码

## 输出格式

**🔴 严重（立即修复）** — 密钥泄露、已知高危CVE
**🟡 高危（本周修复）** — SQL注入、XSS、弱加密
**🔵 中危（下个迭代修复）** — 过时依赖、配置不当
**⚪ 低危（有空再说）** — 代码风格安全建议

每个问题附带：文件位置、风险说明、修复方案代码

---
name: test-gen
description: 
  为指定的函数或文件自动生成单元测试。分析函数签名、
  业务逻辑和边界条件，生成覆盖正常路径、异常路径和
  边界情况的测试用例。支持Jest/Mocha/Pytest/JUnit。
argument-hint: "<文件路径或函数名>"
allowed-tools: Read, Grep, Glob, Write, Bash(node:--test*, npx:jest*, python:-m pytest*)
---

## 任务

为 $ARGUMENTS 指定的代码生成单元测试。

## 步骤

1. 读取目标代码，分析：
   - 函数签名（参数类型、返回类型）
   - 内部分支逻辑（if/else/switch/三元表达式）
   - 可能抛出的异常
   - 外部依赖（需要mock的部分）

2. 识别测试框架：
   - 检查package.json中的devDependencies
   - 检查现有测试文件的import语句
   - 如果没有测试框架，推荐node:test（Node.js）或pytest（Python）

3. 生成测试用例，必须覆盖：
   - ✅ 正常路径（至少2个不同输入）
   - ❌ 异常路径（null、undefined、空字符串、错误类型）
   - 🔲 边界条件（空数组、超长字符串、整数MAX/MIN、零值）
   - 🔄 异步场景（如果函数是async的）

4. 将测试文件写入对应的test/目录
5. 运行测试，确保全部通过
6. 如果有失败的用例，分析原因并修复

## 注意
- 测试文件命名跟随项目现有约定（*.test.js或*.spec.js）
- mock要最小化——能不mock就不mock
- 每个测试用例的描述要说明"测的是什么场景"

---
name: explain
description: 
  深度解读指定代码的设计意图、执行流程和隐含假设。
  结合git blame追溯变更历史，分析为什么代码会写成
  这样。输出架构图和流程图（Mermaid格式）。
argument-hint: "<文件路径[:行号范围]>"
allowed-tools: Read, Grep, Glob, Bash(git:blame*, git:log*)
---

## 任务

深度解读 $ARGUMENTS 指定的代码。

## 步骤

1. 读取目标代码
2. git blame 查看每行的作者和提交时间
3. git log --follow 追溯文件的变更历史
4. 分析代码的上下游调用关系（谁调了它、它调了谁）
5. 生成解读报告：

### 📋 一句话概括
- 这段代码的职责是什么

### 🔄 执行流程

### 🏗️ 在系统中的位置
- 上游：谁调用了这段代码
- 下游：这段代码调用了什么
- 数据流：输入是什么、输出是什么

### 🧠 设计意图
- 为什么选择这种实现方式（而不是更"显而易见"的方式）
- 隐含的假设和前提条件
- 历史上经历过哪些重大修改，以及修改的原因

### ⚠️ 改动须知
- 容易踩的坑
- 修改时需要同步变更的地方
- 哪些"看起来多余"的代码其实是在处理边界情况

## 注意
- 不要只做代码到自然语言的翻译，要分析"为什么"
- 如果git历史中有相关的PR描述或Issue链接，一并引用
- 对于看起来"奇怪"的写法，优先从git log中找原因

# 个人级（推荐，所有项目都能用）
mkdir -p ~/.claude/skills/commit
mkdir -p ~/.claude/skills/review
mkdir -p ~/.claude/skills/security
mkdir -p ~/.claude/skills/test-gen
mkdir -p ~/.claude/skills/explain

# 例如
vim ~/.claude/skills/commit/SKILL.md
# 粘贴commit Skill的内容，保存