关于 launch-readiness
launch-readiness 是面向产品发布团队的检查技能，可按职能评估准备情况并给出有依据的上线建议。它将未完成事项划分为阻碍项或风险，并要求明确负责人和期限。
主要功能
- 01按职能检查发布准备情况
- 02将缺项归类为阻碍项或风险
- 03生成有依据的上线或暂缓建议
- 04为阻碍项指定负责人和解决期限
- 05检查回滚方案是否经过测试
适用场景
- 01评估新功能发布前的准备度
- 02整理发布阻碍并明确责任人与期限
- 03决定是否按计划发布
安装
复制下面的命令，在终端中运行。
$
npx skills add https:/安装后在 Claude Code 中输入/launch-readiness确认已加载。
详细介绍
发布就绪度技能
在发布前，系统地检查各职能的就绪情况，确保万无一失，并给出清晰、有证据支撑的是否发布建议。
必需输入
如果用户未提供以下信息，请向用户询问：
- 发布名称和目标日期
- 发布等级（Tier 1 = 重大发布 / Tier 2 = 重要功能 / Tier 3 = 增量更新）
- 已完成的检查项或自评结果（部分内容也可以——我们会指出差距）
- 团队和角色名称（用于为阻塞项指定负责人）
各职能就绪度检查清单
产品与工程
- 功能已按照发布规格完成
- 已达到性能基准
- 已检查无障碍标准
- 已记录并处理边缘情况
- 已制定并测试回滚计划
市场营销与沟通
- 发布信息已获批准
- 博客文章 / 新闻稿已起草
- 社交媒体内容已准备好
- 邮件营销活动已安排
- 着陆页已上线并经过测试
支持与客户成功
- 支持团队已接受新功能培训
- FAQ 和帮助文档已发布
- 已为发布问题定义升级处理路径
- 客户成功团队已了解情况（如适用于企业客户）
销售与合作伙伴
- 销售支持材料已准备就绪
- 定价已确认并传达
- 已向合作伙伴发送沟通信息（如适用）
数据与分析
- 已实现并验证跟踪事件
- 发布指标仪表板已上线
- 已在发布前采集基准指标
流程
- 审查提供的发布简报和检查清单答复
- 将未完成项标记为阻塞项（必须修复）或风险（需监控）
- 评估整体就绪度，并给出是否发布的建议及理由
- 如果不建议发布，请明确说明必须完成的事项及截止时间
- 验证 — 确认每个阻塞项都有明确的负责人和解决期限，并且回滚计划已测试（而非仅有文档）
输出结构
发布就绪度评估：[功能 / 产品名称]
发布日期：[日期] 发布等级：[1 / 2 / 3] 总体状态：✅ 可以发布 / ⚠️ 有条件发布 / 🛑 不可发布
阻塞项（发布前必须解决）：
- [事项 + 负责人 + 必须完成的期限]
风险（密切监控）：
- [事项 + 缓解计划]
就绪的职能：
- [职能]：✅ 已就绪
建议： [明确说明是否发布及理由——3-5 句]
质量检查
- 每个阻塞项都有明确的负责人（不能是“团队”）和截止时间
- 回滚计划已明确测试，而不只是写成文档
- 已在预发布环境中验证分析事件，而不只是完成实现
- 是否发布的决定有明确的决策者和截止时间
- 已安排至少一次发布后监控检查（例如，T+2hr、T+24hr）
反模式
- 没有证据时，不要将某项职能标记为“已就绪”——绿色状态必须有已完成的检查项作为依据，而非主观假设
- 不要在未明确说明必须满足的具体条件及期限时给出有条件发布的结论——含糊的条件不算条件
- 除非回滚计划已在预发布环境中测试，否则不要将其视为已完成，而不只是写成文档
- 不要将阻塞项指派给“团队”——每个阻塞项都必须有一位明确的负责人，否则无法确保在发布前解决
- 不要跳过分析验证步骤——未经验证的跟踪事件会导致发布情况不可见，也无法评估
评论
支持 Markdown