用途
plan-secrets-audit 是一个专注于凭据暴露与密钥作用域的安全审计技能，角色定位为高级安全工程师。它的核心任务不是简单 grep 字符串，而是补上 grep 无法完成的两项判断：作用域（这个密钥是否本应出现在客户端）与持久性（它是否已进入 git 历史，从而使单纯迁移失效）。
该技能只做审计与规划，不执行轮换、历史重写或环境变量修改，直到每个阶段获得批准。
主要能力
审计分为五个部分：
- A · 模式扫描（工作区）：在 .env* 与仅服务端上下文之外搜索 sk_、pk_、whsec_、service_role、eyJ...、AKIA、API_KEY、SECRET、TOKEN 以及长随机字符串等前缀；区分 Supabase 的 anon 与 service_role；检查任何会发送到浏览器的文件中的密钥。
- B · 作用域分类：安全客户端密钥（Supabase anon、Stripe 可发布密钥 pk_、公开分析密钥）需注明其保护依赖（RLS、Stripe 设计）；绝不应出现在客户端的密钥（service_role、Stripe 密钥 sk_、webhook 密钥 whsec_、AWS 密钥、数据库 URL）一旦暴露即为严重；并识别 NEXT_PUBLIC_ / VITE_ / EXPO_PUBLIC_ 这类会被打包进客户端的陷阱。
- C · git 历史（轮换 vs 迁移）：只要曾进入已提交历史，就应轮换，迁移只是表面功夫；历史清理（filter-repo/BFG）是次要手段，轮换优先。
- D · 部署环境配置（Vercel / AWS）：密钥应存放在平台环境存储中，而非烘焙进构建产物；.env.example 不应提交真实值；不应把密钥作为构建参数（会残留在镜像层）。
- E · .gitignore 与卫生：.env* 应被忽略；README、注释、测试夹具中不应出现密钥。
使用方式
触发短语包括："scan for secrets"、"are my keys exposed"、"did I commit an API key"、"is my .env safe"、"rotate keys"、"about to open-source this"、"pre-launch secret check"。
流程为：扫描工作区（A）→ 分类作用域（B）→ 对每个凭据检查历史（C）→ 审查部署与卫生（D、E）→ 评分（绝不应出现在客户端却出现在客户端包或历史中即为严重）→ 分阶段，输出 plan-secrets-audit.md，然后在对话中给出独立回顾：两到三条影响最大的发现（类型 + 位置 + 末 4 位，绝不给出值）以及首个待批准阶段。文件是交付物，须在回顾前写好。
报告模板包含范围、结论（按严重程度统计）、发现表格（编号、密钥类型、位置、作用域桶、是否在历史中、动作、严重度）、分阶段清理计划（阶段 1 轮换暴露的绝不应客户端密钥 → 阶段 2 迁移干净密钥 → 阶段 3 卫生 → 阶段 4 可选历史清理）以及执行交接。
适用场景
适用于排查硬编码密钥、检查是否误提交 API Key、评估 .env 安全性、准备开源或上线前的密钥检查。不适用于 RLS 策略正确性（应交给 plan-rls-audit）或输入/webhook 校验（应交给 plan-input-validation）。
限制
- 仅做规划：本轮不执行轮换、历史重写或环境变量编辑。
- 绝不打印密钥值，最多给出类型、位置与末 4 位字符。
- 轮换优先于迁移，必须明确说明是哪一种。
- 不假设安全客户端密钥就没问题：anon 密钥 + 无 RLS 应交给 plan-rls-audit。
- 执行顺序：轮换 → 更新环境存储 → 重新部署 →（可选）清理历史。
- 轮换近乎不可逆，计划只说明轮换哪些密钥，规则约束如何执行及顺序。
与其他技能的关系
- plan-security-audit：OWASP 总括，不负责首个密钥匹配。
- plan-rls-audit：表访问控制。
- audit-env-parity：环境/配置漂移。
- create-hook：作为回归防护的提交前密钥扫描钩子。
执行涉及提供商仪表盘、Vercel/AWS 环境、audit-security；验证方式为重新扫描工作区与历史，确认已轮换的密钥失效。