项目简介
haiming-app-monetization 是海明Dev（HammingDev）推出的 App 商业化 Skill。它可以在 App 项目目录中读取实际实现、定位相关页面与代码，并结合竞品研究，输出可继续交给开发 Agent 执行的 onboarding、付费墙和套餐设计方案。
这个 Skill 适合已有 App 原型或源码、希望系统梳理商业化路径的开发者。即使没有源码，也可以提供产品说明、截图或录屏，让 Agent 基于现有材料给出辅导建议。
默认行为是评估而不是修改代码。只有明确提出“评估并实现”后，Agent 才会执行相应的代码改动。
核心能力
定位真实路径与优先问题
Skill 会尽量从实际项目中识别 onboarding、付费墙、会员权益和购买流程所在的页面与代码位置，并区分静态推导和运行观察，避免将仅凭源码得出的判断描述成真实运行结果。
研究竞品与候选定价
在运行 Agent 具备联网工具的情况下，Skill 可以研究相关竞品，并整理候选套餐。结果应注明地区、币种、计费周期、信息来源和未知项。如果无法联网，未核实的价格会被明确标注。
设计分支 onboarding
Skill 不只提供统一的新手引导，还会考虑让用户的选择对应不同的产品演示、核心亮点和文案，从而形成个性化的分支 onboarding 方案。
检查和设计付费墙
付费墙分析会关注会员权益是否明确、主推套餐是否突出、试用说明是否完整，以及用户完成购买后应该进入哪个步骤。
规划实施与验证
当你要求落实方案时，Skill 会关注可复用位置、必要改动和首轮实验。不过，该项目不会承诺转化率或收入提升，方案仍需要通过实际数据验证。
安装 Skill
安装到默认环境
进入你的 App 项目目录，然后运行：
npx skills add HammingDev/haiming-app-monetization安装到当前项目的 Codex
如果使用 Codex，并希望将 Skill 安装到当前项目，可执行：
npx skills add HammingDev/haiming-app-monetization --agent codex --yes--agent codex 指定目标 Agent，--yes 用于自动确认安装。
全局安装到 Codex
若希望在多个项目中使用，可进行全局安装：
npx skills add HammingDev/haiming-app-monetization --agent codex --global --yes交互安装时也可以选择其他受支持的 Agent。实际可用能力取决于运行 Agent 是否具备读取项目、运行应用或联网研究所需的工具。
基础使用：进行完整商业化评估
安装完成后，在 App 项目对应的任务中输入：
使用 $haiming-app-monetization 评估当前项目，研究相关竞品，
给出套餐定价、个性化 onboarding 和付费墙方案，先不修改代码。这条指令包含几个重要约束：
- 评估当前项目：要求 Agent 以真实项目结构和现有实现为基础。
- 研究相关竞品：在工具能力允许时补充外部市场信息。
- 给出完整方案：覆盖定价、onboarding 和付费墙。
- 先不修改代码：保持只读分析，便于先审核方向。
建议先使用这种评估模式。你可以检查页面定位是否准确、竞品是否相关、候选定价是否注明地区和周期，再决定是否进入实现阶段。
聚焦单一环节
如果当前只需要检查付费墙，不必要求完整商业化分析。可以输入：
使用 $haiming-app-monetization 检查当前付费墙的会员权益、试用说明和购买路径。这种方式适合范围明确的任务，例如付费墙已经上线，但需要排查以下问题：
- 会员权益是否容易理解。
- 试用条件是否表达清楚。
- 主推套餐是否明确。
- 购买入口和路径是否连贯。
- 购买完成后的下一步是否清晰。
同样的思路也可以用于聚焦 onboarding 或套餐设计，但应在任务中明确希望检查的环节和期望输出。
从评估切换到实施
默认情况下，Skill 不会修改产品代码。如果已经审核方案并希望 Agent 落实，必须明确提出“评估并实现”。
使用 $haiming-app-monetization 评估并实现当前项目的 onboarding 和付费墙优化。先定位可复用组件，说明必要改动，再执行实现并给出验证步骤。由于 README 只规定了“明确要求实现后才修改”的边界，实际修改范围和执行效果取决于项目结构、现有代码以及 Agent 的工具能力。实施前应通过版本控制保存当前状态，并审核 Agent 提出的文件范围。
没有源码时如何使用
没有可读取的项目源码时，可以向 Agent 提供产品说明、截图或录屏。为了提高分析质量，建议材料至少涵盖：
- 产品的目标用户和主要用途。
- 当前 onboarding 的页面顺序与文案。
- 免费功能和会员权益的区别。
- 现有套餐、币种、周期与试用规则。
- 从打开付费墙到完成购买的路径。
在这种情况下，Agent 无法定位真实代码位置，因此应将输出视为产品层面的辅导，而不是已经验证过的工程结论。
高级使用技巧
明确地区、币种和计费周期
请求定价研究时，应指定目标市场。例如，可以要求优先分析某个地区，并分别整理月付、年付或其他周期。即使不主动指定，最终结果也应标注地区、币种、周期、来源和未知项。
要求区分静态分析与运行观察
如果 Agent 只能读取代码，无法启动应用，就不应把推断写成已经观察到的用户体验。可以在指令中补充：
请分别标注哪些结论来自源码静态分析，哪些来自实际运行观察；无法验证的部分列为未知项。先让 Agent 输出优先级
当问题较多时，可要求按优先级整理，而不是一次修改所有内容：
请定位 onboarding、付费墙和购买路径中的问题，按影响与实施成本排序，先给出首轮实验，不修改代码。README 提到输出应包含优先问题、必要改动和首轮实验，因此这种任务结构有助于将建议转化为后续开发工作。
让 onboarding 选择真正影响后续内容
设计个性化 onboarding 时，不要只收集用户选择。应要求每个选择映射到不同的演示、亮点或文案，使分支对用户可见且有意义。
检查购买后的下一步
付费墙评估不应止于支付按钮。还要确认购买完成后，用户会看到什么、进入哪个功能，以及如何理解刚刚解锁的会员权益。
将结论交给开发 Agent 前先复核
在进入实施阶段前，建议确认：
- 页面和代码路径是否真实存在。
- 竞品价格是否标注来源和核实状态。
- 试用说明是否与实际规则一致。
- 主推套餐和会员权益是否表达清楚。
- 改动范围是否符合当前版本目标。
- 首轮实验是否有可验证的结果。
能力边界与版本状态
当前版本为 v0.1.0，已通过 Skill 格式校验。其方法曾在 Life Widget 项目中完成静态评估和竞品研究，但尚未证明能够实际提升转化率。
联网研究和项目读取依赖运行 Agent 的工具能力。无法联网时，Skill 会标注价格未核实；无法运行应用时，也应将静态判断与运行结果区分开。仓库本身不包含项目源码或私人合作 brief。
Skill 的入口文件是 SKILL.md，行为验收参考位于 references/acceptance.md。项目采用 MIT 许可证，允许使用、修改、再分发和商业使用，但分发时必须保留版权声明和许可证。
总结
haiming-app-monetization 将 App 商业化分析组织成一套可交给 AI Agent 执行的流程：读取现有实现、研究竞品、设计分支 onboarding、梳理套餐和付费墙，并规划实施与首轮验证。最佳实践是先以只读模式评估，再审核来源、未知项和改动范围，最后通过明确的“评估并实现”指令进入开发阶段。