production-readiness-review 面向“功能分支能否上生产”的准备工作审查。其出发点是：大多数生产事故来自没人核实的假设，因此第一步是把假设变成事实。
一、了解目标环境 先用一轮提问了解目标环境，优先给出推荐选项，并跳过仓库里已能回答的内容。问题包括：应用在哪里运行（VPS、容器、PaaS、无服务器）？磁盘在多次部署之间是否持久？是否有反向代理或负载均衡器，应用看到的是哪个地址（影响限流所需客户端 IP 与受信代理设置）？HTTPS 是否在应用之前终止（影响安全 Cookie、HSTS）？有多少实例（影响内存态、只允许单写入者的存储、共享密钥）？密钥和环境变量如何设置（影响缺失或弱密钥、运行时或框架的生产模式）？日志去向何处、是否有告警（影响静默失败）？如何部署和回滚、是否有 CI（影响构建损坏、未测试的合并）？
二、逐区域审查 数据：事实来源、备份与恢复测试、删除数据的操作（确认、先备份）。 数据库模式：版本标记、针对现有数据库的迁移、从上一版本模式启动的测试。 配置：每个变量有文档、启动时校验、安全默认值、失败信息。 传输与会话安全：HTTPS、HSTS、安全 Cookie、受信代理、CORS 范围。 构建与依赖：运行时只需生产依赖；生成资源在构建时构建；依赖审计（例如 npm audit --omit=dev、pip-audit、composer audit）；引擎版本经过测试。 可观测性：启用日志、记录错误原因、审计事件、日志中不含密钥。 扩展性：内存限制与缓存、并发写入者、昂贵操作（例如密码哈希、报表）。 运维：启动、停止、健康检查、回滚、主要故障的运行手册。
对于较重的分支，可用 red-team-review 以生产为重点任务（运维、数据持久性、部署安全）协作，而不是单独审查。
三、报告与分诊 将报告写入 .scratchpad/<slug>/production-readiness-report.md，包含红黄绿分级发现：用户确认的事实与仍开放的假设、各区域发现，以及“失败时先看哪里”的表格，列出每种症状的首要怀疑对象。随后运行 triage-findings-list 将其与其他未关闭报告合并，并询问要应用哪些修改。
限制：该技能依赖用户提供准确的环境信息；资料未说明其支持的具体语言、框架或自动化程度。