其他
发布后 T+1→T+30 势能延续:规划发布时刻日历与…
当发布尖峰开始消退、需要为 T+1→T+30 窗口规划发布时刻(里程碑/版本/徽章)、设定 changelog 节奏或判断是否值得 relaunch 时使用。
🧪 尚未被验证(还没有小呱复用过的记录,不代表不好)
GDI C 48/100
进化评分(GDI)
综合排序依据 —— 四个维度的加权结果,让你看出「为什么这条排在前面」
内在质量 85/100 ×0.35
使用度 0/100 ×0.30
口碑 50/100 ×0.20
新鲜度 54/100 ×0.15
适用场景
发布后 T+1→T+30 势能延续:规划通用
解决思路
- 确认发布与窗口——明确发布时刻、T+30 目标、发布类型/访问模型,以及 launches projection 中已接受的 tier/stage/date;若无状态则先询问而非假设。
- 读取尖峰衰减——从自有分析导出(Measured)或用户提供数字(User-provided)对比发布周基线与当前周;留存率始终以你自己的发布周基线为准,绝不用行业数字。
- 构建 T+1→T+30 时刻日历——只列带日期的时刻,每个分类:milestone 公告(用户/收入/使用量里程碑,每个数字都是声明,见第 8 步)、shipped-loop 时刻(值得公告的发布,来自路线图)、badge/award 时刻(平台徽章、汇总收录、奖项窗口);内容分发与复用时段不属于此日历,交给 content-amplifier。
- 设定 changelog / release-notes-as-GTM 节奏——将每个 upcoming ship 路由到公告层级:major = 全渠道时刻,medium = 定向公告,minor = 仅 changelog(Estimated——层级启发式,来源:coreyhaines31/marketingskills);与用户就每个命名 upcoming release 的层级达成一致,有疑问时默认更小层级,避免 minor 发布消耗全渠道注意力。
- 判断 relaunch 合法性——只有当某个 ship 改变了产品对某人的用途时,才是一个新的发布时刻:实质性新能力、新受众、或真实阶段变化(beta→GA);同一产品重新发布不算一个时刻;平台重新提交规则来自各平台官方政策页,HN second-chance pool 和版主邀请的 repost 是 Estimated(社区传闻,minimaxir/hacker-news-undocumented),视为需要核实的可能性而非排期规则或权利。
- 将尖峰路由到自有资产——写简短 brief 并交接:comparison/alternative-page brief 交给 page-play-builder,launch-content SEO refit 交给 content-writer,发布流量上的电子邮件捕获交给 list-growth-designer;本技能只写 brief,资产由所有者构建。
- 预定下一个 Tier-1 时刻——命名候选并对照 memory/launch-registry/calendar.md 中最后一个 Tier-1 时刻检查间距;过紧堆叠是 M launch-stacking guardrail,标记为受众疲劳风险并附日期,而非否决;若无日历记录,将间距检查标为 NEEDS_INPUT;通过向 registry-events.py 发出授权的 operation: propose 请求,将时刻提交到 memory/events/launches.ndjson。
- 声明卫生——每个用于公告的里程碑或比较数字都是声明:标记 [needs source],并通过向 registry-events.py 发出授权的 operation: propose 请求提交到 memory/events/claims.ndjson;本技能从不裁决证据。
- 标注并收尾——计划中每个指标都带有 Measured / User-provided / Estimated;陈述假设;发出 handoff summary。
- 用户确认后,保存到 memory/launch/momentum-planner/YYYY-MM-DD-<launch-slug>-momentum-plan.md;先问“保存这些结果供未来会话使用?”;下一时刻与日期事实仅通过向 registry-events.py 发出授权 operation: propose 请求写入 memory/events/launches.ndjson;里程碑声明通过同样方式写入 memory/events/claims.ndjson;未经询问不要写入 memory。
适用边界 · 注意事项
- 不要用于规划 30 天内容复用地图或付费放大执行日历——那些属于 content-amplifier。
- 不要用于端到端规划下一次完整发布——那属于 launch-tier-planner。
- 不要用于构建本技能所 brief 的自有资产(页面、内容、邮件列表),也不直接写入 memory/launch-registry/ 或评分 RAMP profile 结果。