Designing Onboarding, Paywalls, and Plans with HammingDev's App Monetization Skill

Project Overview

haiming-app-monetization is an app monetization Skill created by HammingDev. It reads the actual implementation in an app project directory, locates relevant pages and code, and combines this information with competitor research to produce onboarding, paywall, and plan design proposals that can be handed off to a development Agent.

This Skill is suitable for developers who already have an app prototype or source code and want to systematically organize their monetization path. Even without source code, you can provide product descriptions, screenshots, or screen recordings so the Agent can offer guidance based on the available materials.

The default behavior is evaluation, not code modification. The Agent will make code changes only after you explicitly request “evaluate and implement.”

Core Capabilities

Locating Real Paths and Priority Issues

The Skill attempts to identify the pages and code locations for onboarding, paywalls, membership benefits, and purchase flows in the actual project. It also distinguishes between static inferences and runtime observations, avoiding descriptions of source-code conclusions as actual runtime results.

Researching Competitors and Candidate Pricing

When the Agent has internet access, the Skill can research relevant competitors and organize candidate plans. Results should specify the region, currency, billing period, information sources, and unknowns. When internet access is unavailable, unverified prices are clearly marked.

Designing Branching Onboarding

The Skill does more than provide a single standardized introduction. It also considers mapping user choices to different product demonstrations, key highlights, and copy to create a personalized branching onboarding plan.

Reviewing and Designing Paywalls

Paywall analysis focuses on whether membership benefits are clear, whether the featured plan stands out, whether trial details are complete, and which step users should enter after completing a purchase.

Planning Implementation and Validation

When you ask to put a proposal into practice, the Skill focuses on reusable locations, required changes, and initial experiments. However, the project does not promise higher conversion or revenue. The proposal still needs to be validated with real data.

Installing the Skill

Install in the Default Environment

Enter your app project directory and run:

npx skills add HammingDev/haiming-app-monetization

Install to Codex for the Current Project

If you use Codex and want to install the Skill in the current project, run:

npx skills add HammingDev/haiming-app-monetization --agent codex --yes

--agent codex specifies the target Agent, while --yes automatically confirms the installation.

Install Globally for Codex

To use it across multiple projects, install it globally:

npx skills add HammingDev/haiming-app-monetization --agent codex --global --yes

During interactive installation, you can also select another supported Agent. The capabilities available in practice depend on whether the running Agent has tools for reading the project, running the app, or conducting internet research.

Basic Usage: Run a Full Monetization Evaluation

After installation, enter the following in the task associated with your app project:

Use $haiming-app-monetization to evaluate the current project, research relevant competitors,
and provide plan pricing, personalized onboarding, and paywall proposals. Do not modify the code yet.

This instruction includes several important constraints:

• Evaluate the current project: Requires the Agent to base its work on the real project structure and existing implementation.
• Research relevant competitors: Adds external market information when the available tools permit.
• Provide a complete proposal: Covers pricing, onboarding, and paywalls.
• Do not modify the code yet: Keeps the work read-only for easier review of the direction first.

It is recommended to start in this evaluation mode. You can check whether page locations are accurate, competitors are relevant, and candidate prices include the region and billing period before deciding whether to proceed to implementation.

Focus on a Single Area

If you only need to review the paywall, you do not need to request a full monetization analysis. You can enter:

Use $haiming-app-monetization to review the membership benefits, trial details, and purchase flow of the current paywall.

This approach is suitable for a clearly defined task, such as when the paywall is already live but you need to investigate the following issues:

• Whether the membership benefits are easy to understand.
• Whether the trial conditions are clearly stated.
• Whether the featured plan is clear.
• Whether the purchase entry point and flow are coherent.
• Whether the next step after completing a purchase is clear.

The same approach can be used to focus on onboarding or plan design, but the task should clearly state which area you want reviewed and what output you expect.

Switching from Evaluation to Implementation

By default, the Skill does not modify product code. After reviewing a proposal, you must explicitly request “evaluate and implement” if you want the Agent to put it into practice.

Use $haiming-app-monetization to evaluate and implement onboarding and paywall improvements for the current project. First locate reusable components and explain the required changes, then implement them and provide validation steps.

Because the README only defines the boundary that implementation requires an explicit request, the actual scope and outcome depend on the project structure, existing code, and the Agent's tool capabilities. Before implementation, save the current state in version control and review the files proposed for modification by the Agent.

Using the Skill Without Source Code

When no project source code is available to read, you can provide the Agent with product descriptions, screenshots, or screen recordings. To improve analysis quality, the materials should cover at least:

• The product's target users and primary purpose.
• The current onboarding screen order and copy.
• The differences between free features and membership benefits.
• Existing plans, currencies, billing periods, and trial rules.
• The path from opening the paywall to completing a purchase.

In this situation, the Agent cannot locate actual code positions. Its output should therefore be treated as product-level guidance rather than an engineering conclusion that has already been verified.

Advanced Usage Tips

Specify the Region, Currency, and Billing Period

When requesting pricing research, specify the target market. For example, you can ask the Agent to prioritize a particular region and organize monthly, annual, or other billing periods separately. Even when you do not specify them up front, the final results should include the region, currency, period, source, and unknowns.

Require a Distinction Between Static Analysis and Runtime Observation

If the Agent can only read code and cannot launch the app, it should not present inferences as user experiences that have already been observed. Add the following to your instruction:

Please label which conclusions come from static source-code analysis and which come from actual runtime observation; list anything that cannot be verified as an unknown.

Ask the Agent to Prioritize First

When there are many issues, ask it to organize them by priority instead of modifying everything at once:

Please identify issues in onboarding, the paywall, and the purchase flow, rank them by impact and implementation cost, and propose the first experiment without modifying the code.

The README states that the output should include priority issues, required changes, and initial experiments. This task structure helps turn recommendations into subsequent development work.

Make Onboarding Choices Affect Subsequent Content

When designing personalized onboarding, do not merely collect user choices. Require each choice to map to a different demonstration, highlight, or piece of copy so that the branch is visible and meaningful to the user.

Review the Next Step After Purchase

Paywall evaluation should not stop at the payment button. Also confirm what users will see after completing a purchase, which feature they will enter, and how they will understand the membership benefits they have just unlocked.

Review Conclusions Before Handing Them to a Development Agent

Before moving to implementation, confirm:

1. Whether the page and code paths actually exist.
2. Whether competitor prices include their sources and verification status.
3. Whether the trial details match the actual rules.
4. Whether the featured plan and membership benefits are clearly presented.
5. Whether the scope of changes aligns with the goals of the current version.
6. Whether the initial experiment has verifiable results.

Capability Boundaries and Version Status

The current version is v0.1.0 and has passed Skill format validation. Its methods have completed static evaluation and competitor research in the Life Widget project, but they have not yet been shown to improve conversion rates in practice.

Internet research and project access depend on the tools available to the running Agent. When internet access is unavailable, the Skill marks prices as unverified. When the app cannot be run, static judgments and runtime results should also be kept distinct. The repository itself does not include project source code or private collaboration briefs.

The Skill's entry file is SKILL.md, and behavioral acceptance references are located at references/acceptance.md. The project uses the MIT license, which permits use, modification, redistribution, and commercial use, but distributions must retain the copyright notice and license.

Summary

haiming-app-monetization organizes app monetization analysis into a workflow that an AI Agent can execute: read the existing implementation, research competitors, design branching onboarding, organize plans and paywalls, and plan implementation and initial validation. The recommended practice is to begin with a read-only evaluation, review sources, unknowns, and the scope of changes, and then enter the development phase with an explicit “evaluate and implement” instruction.