laolaoshiren/claude-code-skills-zh

# API 测试助手

## 核心原则

- 只把可核验的 OpenAPI、代码、类型、调用方或现有测试当作契约证据。
- 生成测试不等于执行测试；读取接口定义不等于可以访问真实服务。
- 保护现有数据、凭据和用户修改，优先使用隔离且可清理的测试环境。

## 工作流程

### 1. 读取项目与接口证据

先读取适用的仓库规则、测试说明、Git 状态和项目脚本，再按实际存在情况检查：

# Changelog 自动生成

## 触发条件
当用户要求生成 changelog、更新日志、版本记录、release notes 时激活此技能。

## 工作流程

### 第 1 步：获取 Git 历史
```bash
# 先获取最近的 tag，再用 revision range 查询
git describe --tags --abbrev=0
git log --oneline <last-tag>..HEAD

# 或指定范围

# 数据库迁移助手

## 触发条件
当用户要求数据库迁移、生成 migration、schema 变更、数据库升级时激活此技能。

## 工作流程

### 第 1 步：识别框架
扫描项目文件，判断使用的 ORM/迁移框架：
- `alembic.ini` / `alembic/` → Alembic
- `prisma/schema.prisma` → Prisma
- `pom.xml` 含 flyway → Flyway
- `manage.py` + `settings.py` → Django
- `Gemfile` + `db/migrate/` → Rails

# 依赖安全审计

## 核心原则

- 默认只读。用户只要求“检查、审计、报告”时，不修改 manifest、lockfile、源码、CI 或外部服务。
- 以实际解析版本和可追溯 advisory 为证据。不要凭包名、版本年龄或记忆猜测 CVE、修复版本、可达性与许可证。
- 优先使用项目锁定的包管理器和已有审计命令。不要为完成审计而裸跑 `npx`，也不要擅自执行 `pip install`、`go install`、`cargo install` 等下载命令。
- 把“发现问题”“建议修复”“执行修改”分开。任何会改依赖或 lockfile 的动作都需要用户明确授权。
- 许可证部分只陈述事实、适用场景和待确认事项，不作法律结论。

## 工作流程

### 1. 确认范围与授权

# 项目目录结构地图（Directory Structure Mapper）

## 触发条件
当用户说「带我看看项目结构」「这个仓库怎么组织的」「目录树」「帮我理解这个代码库」或类似需求时激活此技能。

## 工作流程

1. **扫描根目录** — 使用 Bash `find` 和 `ls` 获取顶层结构
2. **分析关键目录** — 读取关键文件（package.json, Cargo.toml, pyproject.toml, go.mod 等）获取项目元信息
3. **递归扫描** — 深入扫描主要目录，理解各模块职责
4. **生成结构图** — 输出 ASCII 目录树 + 中文注释说明

## 输出格式

# 环境变量管理器

## 触发条件
当用户要求管理环境变量、.env 文件、配置同步、Secrets 检查时激活。

## 工作流程

### 1. 扫描项目
- 检测所有 `.env*` 文件（.env / .env.local / .env.development / .env.production）
- 默认只提取变量名、来源文件和是否为空；真实值必须脱敏，不写入报告或终端输出
- 扫描代码中引用的环境变量（`process.env.XXX` / `os.environ['XXX']` / `os.getenv('XXX')`）
- 识别静态扫描中未发现引用的变量（仅作为待人工确认候选）
- 识别已使用但未定义的变量（缺失配置）

# 错误消息翻译专家

## 触发条件
当用户粘贴或遇到编程错误消息（英文），需要翻译和解释时激活此技能。

## 工作流程

1. **识别错误类型**
   - 确定编程语言和运行环境（Python/Java/JavaScript/Go/Rust/C/C++ 等）
   - 判断错误类型：语法错误、运行时错误、编译错误、框架错误、系统错误

2. **翻译错误消息**
   - 将英文错误消息准确翻译为中文
   - 保留关键的技术术语（类名、函数名、文件路径）

# ESLint 修复助手

## 工作流程

### 1. 识别项目工具链

读取：

- `package.json` 中的 scripts、`devDependencies` 和 `packageManager`。
- npm、pnpm、Yarn 或 Bun 的 lockfile。
- `eslint.config.*`、`.eslintrc.*`、`.eslintignore`、Prettier 和 TypeScript 配置。
- 适用的仓库规则、Git 状态和用户指定的文件范围。

优先运行仓库已有的 lint script。只有确认 ESLint 已被当前项目锁定并安装时，才使用对应包管理器的本地执行方式。若缺失依赖，先报告；安装包、更新 lockfile 或迁移配置需要单独授权。

# Git 工作流助手

## 核心原则

- 只执行用户明确要求的 Git 动作。生成提交信息不等于暂存或提交；提交不等于推送；创建 PR 不等于合并 PR、关闭 Issue 或发布 Release。
- 把工作树中已有、未跟踪和无关的修改视为用户资产，不覆盖、不回退、不混入本轮提交。
- 优先使用非交互命令。涉及历史重写、冲突选择或远程覆盖时降低自动化程度。

## 工作流程

### 1. 读取仓库规则与状态

先阅读适用的 `AGENTS.md`、`CONTRIBUTING.md`、README、提交规范和 CI 说明，再检查：

# GitHub Actions CI/CD 生成器

## 核心原则

- 先读项目，再生成 workflow。不要凭项目名猜测运行时、包管理器、测试命令或部署目标。
- 默认只生成只读 CI。Release、部署、推送镜像、写回仓库和调用外部 webhook 必须先确认目标、凭据、环境保护与回滚方式。
- 将不可信 PR 代码与 Secrets、写权限、自托管 Runner 隔离。不要为方便而改用 `pull_request_target` 执行 PR 代码。
- 把所有 Action 固定到核验过的完整 40 位 commit SHA，并在旁边保留版本注释。不要使用 `@main`、`@master`、`@latest` 或可移动的 `@vN` tag。
- 为每个 job 设置最小 `permissions` 和 `timeout-minutes`；不依赖仓库默认权限。
- 生成后运行真实语法与项目命令验证，不把“配置看起来正确”当作通过。

## 工作流程

### 1. 盘点项目证据

# 🌍 i18n-helper — 国际化/本地化助手

## 触发条件
当用户要求以下操作时激活此技能：
- 扫描代码中的硬编码中文/英文文本
- 为项目添加国际化支持（i18n）
- 批量提取和翻译语言文件
- 检查翻译完整性（缺失 key 检测）

## 工作流程

### 1. 项目分析
- 检测项目类型（React/Vue/Angular/Node.js/Python/Java 等）
- 识别已使用的 i18n 框架（react-intl, vue-i18n, i18next, gettext 等）

# 📋 log-analyzer — 日志分析助手

## 触发条件
当用户要求以下操作时激活此技能：
- 分析应用日志文件（.log, .txt, journalctl 输出等）
- 排查线上问题和异常
- 从日志中提取统计信息
- 生成日志分析报告

## 工作流程

### 1. 日志格式识别
自动检测日志格式：
- **结构化**: JSON logs, Logfmt

# 性能分析助手

## 工作流程

### 1. 明确目标与边界

先确认或从项目中核实：

- 目标指标，如延迟、吞吐量、CPU、内存、查询次数或包体积。
- 可复现的场景、数据规模、运行环境、版本和关键配置。
- 用户允许分析和修改的范围，以及是否可以运行负载或 profiler。

没有明确目标时，先用现有监控、benchmark 或用户现象缩小范围，不把“代码看起来慢”当成瓶颈结论。

# 代码重构顾问

## 触发条件
当用户要求重构代码、优化代码结构、改善代码质量、消除技术债务时激活此技能。

## 工作流程

### 第 1 步：扫描代码库
- 使用 `grep`/`rg` 扫描目标目录，识别潜在坏味道
- 统计文件行数、函数长度、参数数量等指标
- 查找重复代码块（相似度 > 80%）

### 第 2 步：分类坏味道
按严重程度分类发现的问题：

# 代码安全审计

## 触发条件
当用户要求安全检查、漏洞扫描、安全审计、依赖安全检查时激活此技能。

## 工作流程

1. **确定审计范围** — 根据用户指定的目录/文件/代码段进行分析
2. **静态安全扫描** — 按检查清单逐项排查
3. **依赖安全检查** — 检查 package.json / requirements.txt / go.mod 等依赖文件
4. **生成审计报告** — 按严重程度分类输出

## 检查清单

# Skill 收录评估器

对候选资源进行证据驱动的核验。不要只根据仓库简介、搜索摘要或 Star 做决定。

## 工作流程

### 1. 规范化候选地址

- 接受 GitHub 仓库、仓库子目录、PR、Issue 或用户提供的项目名。
- 从 `tree/`、`blob/` 等子路径提取 `owner/repo`，同时保留指向独立 Skill 的原始子路径。
- 在当前精选列表中搜索仓库名、规范化 URL 和旧名称，判断是新增、重复还是已有条目更新。
- 遇到仓库重命名或转移时，使用最终规范地址，避免继续收录重定向 URL。

```bash

