用途：在产品或功能发布前，按职能系统性检查各项准备情况，避免遗漏，并基于证据给出明确的 Go / Conditional Go / No-Go 建议。
必要输入：若用户未提供，需询问发布名称与目标日期、发布层级（Tier 1 重大发布 / Tier 2 重要功能 / Tier 3 增量更新）、已完成的清单项或自评（可仅部分）、团队与角色名称（用于为阻塞项指派负责人）。
按职能的就绪清单：产品与工程（对照发布规格功能完成、性能基准达标、无障碍标准检查、边界情况记录并处理、回滚方案定义并测试）；营销与传播（发布信息获批、博客/新闻稿起草、社交内容准备、邮件活动排期、落地页上线并测试）；支持与成功（支持团队培训、FAQ 与帮助文档发布、发布问题升级路径、客户成功简报）；销售与合作（销售赋能材料、定价确认并传达、合作伙伴沟通）；数据与分析（埋点事件实现并验证、发布指标看板上线、发布前基线指标采集）。
流程：审查提供的发布简报与清单回答；将未完成项标记为阻塞项（必须修复）或风险（需监控）；评估整体就绪度并给出带理由的 go/no-go 建议；若为 no-go，明确说明必须完成的内容与截止时间；验证每个阻塞项都有具名负责人与解决截止时间，且回滚方案经过测试（而非仅记录）。
输出结构：发布就绪评估（功能/产品名称）、发布日期、发布层级、整体状态（✅ Go / ⚠️ Conditional Go / 🛑 No-Go）、阻塞项（事项+负责人+要求解决时间）、风险（事项+缓解方案）、就绪领域、建议（3-5 句明确的 go/no-go 及理由）。
质量检查：每个阻塞项有具体负责人（非“团队”）和截止时间；回滚方案明确经过测试而非仅写出；分析事件在预发布环境验证而非仅实现；Go/No-Go 决定有具名决策者与截止时间；至少安排一次发布后监控检查（如 T+2hr、T+24hr）。
反模式：无证据不得标记为“就绪”；Conditional Go 必须明确条件与时限；回滚方案未经预发布测试不得视为完成；阻塞项不得指派给“团队”；不得跳过分析验证步骤。
限制：具体适用产品类型、收费方式、价格与平台信息暂未提供。