Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx skills add AnilBurcu/claude-code-react-native --skill in-app-purchasesgit clone --depth 1 https://github.com/AnilBurcu/claude-code-react-nativeWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/anilburcu/claude-code-react-native/in-app-purchases)<a href="https://agentmods.dev/skills/anilburcu/claude-code-react-native/in-app-purchases"><img src="https://agentmods.dev/badge/skills/anilburcu/claude-code-react-native/in-app-purchases.svg" alt="Measured on agentmods" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00064 | $0.01111 |
| Opus 5 | $0.00032 | $0.00556 |
| Sonnet 5 | $0.00013 | $0.00222 |
| Haiku 4.5 | $0.00006 | $0.00111 |
Grade A, and why
in-app-purchases scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 7d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 52 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Subscriptions without 2 AM incidents
The architecture rule everything else hangs on
Entitlement truth lives on your server, not in the client. The purchase SDK tells the client "probably premium" fast; the webhook pipeline tells your database "actually premium" reliably. The client renders from server state and treats its local SDK state as an optimistic hint.
Every horror story in this domain is a variation of trusting the client: premium flags in AsyncStorage, entitlement checks that only run at purchase time, or webhook handlers that were never verified against replay.
RevenueCat wiring that holds up
- Identify the user to the SDK with your own auth user id after sign-in. Anonymous ids merging into identified ids is where "user bought on the wrong account" tickets are born.
- Configure once at startup with the platform key; render from
customerInfolisteners rather than one-shot fetches, so a purchase completing in the background updates the UI without a restart. - Decide your transfer policy consciously. "Transfer to new app user id" versus blocking transfers changes what happens when one store account signs into a second app account. Whichever you pick, enforce ownership rules in your own database guards; the SDK setting alone is not a policy.
- Restore purchases must be a visible button (App Store review expects it) and must resolve through the same server-side reconciliation as a fresh purchase.
Webhooks: the part that must be boring
- Verify the sender on every request: at minimum compare the Authorization header against your configured secret; where the provider offers HMAC-signed webhooks, prefer verifying the signature. An unverified webhook endpoint is an open "make me premium" API.
- If the endpoint runs on a platform that enforces its own auth by default (Supabase Edge Functions and their JWT verification, for example), remember the store's webhook sender cannot present your platform's JWT. Shared-secret endpoints must have platform JWT verification disabled and their own secret check enabled, or every event bounces with 401 and premium "never arrives".
- Deduplicate by event id. Webhook senders retry; your handler will see the same event twice on a bad day.
- Store the environment (SANDBOX vs PRODUCTION) on every event and subscription row, and filter sandbox out of admin dashboards and metrics. Mixed environments make revenue numbers lie.
- Reconcile, don't accumulate: handlers should upsert the subscription to the state the event describes, so replays and out-of-order deliveries converge instead of corrupting.
- A runtime-neutral handler skeleton with the dedupe and transaction contracts spelled out is in reference.md.
What ships with it
1 file beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 7d ago First seen · 52 lines · 64 tokens per session scan A 948064f2d8c1
in-app-purchases is a skill published in the GitHub repository AnilBurcu/claude-code-react-native (3 stars, last pushed 1mo ago), licensed MIT. It adds 64 tokens to every session and 1,111 once invoked, about $0.0003 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other skills, from other repositories
expo-56
Authoritative, version-pinned reference for Expo SDK 56 and SDK 57 — both postdate your training, so defer to this skill over memory for anything Expo. SDK 57 is the current release (2026-07-08, React Native 0.86); SDK 56 is the previous, still-supported release (React Native 0.85). Use it whenever the user is…
expo
Use when shipping a React Native app with Expo — EAS Build/Submit/Update, eas.json profiles and channels, config plugins, prebuild/CNG, runtime-version policy, OTA updates that never land, SDK upgrades, the New Architecture. NOT RN UI, navigation or native-module authoring (that is react-native), NOT a Dart app (that…
rn-publishing-payments
Use when preparing an Expo + RN app for store submission (metadata, screenshots, localized listings, privacy nutrition label, age rating) and integrating monetization (In-App Purchases via RevenueCat for digital goods/subscriptions; Stripe via WebView ONLY for non-digital services). Triggers on: "submit to App Store"…
revenuecat
Integrate RevenueCat for in-app purchases — consumable credit packs or subscriptions. Use when setting up RevenueCat, creating products in App Store Connect / Google Play, configuring the SDK, building a paywall, or handling purchase webhooks in Supabase Edge Functions.
expo-launchpad-evaluator
Phase A, step 6 — skeptical QA. Run the app, watch it, then judge against the contract. Default = functional check; --strict adds quality scoring and an edge-case sweep.
expo-launchpad-contract
Phase A contract — propose the 8 Mandatory Hard Gates, the Platform-Robustness Gates (R1–R11), and 5–10 Functional Criteria derived from the PRD; mark the contract AGREED (1-pass default, rigorous self-review in --strict) and advance the pipeline to generator.