运维与部署类 Skills

部署操作是团队中最需要标准化流程的场景——每次部署都应该过同样的检查清单，不因操作者不同而有遗漏。这一节提供两个直接可用的运维 Skill：部署前检查和数据库迁移安全验证。

Skill 3：/pre-deploy — 部署前自动化检查

场景：在触发部署流水线之前，运行一套标准化的检查清单，确保代码处于可部署状态。

文件：.claude/skills/ops/pre-deploy.md

---
description: 部署前自动化检查清单，检查代码、测试、配置的就绪状态
allowed-tools: Bash, Read, Glob
---
# 部署前检查
## 目标
在部署到指定环境前，运行标准化检查清单。
production 环境检查更严格，staging 检查较宽松（警告不阻断）。
## 参数说明（来自 $ARGUMENTS）
| 参数 | 必填 | 默认值 | 说明 |
|------|------|--------|------|
| `--env` | 是 | — | 目标环境：`staging` / `production` |
| `--skip-tests` | 否 | false | 跳过测试检查（仅 staging 允许）|
| `--service` | 否 | 全部 | 服务名（多服务仓库中指定单个服务）|
**调用示例**：

/pre-deploy --env staging /pre-deploy --env production /pre-deploy --env staging --skip-tests

## 执行步骤
### 阶段 0：参数验证（失败则立即终止）
1. 验证 `--env` 已提供且值为 `staging` 或 `production`。
2. 如果 `--env` 为 `production` 且提供了 `--skip-tests`：
终止，提示"production 环境不允许跳过测试"。
3. 如果 `--env` 为 `production`，输出：
```
⚠️ 正在执行 PRODUCTION 环境部署检查
所有检查项将以严格模式运行（警告也视为阻断）
```
### 阶段 1：代码状态检查
4. `git status --porcelain`：
- 有未提交修改：staging → 警告；production → 终止
5. `git log --oneline -1`：记录当前 HEAD commit
6. `git branch --show-current`：确认在正确的部署分支
- 如果不在 main/master/release-* 上：staging → 警告；production → 终止
### 阶段 2：测试检查
7. 如果未跳过测试：
- 运行 `npm test -- --passWithNoTests 2>&1 | tail -20`
- 检查最后几行是否包含 "Tests: N passed" 或 "Test Suites: N passed"
- 如有失败：staging → 警告；production → 终止
### 阶段 3：依赖和安全检查
8. 运行 `npm audit --json 2>&1 | head -100`
- 提取 critical 漏洞数量
- critical > 0：两个环境都终止（严重安全漏洞不允许部署）
- high > 0：staging → 警告；production → 警告（记录但不阻断）
9. 检查 `node_modules` 是否有锁文件一致性问题：
- 如果 `package-lock.json` 存在，运行 `npm ci --dry-run 2>&1`
- 如果报错：警告（可能有人手动修改了 package.json 但没有更新 lock 文件）
### 阶段 4：配置检查
10. 查找 `.env.{env}` 或 `config/{env}.yml` 配置文件（使用 Glob 工具）
11. 读取文件内容，检查是否有：
- 未替换的占位符（如 `${VAR_NAME}` 或 `TODO` 或 `CHANGE_ME`）
- 空值（key= 后面没有值）
- 注意：不要输出实际的配置值（可能含密钥）
### 阶段 5：输出报告
## 输出格式

部署前检查报告

目标环境：{env} 检查时间：[时间] 当前版本：[commit hash] — [commit message]

检查结果

结论

[✅ 所有检查通过，可以部署到 {env}] 或 [⚠️ 发现 N 个警告，建议确认后再部署] 或 [❌ 发现 N 个阻断问题，不建议部署。请修复后重新运行检查。]

运行 /pre-deploy --env {env} 重新检查

Skill 4：/check-migration — 数据库迁移安全检查

场景：在执行数据库迁移之前，分析迁移脚本的风险，发现潜在的数据丢失或锁表问题。

文件：.claude/skills/ops/check-migration.md

