mcpField
P
product-launch-checklist

product-launch-checklist

github.com/mohitagw15856营销与增长1.5k47 次安装5 天前更新
代码仓库

关于 product-launch-checklist

product-launch-checklist 是面向产品团队的分级发布清单技能，覆盖发布前准备、上线执行和发布后监测。清单获批后，可交由 action-runner 预览并按批准项执行。

主要功能

  1. 01按发布级别生成清单
  2. 02覆盖工程、营销、支持和分析
  3. 03设置 Go/No-Go 条件与负责人
  4. 04安排分阶段上线和回滚检查
  5. 05规划发布后指标复盘

适用场景

  1. 01规划新产品或功能发布
  2. 02明确发布期间的团队分工
  3. 03检查上线准备、回滚与后续监测

MCP 相关

清单获批后，技能可将事项交给 action-runner；后者通过已连接的 action MCP 预览并执行获批操作。示例操作包括创建 GitHub 或 Linear 工单，以及向 Slack 发布摘要。

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/mohitagw15856/pm-claude-skills --skill product-launch-checklist

安装后在 Claude Code 中输入/product-launch-checklist确认已加载。

详细介绍

产品发布检查清单技能

发布前务必检查所有事项。生成一份完整的检查清单，明确分配负责人，涵盖发布前准备、发布日执行和发布后监控。

提议操作

检查清单获批后，即可执行：将事项交给 action-runner，由它预览这些事项（试运行并评估风险等级），仅通过已连接的操作 MCP（GitHub/Linear/Slack）执行你批准的事项，并将执行记录写回知识库。常见操作：在指定的仓库/项目中为每个检查清单事项创建一个问题（🟡），以及将发布摘要发布到 Slack（🔴 — 逐项批准）。此技能负责提议；action-runner 负责审核并执行——绝不会在未经确认的情况下执行。

必需输入

如果用户未提供以下信息，请询问：

  • 发布名称和计划发布日期
  • 发布级别（1 = 重大产品发布，2 = 重要功能发布，3 = 增量更新）
  • 团队成员及其职责（工程负责人、PM、营销、支持等）
  • 功能描述（即将发布的内容）
  • 回滚能力（能否快速通过功能标志禁用或回退？）

从知识库读取／写入知识库

如果存在 professional-brain（brain/），请先使用它，再提出问题：

  • 先读取： 即将发布的 entities/ 功能及相关的 decisions/（范围、日期、负责人）。
  • 之后写入： 将发布决策和负责人记录到 decisions/。此技能还可以将检查清单交给 action-runner 创建工单——它会把实际执行情况写回知识库，形成闭环。

如何使用此技能

提供：

  • 发布名称和日期
  • 发布级别（1 = 重大，2 = 功能，3 = 增量）
  • 团队成员及其职责

此技能会生成分级检查清单。级别 3 的发布仅使用“核心事项”部分。级别 2 会增加“营销与沟通”部分。级别 1 使用所有部分。

输出格式

发布检查清单 — [功能/产品名称] — 目标日期：[日期]

发布级别： [1 / 2 / 3] 发布负责人： [PM 姓名] 工程负责人： [姓名] Go/No-Go 决策截止时间： [日期和时间 — 通常为发布前 24 小时]

🔧 发布前 — 工程与产品（T-2 周）
  • 已创建功能标志，并在预发布环境中完成测试
  • PM 已确认所有验收标准
  • 代码已完成审查并合并至 main
  • 已完成 QA 验收（回归测试 + 新功能测试）
  • 已完成性能测试（负载、延迟）
  • 已完成安全审查（如涉及数据或身份验证变更）
  • 已记录并测试回滚流程
  • 已配置监控和告警
  • 已设置错误日志记录，并配置正确的严重级别
  • 已使用生产数据量在预发布环境中测试数据库迁移
📢 发布前 — 营销与沟通（T-1 周）
  • 已撰写、审核并安排发布博客文章
  • 已配置应用内公告或工具提示
  • 已起草并完成 QA 的邮件营销活动
  • 已起草并安排社交媒体帖子
  • 落地页或功能页面已在预发布环境上线
  • 已发送媒体宣传材料（仅限级别 1）
  • 已准备 Product Hunt／社区帖子（仅限级别 1）
🎓 发布前 — 销售与支持（T-1 周）
  • 已完成销售赋能单页
  • 已与销售和支持团队分享常见问题文档
  • 已撰写并发布帮助中心文章
  • 已完成支持团队演示／培训
  • 已向客户成功团队介绍重点客户情况
  • 已更新定价（如适用）
  • 已更新合同／服务条款（如适用）
📊 发布前 — 分析（T-1 周）
  • 预发布环境中的分析事件均正常触发
  • 已配置发布指标仪表板
  • 已记录基准指标
  • 已记录成功标准并与团队分享
  • 已配置 A/B 测试（如适用）
✅ GO / NO-GO 决策 — T-24 小时
标准状态负责人
所有关键 Bug 均已解决🟢 / 🔴Eng Lead
QA 已完成签字确认🟢 / 🔴QA
已测试回滚🟢 / 🔴Eng Lead
帮助中心文章已上线🟢 / 🔴Support
监控已启用🟢 / 🔴Eng Lead
PM 已签字确认🟢 / 🔴PM

Go / No-Go 决策： [GO / NO-GO] 决策负责人： [PM + Eng Lead 联合负责]

🚀 发布日
  • 向 [X%] 的用户启用功能标志（从低比例开始——5–10%）
  • 在团队 Slack/频道中确认发布
  • 打开指标仪表板并持续监控
  • 在 T+15 分钟、T+1 小时、T+4 小时检查错误率
  • 发布博客文章 / 发送邮件
  • 发布社交媒体帖子
  • 支持团队在前 4 小时待命
  • PM 全天保持在线且可联系
  • 如果 T+2 小时检查通过，将功能标志扩大至 50%
  • 如果 T+4 小时检查通过，将功能标志扩大至 100%
📈 发布后（D+7，D+30）
  • D+7 指标回顾：采用情况、错误、支持工单
  • 汇总 D+7 客户反馈
  • 安排复盘
  • 记录经验教训
  • 对照目标回顾 D+30 成功指标
  • 从代码库中移除功能标志（清理）
  • 根据反馈将后续功能加入待办事项

质量检查

  • 在生成检查清单前确认发布等级（范围决定所需深度）
  • Go/No-Go 决策须指定负责人和具体决策时间
  • 回滚流程已记录并经过测试（不只是计划好）
  • 分阶段扩大功能标志的覆盖比例（5% → 50% → 100%），而非一次性全部启用
  • 安排在发布时进行发布后复盘

反模式

  • 不要对增量更新套用 Tier 1 检查清单——生成检查清单前应合理划分发布等级
  • 如果未确认周末工程支持安排，不要在星期五发布
  • 不要将 Go/No-Go 决策负责人留作“团队”——必须指定具体个人
  • Tier 1 和 Tier 2 发布不得跳过回滚计划——上线前应明确回退所需时间
  • 不要在未安排发布后复盘的情况下结束发布——必须在发布时预约，而不是之后再安排

指南

  • Go/No-Go 决策必须指定负责人——“团队”不算负责人
  • 除非有周末工程支持，否则绝不要在星期五发布
  • 建议所有发布都从低于 10% 的流量开始——即使是简单功能也一样
  • 记录回滚时间：“我们可以在 X 分钟内回退”应在发布前明确

评论

支持 Markdown