Back to Details

production-audit

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Production Audit

生产就绪性审计

Use this skill when the user asks whether an application is ready to ship, what could break in production, or what must be fixed before a launch. This is a maintainer-safe rewrite of the stale community production-audit idea: it keeps the useful production-readiness lens and removes unpinned external execution and third-party data sharing.
当用户询问应用是否已准备好发布、生产环境可能出现哪些问题，或者上线前需要修复哪些内容时，使用此Skill。这是对陈旧社区版production-audit理念的维护者安全重写：保留了实用的生产就绪性审视视角，移除了未固定版本的外部执行和第三方数据共享。

When to Use

适用场景

  • The user asks "is this production-ready", "what would break in prod", "what did we miss", "audit this repo", or "ready to ship?"
  • A feature was merged and needs a pre-deploy or post-merge risk pass.
  • A public launch, demo, customer rollout, or investor walkthrough is close.
  • CI is green but the user wants production risk, not only test status.
  • A deployed URL, release branch, PR, or current checkout is available for evidence gathering.
  • 用户询问“这是否具备生产就绪性”、“生产环境会出什么问题”、“我们遗漏了什么”、“审计这个代码库”或“可以发布了吗？”
  • 功能已合并，需要进行部署前或合并后的风险检查。
  • 即将进行公开发布、演示、客户推广或投资者展示。
  • CI已通过，但用户关注的是生产风险，而非仅测试状态。
  • 可获取已部署URL、发布分支、PR或当前本地检出内容用于证据收集。

When Not to Use

非适用场景

  • During active implementation when the right lens is line-level secure coding; use 
    security-review
    first.
  • For pure libraries, templates, docs-only repos, or scaffolds unless the user wants packaging/release readiness rather than application readiness.
  • When the user asks for a formal compliance audit. This skill is engineering triage, not legal, financial, medical, or regulatory certification.
  • When the only available evidence is a product idea with no repo, deployment, CI, or runtime surface.
  • 处于活跃开发阶段，此时应聚焦于代码行级别的安全编码；请先使用
    security-review
    。
  • 针对纯库、模板、仅文档的代码库或脚手架，除非用户关注的是打包/发布就绪性而非应用就绪性。
  • 用户要求正式合规审计。此Skill用于工程优先级排序，而非法律、财务、医疗或监管认证。
  • 仅能获取产品构想，无代码库、部署、CI或运行时相关信息。

How It Works

工作原理

Build the audit from local and user-authorized evidence. Do not run unpinned remote code, upload repository contents to third-party services, or call external scanners unless the user explicitly approves that specific tool and data flow.
Use this order:
  1. Establish the release surface.
  2. Read recent changes and current branch state.
  3. Inspect runtime, auth, data, payment, background-job, AI, and deployment boundaries that actually exist in the repo.
  4. Check CI, tests, migrations, environment documentation, and rollback path.
  5. Produce a short ship/block recommendation with specific fixes.
基于本地及用户授权的证据构建审计内容。默认情况下，请勿运行未固定版本的远程代码、将代码库内容上传至第三方服务，或调用外部扫描工具，除非用户明确批准特定工具及数据流。
遵循以下步骤：
  1. 确定发布范围。
  2. 查看近期变更及当前分支状态。
  3. 检查代码库中实际存在的运行时、认证、数据、支付、后台任务、AI及部署边界。
  4. 检查CI、测试、迁移、环境文档及回滚路径。
  5. 生成简短的发布/阻止建议，并列出具体修复项。

Evidence Checklist

证据检查清单

Start with cheap, local signals:
text
git status --short --branch
git log --oneline --decorate -20
git diff --stat origin/main...HEAD
Then inspect the project-specific surface:
  • Package scripts, CI workflows, release scripts, Docker files, and deployment manifests.
  • API routes, webhooks, auth middleware, background workers, cron jobs, and database migrations.
  • Environment variable documentation and startup checks.
  • Observability hooks, error reporting, logs, health checks, and dashboards.
  • Rollback, seed, migration, and backfill instructions.
  • E2E coverage for the user paths that matter most.
If a deployed URL is in scope, use browser or HTTP checks only against that URL and avoid credentialed actions unless the user supplies a safe test account.
从低成本的本地信号开始：
text
git status --short --branch
git log --oneline --decorate -20
git diff --stat origin/main...HEAD
然后检查项目特定范围：
  • 包脚本、CI工作流、发布脚本、Docker文件及部署清单。
  • API路由、Webhook、认证中间件、后台Worker、定时任务及数据库迁移。
  • 环境变量文档及启动检查。
  • 可观察性钩子、错误报告、日志、健康检查及仪表盘。
  • 回滚、数据填充、迁移及回填说明。
  • 对核心用户路径的端到端（E2E）覆盖情况。
