Version 0.1.0 reviews a product; it does not supply billing code
Haiming App Monetization is a Chinese-language instruction package for an AI coding agent. Version 0.1.0 tells the agent to inspect an app's real onboarding, value demonstration, paywall, product selection, purchase, and entitlement flow. It can also work from screenshots or a product description when code is unavailable. The repository has no English documentation. Its intended output is a Chinese Markdown assessment that another developer or agent can continue implementing.
The distinction saves a bad comparison. RevenueCat, StoreKit, and Superwall execute purchases or present paywalls; this skill reasons about how your existing screens and products fit together. It ships no mobile source code, backend, analytics collector, or store connection. If your bug is a failed receipt validation, you still need the app's payment stack and platform tools. Haiming may help an agent find that path, but its own four working files cannot process a transaction.
Five acceptance scenarios reward careful claims
The acceptance document defines five cases. They cover a lightweight app, incomplete evidence, conflicting prices, an AI product with continuing costs, and a blocked purchase flow. Each case states mistakes the agent should avoid. A monthly trial for one feature must not become a claim that every feature is free. An old local lifetime price must not override the public store price. A cancelled purchase must not be collapsed into a pending one.
That discipline is the project's best reason to use it. The skill asks the agent to label code facts, public sources, runtime observations, owner experience, and hypotheses separately. Competitor research must record region, currency, period, date, and link. Missing network access means a price stays unverified. Those rules prevent a polished report from laundering guesses into facts, which is a common failure when agents advise on products they cannot open or purchase.
What happened when we ran it
The lab found no supported ecosystem and no Dockerfile at commit 271d8ab. There is therefore no install time, build result, test count, dependency footprint, or vulnerability audit to report. The repository tree contains a README, SKILL.md, one agent descriptor, one acceptance document, a license, and a gitignore. Calling it unbuildable would miss its nature: the published artifact is text meant to be loaded by another agent.
The documented command is npx skills add HammingDev/haiming-app-monetization, with flags for Codex and global installation. That command belongs to an outside skill installer, and the lab result does not verify it. More importantly, installation proves little about the advice. A useful evaluation needs an authorized app, current store listings, and preferably a payment sandbox. None of those materials are included in this 17 KB GitHub repository.
Read-only assessment is the default permission boundary
The skill instructions tell the agent to assess without changing code unless the user explicitly asks for implementation. Even then, permission to edit does not authorize an app-store release, a live price change, or an actual purchase. The agent should preserve existing work, inspect only relevant files, and avoid sweeping reads of secrets or user data. Those are sensible boundaries for a tool invited into a revenue path.
The workflow also resists automatic paywall recipes. It does not assume every app needs weekly and annual plans, a hard paywall, a questionnaire, or an unlimited lifetime tier. Continuing AI costs must be considered before recommending lifetime access. Trials and renewal copy must match the selected store product at runtime. These instructions are more grounded than a generic growth prompt, though their quality still depends on whether the host agent traces the live code path correctly.
One static case is evidence of process, not conversion
The repository records one Life Widget exercise. With the project owner's permission, the method performed a static path review, public competitor research, and plan generation. The underlying app and report are absent. The acceptance note explicitly says this does not prove an independent packaged invocation, a completed transaction, or higher paid conversion. That is the correct interpretation of the only validation claim v0.1.0 provides.
Measurement advice inside the skill is sound on paper. It separates paywall purchase rate, new-user paid rate, trial starts, trial-to-paid conversion, renewals, refunds, and retention. It also asks for a denominator, deduplication rule, user segment, and observation window. Yet no dataset or experiment result accompanies those instructions. You are buying a better checklist, under the MIT license, rather than a demonstrated growth system.
Five commits and one issue make this an early project
GitHub showed 257 stars and one open issue on October 2, 2026. The repository was created September 9 and last pushed September 10 after five commits. The latest-release endpoint returned no tagged release even though the metadata says v0.1.0. The open issue is a positive AutoClaw exercise using a fictional focus-timer app, which tests report generation rather than a real purchase or commercial outcome.
Try Haiming when you already have an app, can give an agent narrow read access, and want a Chinese product review before touching the paywall. Keep the final decision with someone who can inspect store configuration and run the purchase states on device. If you need code that sells a subscription today, install a payment SDK first; this skill only helps decide what the experience around that SDK should say and do.