自定义 Slash Command 的 7 个工程化模板

---
description: 检查代码改动的安全性
argument-hint: "[文件路径或 PR 号]"
allowed-tools:
  - Read
  - Grep
  - Bash(git diff:*)
  - Bash(gh pr diff:*)
---

你是一个资深安全审计师。请对 $ARGUMENTS 指向的改动做安全 review...

---
description: 多视角代码 review（安全/性能/可维护性）
argument-hint: "[PR 号 或 文件 glob]"
allowed-tools:
  - Read
  - Grep
  - Glob
  - Bash(git diff:*, gh pr:*)
---

对 $ARGUMENTS 做 review，严格按下面 4 个视角分别出结论。
每个视角最多 5 条发现，每条格式：
  - 【严重级 高/中/低】
  - 问题描述（不超过 30 字）
  - 文件:行号
  - 建议改法（代码片段，不超过 6 行）

<view name="安全">
关注 SQL 注入、XSS、SSRF、硬编码密钥、不安全反序列化...
</view>

<view name="性能">
关注 N+1 查询、未 index 的大表扫描、同步阻塞、内存泄漏...
</view>

<view name="可维护性">
关注命名、函数长度、魔法数字、重复代码、测试覆盖...
</view>

<view name="兼容性">
关注 API break、数据库 schema 迁移、依赖版本冲突...
</view>

最后给一个 <verdict>approve / request-changes / reject</verdict>。

---
description: 为指定文件/函数生成单元测试
argument-hint: "[文件路径]"
allowed-tools:
  - Read
  - Grep
  - Glob
  - Edit
  - Bash(npm test:*, pytest:*)
---

为 $ARGUMENTS 补齐测试。步骤：

1. 读取目标文件，列出所有 public 函数
2. 搜索项目现有测试文件（*test*, *spec*），挑 2-3 个最相似的
3. 严格模仿既有测试的：
   - 测试框架和断言风格
   - describe/it 命名规则
   - mock 方式
   - fixture 组织
4. 对每个未覆盖的函数生成：正常路径 1 个 + 边界情况 2 个 + 错误路径 1 个
5. 运行测试确认通过

不要使用任何项目中未出现过的断言库或测试 util。

---
description: 从指定函数中提取子函数，保持对外接口不变
argument-hint: "[文件:函数名]"
allowed-tools:
  - Read
  - Edit
  - Bash(npm test:*, pytest:*, cargo test:*)
---

对 $ARGUMENTS：

1. 先用 Read 读取目标函数完整代码
2. 找出 2-4 个逻辑独立的代码块（循环、分支、连续 I/O 操作等）
3. 每个块提取成一个 private 函数，命名动词+名词
4. **严禁改动原函数的签名、参数、返回值**
5. 提取完立刻跑测试，失败则回滚

最后给我一个 before/after 行数对比。

---
description: 按 runbook 调试生产问题
argument-hint: "[告警 ID 或问题描述]"
allowed-tools:
  - Read
  - Grep
  - Bash(kubectl:*, docker logs:*, curl:*, psql:* --readonly)
---

问题：$ARGUMENTS

严格按以下 runbook 执行，每一步完成汇报结果后再进入下一步：

<step n="1">检查服务健康：kubectl get pods -n prod，列出 Not Ready 的</step>
<step n="2">拉最近 5 分钟 error 日志，grep 出 top 3 error pattern</step>
<step n="3">查数据库连接池使用率（SELECT ... FROM pg_stat_activity）</step>
<step n="4">查上游依赖 latency（curl /health/deps）</step>
<step n="5">对照 recent deploys（最近 2 小时 CI/CD 记录），判断是否 regression</step>
<step n="6">输出诊断结论：根因 + 紧急缓解动作 + 是否需要 rollback</step>

任何一步失败立即停止，不要跳步。

---
description: 根据 git diff 生成 PR 描述
argument-hint: "[base 分支，默认 main]"
allowed-tools:
  - Bash(git diff:*, git log:*)
---

对比 $ARGUMENTS（默认 main） 到当前分支，生成 PR 描述：

## Motivation
用一段话说清楚为什么要做这个改动。不要从 diff 倒推，要从 commit message 的语气中推测业务目的。

## Changes
按模块分组的 bullet list。一项不超过 15 字。

## Testing
- 自动化测试：新增/修改了哪些测试
- 手动验证：列出复现步骤

## Rollback Plan
一句话说清楚怎么回滚。如果有 DB 迁移，必须写 down script。

禁止使用"优化"、"改进"、"增强"这种模糊词。

---
description: 生成 conventional commits 格式提交信息
allowed-tools:
  - Bash(git diff --cached:*, git status:*)
---

检查 staged 改动，生成一条 commit message：

格式：<type>(<scope>): <subject>

type 从 feat/fix/refactor/docs/test/chore/perf 中选。
scope 是模块名，从文件路径推断。
subject 祈使句，不超过 50 字符，不加句号。

如果 staged 超过 8 个文件且涉及多个 scope，先提醒我"改动太杂，建议拆分"，然后给出一个折中的 scope。

Body 可选。如果有破坏性改动必须写 BREAKING CHANGE 段。

---
description: 在隔离目录快速写一个原型
argument-hint: "[想验证的技术点]"
allowed-tools:
  - Write
  - Edit
  - Bash(mkdir:*, cd:*, npm init:*, python -m venv:*, node:*, python:*)
---

在 /tmp/spike-$(date +%s)/ 创建一个最小可运行原型验证 $ARGUMENTS。

要求：
- 单文件优先，超过 150 行再拆
- 依赖最少，能用标准库就别装包
- 必须可以 node/python 直接跑出结果
- 结束时把运行命令和输出一起贴给我

不要在主仓库目录下创建任何文件。