knock-product-messaging-strategy

产品消息策略技能

将产品转变为一套协调一致的消息系统，而不是一堆互不关联的单次通知。此技能将产品负责人高效消息指南转化为 Agent 步骤，生成适用于 Knock 的计划和资源。

配套手册：

• 应用内消息最佳实践
• 事务性电子邮件
• 通知基础设施

输出要求（必须遵守）

将完整计划写入 knock-plan.md（仓库根目录）。聊天内容保持简短——仅包含状态和确认。遵循 rules/knock-plan-file.md。

不要在聊天中粘贴完整的建议说明、分类体系或检查清单。以计划文件为上下文和交接给 knock-setup 的信息来源。

概述

设计或审查消息系统时，按顺序处理以下规则文件。逐步将详细发现写入 knock-plan.md；不要在聊天中逐一叙述。

1. 数据基础与触发条件——有意义的产品时刻和事件负载
2. 接收者与责任归属——谁应该收到消息，以及原因
3. 发送策略——渠道、升级、时间安排、停止条件
4. 发送量与批处理——频率控制和摘要
5. 相关性与偏好——个性化和偏好分类体系
6. 衡量与审查——结果、疲劳信号、发布检查清单
7. 在 Knock 中应用——将计划映射到工作流、引导、受众和偏好

如何使用此技能

为产品设计消息系统

1. 了解产品（代码库、事件、角色、生命周期）。如有需要，最多提出 3 个澄清问题。
2. 按照 rules/data-foundation-and-triggers.md 列出有意义的时刻和必需的事件数据，并将它们写入 knock-plan.md。
3. 对每个高价值时刻，使用接下来的规则文件确定接收者、发送、发送量和偏好方面的方案；更新计划文件，而非聊天内容。
4. 按增长成效排序：激活、留存、收入挽回，最后是可选提醒。
5. 在计划中标记为可构建之前，先按照 rules/measurement-and-review.md 审查每个候选项。
6. 使用 rules/apply-in-knock.md 丰富计划中的 Knock 结构（仅在用户明确要求时创建资源）。连接后优先使用 Knock MCP / CLI。
7. 在聊天中：用一行状态说明指向 knock-plan.md，然后询问要构建哪些项目。确认问题放在最后，并加粗。

审查现有通知方案

1. 将当前工作流、引导、渠道和偏好类别清点到 knock-plan.md（审查部分）。
2. 按照 rules/measurement-and-review.md 中的审查清单逐项评分。
3. 在文件中标记缺失的停止条件、范围过广的接收者规则、渠道垃圾信息和偏好缺口。
4. 聊天中：用一行状态说明，并询问接下来要处理哪些修复/合并/移除项目。

交接给设置或实施流程

• 策略获批后，如需从零开始设置 Knock，请继续使用 knock-setup。
• 如需撰写文案和设置渠道格式，请使用 knock-notification-best-practices。
• 如需处理应用内引导界面，请使用 knock-in-app-ui。
• 如需管理本地资源，请使用 knock-cli。

交接给 knock-setup 时，请更新 knock-plan.md 中的设置交接部分，并在聊天中传递相同的列表（除非用户要求，否则不要重新排序）：

### Setup handoff
- **plan.** knock-plan.md
- **confirmed.** [names or indexes]
- **skipped.** [names or indexes]
- **deferred / blocked.** [names + reason]

knock-setup 必须以 confirmed 为准，从 knock-plan.md 读取详细信息，并跳过重新发现。

规则文件参考

• rules/knock-plan-file.md — 计划文件路径、结构和聊天简洁性规则
• rules/data-foundation-and-triggers.md — 事件、载荷和时机类型
• rules/recipients-and-ownership.md — 接收者选择和升级
• rules/delivery-strategy.md — 渠道顺序和时机
• rules/volume-and-batching.md — 频率、冷却时间和摘要
• rules/relevance-and-preferences.md — 上下文、个性化和偏好
• rules/measurement-and-review.md — 成效、疲劳度和上线标准
• rules/apply-in-knock.md — 将决策映射到 Knock 原语

快速参考

四种时机类型

1. 用户请求的结果 — 导出完成、付款已提交（通常立即处理）
2. 协作活动 — 提及、分配、审批（立即处理或批量处理）
3. 产品或账户状态变更 — 集成中断、用量限制、付款失败
4. 基于时间的条件 — 试用即将结束、引导流程未完成、审批逾期

构建前的不可妥协事项

• 触发条件应代表有意义的状态变更，而不能仅仅是模糊的不活跃启发式规则
• 接收者应是负责采取下一步行动的人
• 明确主要渠道和升级路径
• 明确停止 / 取消条件，并在延迟后重新检查
• 分配偏好类别（或明确标记为交易性 / 服务关键型）
• 成功指标应是产品成效，而不只是打开率

增长优先级顺序

1. 激活 / 达成价值的时间
2. 核心循环参与度（协作、习惯）
3. 收入保护（付款失败、试用、限制）
4. 基于准确状态的重新参与 / 挽回
5. 公告和教育（最低打扰）