Subscriptions are the part of a mobile app nobody wants to build and everybody has to — SDK wiring, paywall UI, store config, then the ads and tests that make it pay.
These skills hand that whole surface to the agent you already have open.
> /adapty-integration
Detected Flutter — pubspec.yaml, ios/ and android/ present
? Paywall approach → Flow Builder (no-code editor)
? Integrations → Amplitude, AppsFlyer
? Adapty app → Create a new one
Creating app, access level, products and placement via the Adapty CLI…
Fetching flutter-sdk-overview docs before writing Stage 1…
Supported platforms: iOS · Android · Flutter · React Native · Unity · Kotlin Multiplatform · Capacitor
Every install below gives you the whole toolkit — and it grows, so an update brings new skills with it.
| Skill | What it does | Needs |
|---|---|---|
adapty-integration |
Sets up in-app purchases end to end — dashboard, SDK, paywall, store config — or moves you over from another purchase system | Adapty CLI |
adapty-attribution |
Reads your Adapty Attribution data: which channels, campaigns, ads and countries pay back, trial quality, weekly changes, predicted payback, and why an ad network's numbers differ from Adapty's | Adapty CLI, Adapty Attribution |
ads-manager |
Runs your Apple Search Ads: performance across campaigns and keywords, bid and budget changes, search-term harvesting, campaigns on and off | Adapty CLI, Apple Ads account |
flow-audit |
Answers "did I forget anything?" before you publish a flow — triggers, products, variables — with a verdict and ranked fixes | Adapty CLI |
flow-generator |
Builds a paywall or onboarding flow, or changes one you have: translate it, rewrite the copy, add or reorder screens, add tabs and plan pickers, wire quiz branching | Adapty CLI |
migrate-placements |
Moves an app from paywall placements to flows — creates the new flow placements alongside your existing ones and hands back the old→new mapping and the one call to change | Adapty CLI |
onboarding-teardown |
Reads an onboarding flow — described, screenshotted, or as a config — and ranks what to change and test, seam with the paywall included | nothing |
paywall-teardown |
Reads any paywall — yours, a competitor's, a work in progress — and ranks what to change and test | nothing |
The Adapty CLI comes from npm install -g adapty. You don't have to keep it current — the skills check the version themselves and fetch a newer one when they need it, rather than telling you a command doesn't exist.
claude plugin marketplace add adaptyteam/adapty-skills
claude plugin install adapty-skills@adaptyThen run /reload-plugins inside Claude Code. One plugin, adapty-skills, carries every skill in the repo.
Already installed as adapty-sdk-integration?
That handle still works and still updates, so nothing breaks if you do nothing. To move over, install the new one and remove the old one — leaving both installed loads the same skills twice:
claude plugin install adapty-skills@adapty
claude plugin uninstall adapty-sdk-integration@adaptyThe skill you invoke is now /adapty-integration (previously /adapty-sdk-integration).
codex plugin marketplace add adaptyteam/adapty-skills
codex plugin add adapty-skills@adaptyThen start a new thread, so Codex picks up the skills. One plugin, adapty-skills, carries every skill in the repo.
To pull later changes:
codex plugin marketplace upgrade
codex plugin add adapty-skills@adaptyThe skills CLI installs into any supported agent — Cursor, Copilot, Codex, Gemini CLI, Zed, Amp, and more:
npx skills add adaptyteam/adapty-skills --all--all is --skill '*' --agent '*' -y: every skill, every agent it detects, no prompts. Drop it and the CLI asks which ones you want, which is fine at a keyboard but hangs in a script.
For one skill only, name it:
npx skills add adaptyteam/adapty-skills --skill ads-managerSkills installed this way don't update automatically. To get the latest later:
npx skills updateThe skills are portable directories under skills/, and every CLI below reads the same Claude-style SKILL.md format — so copying them into place works. The skills/* glob takes all of them.
GitHub Copilot CLI — docs:
git clone https://github.com/adaptyteam/adapty-skills.git
cp -r adapty-skills/skills/* ~/.copilot/skills/OpenAI Codex CLI — docs. The plugin is the better route unless you want one project scoped to its own copy. Use ~/.agents/skills/ for personal, <repo>/.agents/skills/ for project:
git clone https://github.com/adaptyteam/adapty-skills.git
cp -r adapty-skills/skills/* ~/.agents/skills/Gemini CLI — docs:
gemini skills install https://github.com/adaptyteam/adapty-skills
# or manually:
git clone https://github.com/adaptyteam/adapty-skills.git
cp -r adapty-skills/skills/* ~/.gemini/skills/Working in-app purchases: dashboard, SDK code, paywall, store config. Open your mobile project in your agentic CLI and run:
/adapty-integration
(In CLIs that don't map slash commands to skills, "Use the adapty-integration skill" does the same. That holds for every skill below.)
The skill takes over from there. It will:
- Detect the platform from the project structure
- Ask three questions — paywall approach, third-party integrations, and whether to use an existing Adapty app or create a new one
- Configure the Adapty dashboard via the Adapty CLI
- Implement the SDK stage by stage, fetching the latest docs before writing each piece of code
- Verify each step with build checks and visual checkpoints before moving on
You'll be asked for your Adapty credentials and a few decisions along the way — the rest is automated.
- Flow Builder (recommended) — Adapty renders paywalls and onboarding in a no-code editor; nothing to build. On Unity and Capacitor this is Paywall Builder, the previous generation, which does paywalls only
- Custom paywall — you build the UI; Adapty provides products and handles purchases
- Observer mode — keep your existing StoreKit / Billing code; Adapty tracks events only
An analyst on your Adapty Attribution data, measured against the subscription revenue Adapty holds for every user.
Open your terminal in any directory and ask for it:
/adapty-attribution
It carries ten playbooks: ranking channels and campaigns by payback and deciding where budget goes, judging a young campaign at a horizon it has actually reached, trial-to-paid quality by campaign, a weekly digest with week-over-week flags, countries and stores, the winning ads inside a campaign, refund-heavy traffic, predicted payback, reconciling an ad network's numbers with Adapty's, and diagnosing a drop in installs.
It only reads. Every call goes through adapty attribution, which changes nothing. Apple Search Ads spend is not collected by Attribution, so the skill reads it through Ads Manager and reports it on its own line, in its own currency. Setup questions — connecting Meta, TikTok or Google Ads, tracking links, the web pixel, Stripe or Paddle — go to the docs pages that own them.
An analyst on your ad account — bids, budgets, keyword harvests, dead-ad diagnosis.
You need a connected Apple Search Ads account and an active Ads Manager subscription — adapty asa whoami tells you where you stand.
Open your terminal in any directory and ask for it:
/ads-manager
It covers ten workflows: orienting on your account, reporting performance, launching a campaign (seeded from Adapty's keyword recommendations when you have no keyword list), harvesting keywords from search terms, a bid-and-budget optimization pass, pausing or resuming, running ads against a custom product page, diagnosing an ad that isn't serving, rule-based automations, and a competitor check.
It treats your ad account as live money. There is no delete and no undo in this surface, so the skill confirms before every write, never invents an ID or a budget, prefers small keyword batches, and pins idempotency keys so a re-run can't double-apply. Reads and automation dry runs are free, and it uses them freely.
The broken product binding, caught before your users find it. flow-audit answers one question: is this Flow Builder flow ready for production?
It's read-only. It never calls flows config update, products create, or flows create — it fetches the flow's config and cross-references it against your live dashboard (catalog, access levels) to catch what an offline checker can't, like a bound product that doesn't exist or a card whose copy claims a period the product doesn't have.
/flow-audit
(Or "audit my flow" / "is this ready to publish?")
It checks six families — triggers, store compliance, products, variables, localization, and placeholders — plus whether any placement shows the flow, and comes back with a plain-language verdict (Ready to publish, Not ready to publish yet: n things to fix first, or Almost ready: n things I could not check), numbered findings that each say what is wrong, why it matters to a real user, and how to fix it, and a What happens next section: what to answer first, what the agent can fix for you, and what only you can do in the dashboard. It answers in your language.
It never certifies what it couldn't see. A question it can't answer from the data — can the host app dismiss this paywall on its own, are your products approved in App Store Connect — keeps the verdict from reading a bare Ready to publish until you've weighed in. When you want something fixed, it offers to do it and hands the findings to flow-generator, which owns the actual write.
Describe the screen you want and get it built — or change one you already have, without opening the editor. flow-generator writes an Adapty Flow Builder flow as JSON.
It authors new flows, and it transforms flows that exist. Authoring is what most people reach for: product IDs come from your catalog (it asks which to use before designing anything), and the only things it will never invent are uploaded images and videos, real store prices, and proof numbers like ratings — those it asks you for, or leaves visibly out. Transforming your own flow is the safer path when you have one — theme, fonts, locales and products are inherited, so everything the skill writes is real.
It reads and writes the config through the Adapty CLI, so you don't export or upload anything by hand, and it sorts out the CLI itself rather than telling you a command doesn't exist.
/flow-generator
It runs five phases: authenticate, work out whether to create a flow or edit an existing one, validate the config, preview it and iterate until it looks right, then save and ask before it publishes. Validate and preview both run on a local file, so the agent gets it right before anything reaches your dashboard.
Four transforms:
- Add a locale — extend the flow's locales and fill in every localizable field
- Rewrite copy — change wording without touching structure
- Screens — add, remove, or reorder, repairing the navigation that a deletion breaks
- Branching and conditions — selectable groups, option IDs, and the conditional actions that route on them
It saves to a draft; publishing is a separate word from you. A newer CLI has a publish command, but the skill never folds it into a save — it asks first. And the publish endpoint isn't in production yet, on any account, so for now it hands you the editor's publish button instead. There is no delete command at all, so removing a flow stays yours. Every write after the first carries the flow's updated_at as an optimistic lock, so a save can't quietly overwrite an edit someone else made in the meantime — it fails instead. It asks before creating a product. And because a config can save cleanly and still not render, the agent screenshots the preview and looks at it before telling you it's done.
You have placements pointing at paywalls, and you want them pointing at flows instead. migrate-placements reads every placement in the app, works out which ones are worth moving, and creates the flow placements for you.
/migrate-placements
None of this is in production yet, on any account — neither the publish endpoint nor the placement audience a flow needs — so the skill probes for the capability first and, until it ships, hands you Placements in the dashboard instead of a half-finished migration.
Placements are created, never converted. A placement's content type is fixed the moment it exists — the backend refuses a change — so there is no in-place upgrade to be had. Every migration is a new placement standing next to the old one.
That shape is what makes it safe: your paywall placements are left untouched, and that is the rollback. Ship the new call, and if anything looks wrong, point the app back at the old ID — nothing was taken away.
The cost is the ID. A new placement cannot reuse the old developer ID (IDs are unique across every placement in the app, whatever its type) and a placement cannot be deleted, so a name you regret is permanent. Every proposed ID is shown to you for approval before anything is created.
One flow per distinct paywall, reused across every placement that pointed at it — two placements sharing a paywall get one flow, not two. You get back the old→new mapping, and the single call in your code that has to change.
The migration is not done when the placements exist. Nothing reaches users until the app ships the new call, so the last row of the report is yours.
A screenshot turned into a ranked list of things to test. Like onboarding-teardown, it needs no CLI, no account and no credentials — it reads what you give it and writes nothing anywhere.
Paste a paywall screenshot and say roughly nothing:
/paywall-teardown
(Or just drop the image in — "here's my paywall" is enough.)
You get back a read of the vertical and its trust axis, a line on what's already working, and 5–8 prioritized rows: the named pattern, the specific change applied to your screen, where that pattern shows up across categories, and an expected-impact range. It handles competitor screenshots and half-finished designs too.
It also works forwards. Ask for a paywall instead of a critique of one — or hand an agent "add a paywall screen" with no design attached — and the library becomes the reference the agent designs against: a build list of the patterns that belong on the screen for your category, in priority order, plus the short list of real values it refuses to invent for you (your actual rating, your actual review count, your actual outcome data, your hero asset). Then it grades the result and fixes what it finds, rather than handing you a report on a screen it just built. flow-generator calls it at both ends for exactly this — before it writes the config, and again over the render — so a generated screen is held to the same library a live one would be. If you do give a design reference, that reference wins; the library only fills what it leaves unsaid.
Impact ranges are expected effect calibrated from Adapty's teardowns of top subscription apps across many verticals — not measured lift for your app. Ship the tests and get your own numbers.
The same treatment, one level up: the sequence rather than the screen. It needs no CLI, no account and no credentials either.
Onboarding is a sequence, and that is the one thing a screenshot cannot show — so this one starts with a short interview instead of an upload:
/onboarding-teardown
Six questions, one at a time, each answerable with a tap or a line: your category, how long the flow is, what the first screen is, whether you ask what users want and give them something personalized back, when the paywall appears, and when you ask for permissions. Answer three of six and it still delivers.
You get back your flow written out as a line (often the first time anyone has seen it that way), what's already working, 5–8 prioritized rows, and a paragraph on the seam — whether the paywall reflects what onboarding just spent five screens capturing. That seam is where the expensive findings live: a goal question with nothing behind it, a loader promising a personalized plan that the next screen doesn't deliver.
Hand it a flow config and it stops interviewing. The sequence, the branching, the goal capture and the paywall's position are all in the file; it reads them and asks only what the JSON cannot say — your category, and whether the app truly delivers the payoff the flow promises.
It also works forwards, the same way its paywall counterpart does. Ask for an onboarding rather than a critique of one and the library becomes the reference: a skeleton chosen for your category from what your app can actually back, a per-screen build list, and the short list of things it refuses to invent — a projected outcome nobody modelled, real proof numbers, an asset nobody has a file for. flow-generator calls it at both ends, so a generated sequence is held to the same library a live one would be.
One constraint it will tell you about rather than quietly working around: a flow cannot request a permission. It can render the soft prompt that makes the ask land better, but the system dialog belongs to your app code — so permission-timing findings arrive as a handoff, not as something the builder can ship for you.
- An agentic CLI that supports the Claude Skills format — Claude Code, GitHub Copilot CLI, OpenAI Codex, or Gemini CLI
- An Adapty account (free tier works)
Adapty SDK overviews: iOS · Android · Flutter · React Native · Unity · Kotlin Multiplatform · Capacitor
If your agent runs somewhere with restricted outbound network access — Claude Cowork on a corporate plan, a managed sandbox, an egress proxy — an administrator has to allow both:
adapty.io
*.adapty.io
List both. A wildcard does not cover the apex domain in most allowlist implementations, and the apex is where almost everything goes: the skills fetch documentation from adapty.io/docs/... (the large majority of requests), the dashboard is app.adapty.io, and the Adapty CLI talks to api-admin.adapty.io and, for Apple Search Ads, api-asa-admin.adapty.io. Allowing only *.adapty.io blocks the docs the agent reads before writing any code.
adapty-integration is the only skill here that sends anything back. At the end of a successful integration it asks whether you'd like to share anonymous signals — platform, steps completed, rating — with no code, no project details and nothing identifying. Say no and nothing is sent. Every other skill here collects nothing at any point.