发布定价与梯度打包规划：设计分层定价、早鸟优惠与退款保证

当需要决定发布时收多少钱、如何打包（分层结构、发布优惠、beta 定价与保证条款）时使用。

适用场景

解决思路

1. 确认当前状态与商业目标：梳理现有定价/历史、单位经济、发布类型/访问模式，以及预先声明的收入/注册/管道目标；不要凭空捏造基线。
2. 设计分层结构与命名：两个起始启发式（均为社区经验、非实测规则）——约 1x / 2.2x / 5x 价格的 3 层阶梯，或 2 层结构（真正的产品是第二层，第一层用于锚定）；按服务深度命名（DIY / Done-With-You / Done-For-You）或按 ICP 命名；用用户实际成本与价值结构验证，而非盲目套用比例。
3. 将价值映射到价格：把每层内容对齐 message-house 的价值支柱，确保每个支柱都能在某处被购买、每层的头条功能都复述某个支柱；标出无归属的支柱和未售卖任何支柱的层级。
4. 设计发布优惠及其截止理由：折扣或赠品阶梯必须配真实的紧迫理由（发布周窗口结束、创始会员名额上限、beta 结束时涨价）；不要设计虚假稀缺（会重置的倒计时、不真实的“仅剩 N 个”），这触及 RAMP A1 声明诚信红线；每个优惠条款（百分比、截止日期、名额上限）都是声明，需提交。
5. 规划 beta / 早期采用者价格路径：确定 beta 或早期采用者价格、早期采用者在 GA 后是否保留原价（grandfathering）、以及声明的 GA 后价格；按阶段声明定价状态以支撑 RAMP-R1 阶段真实性（GA 承诺公开付费可用就需要上线定价页）。
6. 设计保证 / 退款条款：明确窗口、条件、由谁履行、以及确切措辞；保证是带必要披露的声明，无法证实的内容标记 [needs source]，本技能不裁定声明。
7. 为每个数字打标签：价格历史与转化数据标为 Measured 或 User-provided；分层比例、预期转化率、优惠提升预测标为 Estimated 并注明来源；绝不说本技能无法知道的行业基准——对比“你自己的历史转化率”，而非“好的转化率是 N%”。
8. 将条款路由到注册表：打包声明/条款候选与阶段关联的定价事实并交接；由注册表正式化，本技能绝不直接写入其记录。
9. 交付后询问是否保存结果：确认后保存到 memory/launch/pricing-packaging-planner/YYYY-MM-DD-<product-or-offer>.md；声明与优惠条款候选经授权的 operation: propose 请求提交到 registry-events.py 写入 memory/events/claims.ndjson；与注册表相关的定价状态事实写入 memory/events/launches.ndjson；未经询问不得写入 memory。

适用边界 · 注意事项

• 不适用于规范化的 offer / claim 记录——应使用 offer-claims-registry。
• 不适用于付费订阅通讯的经济模型——应使用 newsletter-monetization-planner。
• 不适用于广告竞价或拍卖策略——应使用 bid-strategy-planner。