---
description: 分析数据库迁移脚本的安全风险，检测数据丢失和不可逆操作
allowed-tools: Bash, Read, Glob
---
# 数据库迁移安全检查
## 目标
在运行数据库迁移前，分析迁移脚本的安全性，
识别高风险操作（数据丢失、长时间锁表、不可回滚操作）。
## 参数说明（来自 $ARGUMENTS）
| 参数 | 必填 | 默认值 | 说明 |
|------|------|--------|------|
| `--migration` | 否 | 最新未执行的迁移 | 要检查的迁移文件名（不带路径）|
| `--env` | 是 | — | 目标环境：`staging` / `production` |
| `--dir` | 否 | `db/migrations` | 迁移文件所在目录 |
**调用示例**：

/check-migration --env staging /check-migration --env production --migration 20240315_add_payment_index.sql /check-migration --env staging --dir database/migrations

## 执行步骤
### 步骤 1：参数验证
1. 验证 `--env` 必须提供。
2. 如果提供了 `--migration`，在 `{dir}` 目录下验证文件存在：
- 如果不存在，列出目录中的最新 5 个迁移文件，提示用户确认文件名
### 步骤 2：确定要检查的迁移文件
3. 如果未提供 `--migration`：
- 用 Glob 工具找到 `{dir}/*.sql`（或 `*.rb`/`*.py`）文件
- 如果有 migration 状态追踪（如 `schema_migrations` 表记录），提示用户通过 `--migration` 明确指定
- 否则，取文件名排序最后（最新）的文件
4. 使用 Read 工具读取迁移文件内容
### 步骤 3：风险分析
对迁移文件内容进行以下安全检查：
**🔴 严重风险（production 环境会阻断）**：
- `DROP TABLE`、`DROP DATABASE`、`DROP SCHEMA`
- `TRUNCATE TABLE`
- `DELETE FROM ... `（不带 WHERE 子句）
- `UPDATE ... SET ...`（不带 WHERE 子句，可能影响全表）
**🟠 高风险（需要确认）**：
- `ALTER TABLE ... DROP COLUMN`（不可逆数据丢失）
- `ALTER TABLE ... ADD COLUMN ... NOT NULL` 且没有 `DEFAULT`
（在有数据的表上会失败）
- `CREATE INDEX`（大表上可能锁表；建议 `CONCURRENTLY`）
- `ALTER TABLE ... RENAME`（需要确认下游代码已同步修改）
**🟡 注意项**：
- 迁移文件是否同时有对应的 rollback/down 函数？
如果没有，标注"此迁移不可回滚"
- 是否有外键约束变更？（可能影响数据完整性）
### 步骤 4：评估数据规模影响
5. 尝试运行（如果数据库可达）：
```sql
-- 仅作为建议，不实际运行
```
实际上，提示用户在执行迁移前检查目标表的数据量：
```
建议运行：SELECT COUNT(*) FROM {affected_table};
以评估迁移影响的数据行数。
```
### 步骤 5：生成报告
## 输出格式

数据库迁移安全检查报告

迁移文件：{filename} 目标环境：{env} 检查时间：[时间]

风险分析

回滚能力

[✅ 迁移有 down/rollback 函数] 或 [⚠️ 未找到 rollback 函数，此迁移不可自动回滚]

执行建议

[根据风险等级输出建议]

运行前建议： 1. 在 staging 环境先验证 2. 确认已备份受影响的表 3. 在低流量时段执行（如有锁表风险）

本节记录清单

• [ ] 复制 /pre-deploy Skill 并根据项目测试命令（npm/pytest/go test）调整步骤 7
• [ ] 复制 /check-migration Skill 并根据迁移文件格式（.sql/.rb/.py）调整步骤 3
• [ ] 测试 /pre-deploy --env staging 在你的项目上的输出
• [ ] 测试 /check-migration --env staging 并验证风险识别准确性

下一节：日志分析与项目管理类 Skills——日志摘要、工作汇报、代码库导览——这些 Skills 提升日常工程效率。