Production Audit 是一个对已发布仓库的部署状态进行外部审计的技能，用于发现 AI 辅助项目经常遗漏的生产就绪度缺口。
用途 该技能在代码提交之后扫描已部署的产品，覆盖 RLS（行级安全）、Webhook 幂等性、密钥暴露、数据库授权（GRANT）、Stripe 幂等键、索引、可观测性、提示注入等十余种故障模式。它与会话内的安全技能（如 security-review、OWASP 风格、VibeSec、Trail of Bits）互补：后者在编写时扫描编辑器缓冲区，本技能在提交后扫描部署状态，两者时机、输入和发现不同，严肃发布时建议同时运行。
主要能力 技能通过公开 CLI 封装 commit.show 审计引擎，命令为 npx commitshow@0.3.23 audit . --json。输出为稳定的 JSON 信封（schema_version: "1"，仅做加法变更），并同时写入 .commitshow/audit.md 和 .commitshow/audit.json 侧车文件，使后续代理会话无需重新运行引擎即可读取先前状态。JSON 信封包含 score.total（0-100 生产就绪度评分）、score.delta_since_last（与父快照相比的变化，正数表示改善）、score.band（strong 80+、mid 60-79、early <60）、concerns[]（按影响排序的顶部问题，每项含 axis 和 bullet）、strengths[]（顶部 3 项有效之处，仅供上下文）、standing（可选，仅当项目在 commit.show 上 auditioning 时）、snapshot.created_at / trigger_type（审计运行时间）。concerns 按决策影响而非严重程度排序，位置 1 是应首先呈现的条目。
使用方式 从仓库根目录运行。CLI 固定到经过审查的确切版本，避免未来 npm 发布被静默选中。由于 npx 会以当前用户权限在本地下载并运行 npm 包代码，仅在用户明确批准此外部执行、且仓库中本地文件和环境变量对该进程安全时才运行。侧车目录预先创建，stderr 被分离，以免安装/弃用警告破坏 JSON 信封：
mkdir -p .commitshow npx commitshow@0.3.23 audit . --json \
.commitshow/audit.json
2> .commitshow/audit.stderr.log
若用户指向远程 URL 而非 .，将 . 替换为 URL，保持相同的 mkdir -p、版本固定和 stderr 分离。
解析信封后向用户呈现：先用一句话给出评分和趋势，再列出顶部 concerns，不要倾倒完整 JSON。格式示例：
Score: 82/100 (+5 since yesterday) · band: strong
Top concerns: ↓ [Security] No API rate limiting on /auth — IP cap missing ↓ [Infrastructure] webhook handler at api/stripe.ts — signature verified, but no idempotency-key check (replay attack window open)
Want me to fix the webhook idempotency gap first?
规则：使用 concerns[].bullet 中的确切条目（引擎已写好面向行动的文案）；除非用户明确要求，不要列出 strengths；始终以点名具体 concern 的追问结尾，不要问“你想做什么”，而问“先修 X 吗”；若 score.delta_since_last 为负或 null，只以绝对评分开头。
若用户选择某个 concern，先阅读 bullet 中引用的文件，确认缺口与描述相符（引擎偶尔会在问题已在别处缓解时过度标记），提出最小补丁（尽量单文件），未经明确批准不得应用，先展示 diff。应用修复后建议用 --refresh 重新运行（与步骤 1 相同的规范形式，使 audit.json 保持为增量计算的唯一来源）：
mkdir -p .commitshow npx commitshow@0.3.23 audit . --json --refresh \
.commitshow/audit.json
2> .commitshow/audit.stderr.log
适用场景 当用户询问“这是否生产就绪”“生产环境会出什么问题”“给我的项目打分”“我漏了什么”“审计我的仓库”“可以发布了吗”时使用。在功能分支合并到 main 后立即使用（可作为预部署门禁）。在公开发布 / Show HN 帖子 / 投资人演示前使用。当 git log 显示自上次写入 .commitshow/audit.md 以来超过 20 次提交时使用。
不适用场景 在会话内活跃编码期间跳过——此时应使用 security-review / OWASP 风格做行级模式检查；本技能用于合并后 / 发布前审查。库 / 脚手架形式的仓库跳过——引擎最适合应用形式，库会得到部分替代评分。若 .commitshow/audit.json 已存在且不足 1 小时，直接读取而非重新运行。审计有速率限制（匿名：20/IP/天 · 5/仓库/天 · 2000/天全局）。私有 / 非 GitHub 仓库跳过——审计拉取公开 GitHub 信号，私有仓库返回 not_found 错误。
限制 本技能不能替代特定环境的验证、测试或专家审查。审计引擎针对具有实时 URL 的已部署应用校准；CLI / 库 / 脚手架形式得到部分替代评分（审计支柱最高约 45/50），公平但不理想。在企业防火墙阻止 *.supabase.co 时 API 调用失败，没有离线模式，审计依赖公开引擎。冷审计耗时 60-90 秒，缓存审计（7 天内）即时返回，--refresh 强制绕过缓存（计入速率限制）。
安全与安全说明 技能执行 npx commitshow@0.3.23 audit ...，会本地下载并运行该确切 npm 包版本，然后调用 https://api.commit.show 的公开 API（代理到 Supabase Edge Functions）。正常使用中不要将确切版本替换为 latest 或 semver 范围。将 CLI 视为具有本地进程权限的外部代码；除非用户明确接受该风险，否则不得在包含密钥或敏感未提交文件的仓库中运行。不会有意向 API 发送凭据，但本地进程可访问当前用户可用的文件和环境变量。CLI 在当前工作目录写入 .commitshow/audit.{md,json}，这些文件可安全提交（无密钥），但按惯例作为临时产物加入 gitignore。审计引擎只读取公开 GitHub 信号，不修改用户仓库或推送提交。所有针对具体发现的修复提案必须以 diff 展示并经用户批准后才能编辑，未经明确确认绝不应用。
常见问题 私有仓库返回 not_found：引擎只拉取公开 GitHub 信号，可将仓库设为公开，或使用 --no-network 进行仅本地的确定性检查。遇到速率限制（429）：等到次日（限制在 00:00 UTC 重置），或在 commit.show 登录以获得更高的每仓库上限。打磨良好的库 / CLI 评分似乎过低：引擎偏向应用形式，CLI / 库 / 脚手架得到部分替代评分，审计支柱上限约 45/50，这是已确认的校准权衡。重新运行后 concerns[] 为空：重新审计可能命中缓存，使用 --refresh 强制绕过。
相关技能 @security-review——会话内行级安全模式，与本技能并行运行而非替代。@vibesec——面向 vibe-coded 项目的编辑器缓冲区安全审查，不同视角。@owasp-security——编码期间的 OWASP Top 10 覆盖，配套使用。@trail-of-bits-skills——CodeQL / Semgrep 静态分析，不同层次。
附加资源 规范仓库：https://github.com/commitshow/production-audit；审计引擎源码：https://github.com/commitshow/commitshow/blob/main/supabase/functions/analyze-project/index.ts（其中记录了 14 帧故障框架）；JSON schema 稳定于 schema_version: "1"，仅做加法变更；CLI：https://github.com/commitshow/cli；公开 REST API：https://api.commit.show/audit?repo=...&format=json。