# 测试生成器

## 工作流程

### 1. 读取真实契约

检查目标代码及其：

- 类型定义、公开文档、调用方和错误处理路径。
- 现有测试、fixture、测试配置、依赖清单和项目测试命令。
- 输入输出、副作用、状态变化、并发语义和系统边界。
- 适用的仓库规则、Git 状态及本轮允许修改的范围。

区分“代码当前行为”和“产品期望行为”。两者冲突或契约不明确且会改变断言时，先列出证据与待确认假设；不要用测试固化猜测。

# 中文代码审查专家

## 触发条件
当用户要求审查代码、code review、代码检查、代码质量评估时激活此技能。

## 工作流程

1. **读取目标文件** — 使用 Glob 和 Read 工具获取要审查的代码
2. **分析代码质量** — 从以下维度评估：
   - 代码规范（命名、格式、注释）
   - 潜在 Bug（空指针、越界、并发问题）
   - 性能问题（N+1 查询、内存泄漏、不必要的循环）
   - 安全漏洞（SQL 注入、XSS、硬编码密钥）
   - 设计模式（是否合理使用、是否有更好的方案）

# 中文文档生成器

## 触发条件
当用户要求生成文档、写技术文档、生成 API 文档、项目说明时激活此技能。

## 工作流程

1. **扫描项目结构** — 识别项目类型（Web 应用/CLI 工具/库/服务）
2. **分析代码** — 提取模块、函数、类、接口的签名和注释
3. **生成文档** — 输出以下文档：

### 生成内容
- **项目概述** — 中文简介、技术栈、架构图（Mermaid）
- **快速开始** — 安装、配置、运行步骤

# 中文 README 生成器

## 触发条件
当用户要求写 README、重写项目介绍、补全文档首页、优化开源仓库展示页时激活此技能。

## 核心原则
1. 先读代码和目录，再写 README；不要只凭项目名猜功能。
2. 面向中文开发者表达，技术名词保留英文，解释用自然中文。
3. 首页要解决三个问题：这是什么、为什么值得用、怎么快速上手。
4. 优先给出真实命令、真实路径、真实示例，少写空泛宣传语。
5. 如果项目已有 README，先保留有效信息，再补全缺失结构。
6. 如果项目包含官网或文档站，README 中必须给出统一、可点击的正式入口链接，避免 README / 官网 / Issue 模板地址不一致。
7. 项目介绍页要尽量补上社交证明信号（如 Star、精选数量、更新时间、代表性场景），帮助访客快速判断是否值得继续浏览。
8. README 首屏必须具备“30 秒价值判断”能力：首句价值主张 + 适合谁用 + 最短安装方式，缺一不可。