如果已部署URL在审计范围内，仅针对该URL使用浏览器或HTTP检查，除非用户提供安全测试账户，否则避免使用凭据操作。

Risk Lenses

风险审视维度

Security And Auth

安全与认证

  • Are public routes, API routes, and admin routes clearly separated?
  • Are auth and authorization enforced server-side?
  • Are secrets kept out of client bundles, logs, example output, and checked-in files?
  • Are rate limits, CSRF protections, CORS policy, and upload validation present where the app needs them?
  • Does the AI or agent surface defend against prompt injection, tool abuse, and untrusted content crossing into privileged actions?
  • 公共路由、API路由及管理员路由是否清晰分离？
  • 认证与授权是否在服务端强制执行？
  • 密钥是否未出现在客户端包、日志、示例输出及已提交文件中？
  • 应用所需的速率限制、CSRF防护、CORS策略及上传验证是否已配置？
  • AI或Agent层面是否针对提示注入、工具滥用及不可信内容进入特权操作进行防护？

Data Integrity

数据完整性

  • Do migrations run forward cleanly and have a rollback or recovery plan?
  • Are destructive migrations, backfills, and data imports staged safely?
  • Do database policies, grants, and service-role boundaries match the app's tenancy model?
  • Are retries idempotent for writes, jobs, and webhook handlers?
  • 迁移是否能顺利向前执行，且有回滚或恢复方案？
  • 破坏性迁移、数据回填及数据导入是否已安全部署？
  • 数据库策略、权限及服务角色边界是否与应用的租户模型匹配？
  • 写入操作、任务及Webhook处理器的重试是否具有幂等性？

Payments And Webhooks

支付与Webhook

  • Are webhook signatures verified before parsing trusted payload fields?
  • Is each payment, subscription, or fulfillment webhook idempotent?
  • Are replay, duplicate delivery, and out-of-order delivery handled?
  • Are test-mode and live-mode credentials separated?
  • 在解析可信负载字段前，是否已验证Webhook签名？
  • 每个支付、订阅或履约Webhook是否具有幂等性？
  • 是否已处理重放、重复交付及乱序交付问题？
  • 测试模式与生产模式的凭据是否已分离？

Operations

运维

  • Can the app start from a clean checkout using documented commands?
  • Are required environment variables named, validated, and fail-fast?
  • Is there a health check that proves dependencies are reachable?
  • Are deploy, rollback, and incident-owner paths documented?
  • Are logs useful without leaking secrets or personal data?
  • 能否使用文档化的命令从干净检出状态启动应用？
  • 所需环境变量是否已命名、验证，并在缺失时快速失败？
  • 是否存在可验证依赖可达性的健康检查？
  • 部署、回滚及事件负责人路径是否已文档化？
  • 日志是否有用且未泄露密钥或个人数据？

User Experience

用户体验

  • Are the launch-critical paths covered on desktop and mobile?
  • Are forms usable on mobile without input zoom, layout overlap, or blocked submission states?
  • Do loading, empty, error, and permission-denied states tell the user what happened?
  • Is there a support or recovery path when a critical operation fails?
  • 上线关键路径是否覆盖桌面端及移动端？
  • 移动端表单是否可用，无输入缩放、布局重叠或提交状态被阻塞的问题？
  • 加载、空状态、错误及权限拒绝状态是否能告知用户发生了什么？
  • 关键操作失败时是否有支持或恢复路径？

Scoring

评分标准

Use scores to force prioritization, not to imply mathematical certainty.
BandScoreMeaning
Blocked0-49Do not ship until the top risks are fixed
Risky50-69Ship only behind a small rollout or internal beta
Launchable With Caveats70-84Ship if owners accept the listed risks
Strong85-100No obvious launch blockers from available evidence
Cap the score at 
69
if any of these are true:
  • Authentication or authorization is missing on sensitive data.
  • Payment or fulfillment webhooks are not idempotent.
  • Required migrations cannot be run safely.
  • Secrets are exposed in client bundles, logs, or committed files.
  • There is no rollback path for a high-impact release.
