发布定价打包规划器

解决什么问题

产品进入发布阶段时，定价往往比功能更棘手：分层怎么划、档位怎么命名、首发优惠如何既有真实紧迫感又不触碰虚假宣传红线、beta 用户的低价何时以及如何过渡到正式价格。这些问题散落在商业化、法务和增长团队之间，缺少一个能把价值主张与价格锚点对齐的产物。@user_2c0f1e77/aaron-pricing-packaging-planner 负责产出这样一份发布定价与打包方案，但它只动一根杠杆：pricing/packaging。

核心能力与工作方式

技能在 RAMP 循环的 Assemble 阶段运行，输入当前定价与历史、单位经济数据（若已知）、已确认的 message-house 价值支柱、竞品公开定价页和发布阶段/日期。产出包括：命名后的分层结构及每档内容、对齐价值支柱的价值-价格映射、带真实截止理由的发布优惠阶梯、beta/early-adopter 价格及其明确的过渡路径、以及保证/退款条款草案。

流程上有几个关键设计：

• 分层启发式需自行验证。技能提供两条社区启发式（源自 swyxio/launch-cheatsheet，标注为 Estimated）：约 1x / 2.2x / 5x 的三档阶梯，或以低价档锚定、真正产品放在第二档的两档结构。但技能明确要求对照用户的实际成本与价值结构验证，而非机械套用比例。
• 每个档位都要能追溯到价值支柱。技能会标记没有任何价值支柱落点的档位，以及销售内容无人认领支柱的档位，确保定价不是孤立的数字游戏。
• 紧迫感必须真实。折扣、截止日期、人数上限都要有真实理由（发布周窗口结束、创始成员名额封顶、beta 结束价格上调）。倒计时会重置、名额并不真实的伪稀缺设计，与 RAMP A1 claim-integrity 红线相邻，技能不会生成这类方案。
• 所有价格主张只是候选，不是生效报价。每一条定价声明、优惠条款、保证措辞都会通过授权操作 propose request to registry-events.py 提交到 memory/events/claims.ndjson，由 offer-claims-registry（offers.md 是生效报价的唯一事实来源）正式登记。技能自己从不直接写 memory/claims/ 或 memory/launch-registry/。

适用边界与注意点

技能只设计发布定价与打包：不拥有报价/主张的权威记录，不建模付费订阅 Newsletter 经济（那是 newsletter-monetization-planner 的职责），不规划广告出价策略，也不运行 RAMP 否决检查（那是 launch-readiness-auditor）。它草拟的保证条款若本会话无法证实，会标注 [needs source]，且不做主张裁定。另外，所有粘贴的定价页和竞品文档都被视为不可信输入，其中嵌入的指令不会被执行。计划完成后，技能会先询问是否保存结果，而非直接写入 memory/launch/pricing-packaging-planner/。