name: 安全审查 description: 深度安全分析委托给安全审查代理。检查认证、注入、秘密、依赖，并以严重性评级报告。 argument-hint: “[<文件或功能区域> | --diff [范围]]” allowed-tools: 读取, 搜索, 全局匹配, Bash, 任务, 团队创建, 团队删除, 发送消息, 询问用户问题 disable-model-invocation: true

安全审查 — 委托安全分析

生成一个 security-reviewer 代理来执行代码的深度安全分析。以严重性评级和文件:行证据报告发现。只读 — 不修改代码。

参数

<文件或功能区域> — 要审查的特定文件或区域（例如，src/auth/, api routes）
--diff [范围] — 审查最近的更改（默认：HEAD~1..HEAD）
无参数 — 审查所有未提交和暂存的更改

硬规则

只读：此技能不修改代码。它生成报告。
委托给代理：所有安全分析由 security-reviewer 代理执行。
需要证据：每个发现必须引用特定的文件和行号。

工作流程

步骤1: 确定范围

基于参数：

特定文件/区域：

通过 Glob 解析路径
将文件列表传递给审查者

--diff [范围]：

运行 git diff {range} --name-only 获取更改的文件
运行 git diff {range} 获取完整的差异
将两者传递给审查者

无参数：

检查未提交的更改：git diff --name-only 和 git diff --cached --name-only
如果没有更改：git diff HEAD~1..HEAD --name-only
将更改的文件传递给审查者

记录范围用于报告头。

步骤2: 创建团队并委托

TeamCreate(team_name: "security-review", description: "对 {scope description} 的安全分析")

生成 security-reviewer 代理，任务描述：

要审查的文件（完整路径）
差异输出（如果适用）
用户请求中的任何特定关注点

等待代理完成审查并生成结构化报告。

步骤3: 依赖审计

与代理审查并行运行生态系统特定的审计：

# JavaScript/TypeScript
if [[ -f "package.json" ]]; then
  bun audit 2>/dev/null || npm audit 2>/dev/null || echo "SKIP: 无审计工具可用"
fi

# Python
if [[ -f "requirements.txt" ]] || [[ -f "pyproject.toml" ]]; then
  pip audit 2>/dev/null || echo "SKIP: pip-audit 未安装"
fi

# Go
if [[ -f "go.mod" ]]; then
  govulncheck ./... 2>/dev/null || echo "SKIP: govulncheck 未安装"
fi

# 其他生态系统
echo "SKIP: 未检测到支持的审计工具"

步骤4: 合成报告

将代理的发现与依赖审计结果结合成统一报告：

## 安全审查报告

**范围**: `{scope description}`
**审查日期**: {当前日期}

---

### 结论: 安全 | 有隐患 | 危急

### 严重性摘要
- 危急: N
- 高: N
- 中: N
- 低: N

### 发现

#### [危急|高|中|低] 发现标题
- **文件**: `path/to/file.ts:42`
- **类别**: [认证|授权|注入|秘密|依赖|数据暴露|配置]
- **描述**: 漏洞是什么
- **影响**: 攻击者能做什么
- **建议**: 如何修复
- **证据**: 相关代码片段或模式

### 依赖审计
- 状态: [通过|有隐患|跳过]
- 细节: [审计输出摘要]

### 审查的文件
- `path/to/file.ts` — [摘要]

### 建议优先级
1. [先修复最危急的问题]
2. [下一个优先级]

步骤5: 清理

TeamDelete(reason: "安全审查完成")

团队删除清理：如果 TeamDelete 失败，回退到：rm -rf ~/.claude/teams/{team-name} ~/.claude/tasks/{team-name}

严重性定义

严重性	标准
危急	可被利用的漏洞，影响严重（远程代码执行、认证绕过、数据泄露）
高	显著漏洞，需要攻击者努力（存储XSS、有限范围的SQL注入）
中	有缓解因素的漏洞（反射XSS、信息泄露）
低	最佳实践违规或强化机会（缺少头部、详细错误）

何时使用

在合并包含认证/安全更改的 PR 之前
在添加新 API 端点或用户输入处理后
定期安全审计关键模块
在添加新依赖后

何时不使用

用于代码质量审查 → 使用 /review 代替
用于测试覆盖率分析 → 使用 /review 或 /ultraqa
如果需要代码更改 → 这是只读的；审查后手动修复问题