Cap the score at 
84
if CI is not green or the launch-critical path was not tested end to end.
使用分数强制优先级排序，而非暗示数学确定性。
等级分数含义
阻止发布0-49在修复顶级风险前请勿发布
高风险50-69仅能在小范围发布或内部Beta环境中发布
可发布但需注意70-84若负责人接受列出的风险则可发布
良好85-100根据现有证据，无明显上线阻塞项
若存在以下任一情况，分数最高为
69
：
  • 敏感数据缺失认证或授权。
  • 支付或履约Webhook不具备幂等性。
  • 必要迁移无法安全执行。
  • 密钥暴露在客户端包、日志或已提交文件中。
  • 高影响版本无回滚路径。
若CI未通过或上线关键路径未进行端到端测试，分数最高为
84
。

Output Format

输出格式

Lead with one sentence:
text
Production audit: 76/100, launchable with caveats, with webhook idempotency and rollback docs as the two risks to fix before public launch.
Then list:
  • Blockers
    : must-fix items before deploy.
  • High-value fixes
    : next fixes if the user wants to improve the score.
  • Evidence checked
    : files, commands, CI, deployed URL, or PRs inspected.
  • Evidence missing
    : what would change confidence if provided.
  • Next action
    : one concrete fix or verification step.
Keep strengths short. The user asked for readiness, so the useful answer is the remaining risk and the next action.
以一句话开头：
text
生产就绪性审计：76/100，可发布但需注意，需在公开发布前修复Webhook幂等性及回滚文档这两个风险。
然后列出：
  • 阻塞项
    ：部署前必须修复的内容。
  • 高价值修复
    ：若用户想提升分数，下一步需修复的内容。
  • 已检查证据
    ：已检查的文件、命令、CI、已部署URL或PR。
  • 缺失证据
    ：若提供这些信息会改变审计信心。
  • 下一步行动
    ：一个具体的修复或验证步骤。
优点部分保持简短。用户询问的是就绪性，因此有用的答案是剩余风险及下一步行动。

Example

示例

User:
text
is this ready to ship?
Response:
text
Production audit: 68/100, risky, because Stripe webhooks are verified but not idempotent and there is no rollback note for the pending migration.

Blockers:
- Add idempotency for `checkout.session.completed` before fulfilling orders.
- Write and test the rollback path for `20260511_add_billing_state.sql`.

High-value fixes:
- Add a health check that verifies database and payment-provider reachability.
- Add one E2E path for upgrade, webhook fulfillment, and billing-page refresh.

Evidence checked:
- `api/stripe/webhook.ts`
- `db/migrations/20260511_add_billing_state.sql`
- GitHub Actions run for the release branch

Next action: Want me to patch webhook idempotency first?
用户：
text
这个可以发布了吗？
回复：
text
生产就绪性审计：68/100，高风险，因为Stripe Webhook已验证但不具备幂等性，且待执行迁移无回滚说明。

阻塞项：
- 在履行订单前，为`checkout.session.completed`添加幂等性处理。
- 编写并测试`20260511_add_billing_state.sql`的回滚路径。

高价值修复：
- 添加可验证数据库及支付提供商可达性的健康检查。
- 为升级、Webhook履约及账单页面刷新添加一条端到端测试路径。

已检查证据：
- `api/stripe/webhook.ts`
- `db/migrations/20260511_add_billing_state.sql`
- 发布分支的GitHub Actions运行情况

下一步行动：需要我先修复Webhook幂等性吗？

Anti-Patterns

反模式

  • Running 
    npx <package>@latest
    or a remote scanner as the default audit path.
  • Uploading source, secrets, customer data, or private topology to an external audit service without explicit approval.
  • Producing a score without naming the evidence checked.
  • Treating green CI as production readiness.
  • Ending with a generic "let me know what you want to do."
  • 默认使用
    npx <package>@latest
    或远程扫描工具作为审计路径。
  • 在未获得明确批准的情况下，将源代码、密钥、客户数据或私有拓扑上传至外部审计服务。
  • 未说明已检查证据就给出分数。
  • 将CI通过等同于生产就绪性。
  • 以通用的“告诉我你想做什么”结尾。

See Also

相关技能

  • Skill: 
    security-review
  • Skill: 
    deployment-patterns
  • Skill: 
    e2e-testing
  • Skill: 
    tdd-workflow
  • Skill: 
    verification-loop
  • Skill: 
    security-review
  • Skill: 
    deployment-patterns
  • Skill: 
    e2e-testing
  • Skill: 
    tdd-workflow
  • Skill: 
    verification-loop