Update to RevenueCat

{
  "name": "revenuecat-paywall-design",
  "description": "Must invoke for any request to create, edit, evaluate, understand, or improve a RevenueCat Paywall in the dashboard — including questions about a specific paywall or general paywall design recommendations. Not for presenting a paywall in app code (use revenuecat-paywall).",
  "included_files": [],
  "skill_md_contents": "---\nname: revenuecat-paywall-design\ndescription:\n  Must invoke for any request to create, edit, evaluate, understand, or improve a RevenueCat\n  Paywall in the dashboard — including questions about a specific paywall or general paywall\n  design recommendations. Not for presenting a paywall in app code (use revenuecat-paywall).\n---\n\n# Designing and editing RevenueCat Paywalls\n\nThis skill covers the **dashboard paywall**: creating, duplicating, editing, auditing, and\npublishing. To **display** a configured paywall in the app with RevenueCatUI, use\n`revenuecat-paywall` instead.\n\nPaywall advice requires a paywall. An offering whose `paywall_id` is null has no RevenueCat\npaywall: its purchase UI is client-side and invisible to you. Say so, and keep your advice to\nwhat RevenueCat actually controls.\n\nVia the `rc` CLI (see the `revenuecat-cli` skill): `rc paywalls generate --prompt \"...\"`,\n`rc paywalls edit --prompt \"...\"`, `rc paywalls rewind --session <id>`, `rc paywalls publish`,\n`rc paywalls show`. Prefer MCP below when you need screenshots or a structured `get-paywall`\nread.\n\n## Evaluating a paywall\n\nWhen evaluating a RevenueCat Paywall, use `render-paywall-screenshot` to look at a static render\nof above-the-fold content. The render is for you, not something to display to the user.\n\nFor a specific identified paywall, match the tool to the question:\n\n- **Exact configuration** (default package, component bindings, offer-conditional content):\n  `get-paywall` with `expand: [\"components\"]`. Without that expand, component configuration is\n  omitted.\n- **Visual inspection**: `render-paywall-screenshot`. A screenshot cannot verify\n  configuration-dependent details.\n- If a tool answer conflicts with what the user reports seeing, verify with `get-paywall` before\n  disputing their observation; if `get-paywall` is unavailable, say you could not verify rather\n  than disputing them.\n\nBoth `get-paywall` and `render-paywall-screenshot` use the draft when available, otherwise the\npublished version, and cover one paywall — not workflows or multipage paywalls. For general\npaywall advice that is not about a specific paywall, answer directly without calling these tools.\n\nIf `get-paywall` fails, you may still report observations explicitly visible in a screenshot.\nState that configuration-dependent details were not verified; do not silently replace\nstructure-aware analysis with screenshot reasoning.\n\n## Editing\n\nWhen the user explicitly asks you to edit an existing paywall, use `edit-paywall-ai`. It starts\nan async task: poll `get-paywall-ai-task` with the returned task ID about every 10–15 seconds\nuntil it succeeds or fails. Do not call `edit-paywall-ai` again for the same request unless the\ntask fails. Image-generation edits can take several minutes.\n\nIf the user wants to edit manually, link to the paywall builder:\n\n```\nhttps://app.revenuecat.com/projects/{project id without leading proj prefix}/paywalls/{paywall ID starting with pw}/builder\n```\n\nThe builder also has a conversational AI editor in the left toolbar; you cannot link to it\ndirectly.\n\nIf the user attaches images to the current message and the tool schema accepts them, pass them\nthrough and tell the editor how they should be used. Do not reproduce visual details\nunnecessarily. Images from earlier messages are not still attached — ask the user to attach\nagain.\n\nMCP has no restore-version tool. If the user asks to undo an edit you made via MCP, tell them\nthey can restore an older version in the paywall editor. If they used the CLI, `rc paywalls rewind --session <id>` undoes the last editor action. Restoring does not publish.\n\n## Duplicating\n\nWhen the user asks for a paywall that copies, duplicates, or mirrors an existing one, use\n`duplicate-paywall` rather than `create-paywall-ai`. `create-paywall-ai` designs from a blank\ncanvas and a text prompt, so it reproduces only what the prompt describes: images, exact\ncomponent structure, and anything unmentioned are regenerated rather than copied.\n\n`duplicate-paywall` copies the source paywall — its current draft by default, or its published\nversion if you pass `source_version: published` (fails if the paywall has never been published)\n— into a new unpublished paywall. Choose deliberately:\n\n- When the source has a published version (`get-paywall`'s `published_at` is non-null), pass\n  `source_version: published` — that is the paywall the user means when they reference one by\n  name or link.\n- Take the `draft` default only when the user is explicitly asking to copy in-progress\n  unpublished edits, or the source has never been published.\n\nSay which version you copied. Pass `offering` (`lookup_key` and `display_name`) to also\nduplicate the source paywall's offering — packages only — and attach the copy to it; omit\n`offering` to leave the copy unattached. When the user's framing is offering-first — a second\noffering that should carry the same paywall — use `duplicate-offering` instead, which copies the\npackages and the attached paywall together. Then apply differences with `edit-paywall-ai`, and\ndescribe the result as a copy of the original rather than as a new design.\n\nDuplication does not cover every paywall — multipage paywalls are not supported. If duplication\nis unavailable or fails, you may fall back to `create-paywall-ai`, but tell the user the result\nis a reconstruction from a description, not a copy, and that details such as images will differ.\n\n## Creating\n\nWhen the user asks you to create a new paywall, use `create-paywall-ai` to create a **draft\nonly**. It starts an async task: poll `get-paywall-ai-task` about every 30 seconds until it\nsucceeds or fails. Image-heavy creation can take 5–10 minutes; do not call `create-paywall-ai`\nagain for the same request unless the task fails.\n\nPrefer creating the paywall for an existing offering when the user names one or when you can\nconfidently identify a suitable offering. If they do not name an offering, use `list-offerings`,\n`get-offering`, `get-offering-prices`, `list-products`, `list-apps`, `get-app`,\n`get-project-ui-config`, and `list-paywalls` to understand the app, products, pricing, brand\nconventions, and existing paywalls first. Inspect the app/codebase and pass concise\n`codebase_context` (premium features, brand colors, visual direction, tone, products, audience)\nand `app_context` when you can infer it. Recommend the best offering when there is a clear fit;\nif the user declines or no clear offering is known, create an unattached draft.\n\nAn offering can have at most one attached RevenueCat Paywall. If the offering has a\n`paywall_id`, do not pass that offering as `offering_id` to `create-paywall-ai`. Explain that it\nalready has a paywall, and pick the option that matches:\n\n- The new paywall should look like the existing one: duplicate it. This is the right choice\n  whenever the user said \"same as\", \"like\", \"copy\", or \"mirror\".\n- The existing paywall should change: `edit-paywall-ai`.\n- The new paywall is a genuinely different design: choose a different or unattached offering, or\n  create an unattached draft using the offering's products and pricing as context.\n\nDo not present an unattached `create-paywall-ai` draft as the way to satisfy a duplication\nrequest.\n\nFold gathered context into the prompt: app identity, target audience, core value proposition,\nproduct durations, trials, price points, existing paywall patterns, brand colors or fonts, and\nany user-stated design direction. Keep the prompt concrete enough for a one-shot draft and do\nnot ask the tool to publish.\n\nA duplicated or newly created paywall is an unpublished draft. Do not publish unless the user\nexplicitly asks, except when preparing a treatment offering for an experiment (see\n`revenuecat-experiments`).\n\n# Overall ideas and guidance\n\n## Collecting ideas\n\nSearch the RevenueCat blog and docs for paywall design and best practices. Markdown docs are at\nthe page URL with `.md` appended.\n\n## Disallowed practices\n\nApple's App Review guidelines are strict. Patterns often touted as best practices can lead to a\nrejected update or a store ban:\n\n- **Trial toggle.** A toggle to enable/disable the trial. Apple rejects this as misleading.\n- **Delayed close button.** A dismissible paywall that cannot be closed for a few seconds.\n  Apple considers this misleading.\n- **Second offer on dismiss / purchase cancel.** Least clear of the four; showing the exact\n  same product after cancelling has been rejected as tricking users into unwanted purchases.\n- **Non-IAP digital goods in-app.** Stripe or other non-IAP SDKs in the app or an in-app\n  webview for digital goods. Linking out to web purchases in an external browser is a different\n  (US) path; the purchase must not happen inside the app.\n\n## Paywall placement\n\nTry different placements: beginning or end of onboarding, as a feature gate, etc. Onboarding\npaywalls tend to be very successful: they capture the highest number of potential customers\n(nobody has churned yet) and motivation is high just after download.\n\n## Always experiment\n\nResults of different paywall designs are highly variable. Continuously test. At thousands of\nnew users per day, A/B testing with RevenueCat Experiments is the best validation. At hundreds\nper day, tests can still be directional. Below that, ship and observe conversion over time. Use\nthe `revenuecat-experiments` skill to set up a test.\n\n# Auditing existing paywall designs\n\nAnalyze the paywall and identify conversion issues. Prioritize conversion over aesthetic\nconsistency when they conflict. Audit in this order of impact.\n\n### Visual issues (highest impact — fix these first)\n\n**CTA Button** — single highest-impact element, address this FIRST.\n\n- **CTA color is the #1 priority.** Look at the CTA button background color, then scan every\n  other colored element (icons, badges, borders, card accents). If the CTA shares the same hue\n  as ANY of them, it must change to a contrasting color that nothing else on the page uses. A\n  CTA that blends in with the page accent kills conversion.\n- If the CTA copy is generic (\"Continue\", \"Subscribe\"), it needs to be specific and\n  action-oriented (e.g. \"Start Yearly Plan\", \"Get Unlimited Access\").\n- If a free trial exists and the CTA does not mention it, the CTA should include trial language\n  (e.g. \"Start Free Trial\", \"Try for Free\"). Trial info buried in small print is a conversion\n  miss.\n\n**Plan Card Differentiation**\n\n- The recommended plan MUST be impossible to miss. It needs at least TWO of: a different\n  background color, a colored border, a \"Best Value\" / \"Most Popular\" badge, or a larger/\n  elevated card. A single subtle border change is not enough.\n- If there is no default plan selected, one needs to be set.\n- Equal-weight cards cause decision paralysis — differentiate the recommended plan.\n- If a badge overlaps text, the selection indicator, or other content, reposition it.\n\n**Price Anchoring** — required when multiple plans exist.\n\n- If savings are not immediately visible (no crossed-out price, no \"Save X%\", no per-day\n  comparison), the recommended plan needs a savings signal.\n- The signal must be concrete. Vague phrases like \"Save with annual billing\" do not count. Show\n  real values: a computed discount, a free-period callout, or a per-period price comparison.\n  Never hardcode discount percentages or savings amounts.\n- Use ONE clear anchoring signal. Stacking crossed-out price + savings badge + absolute\n  discount + original price creates visual noise.\n\n**Price Visibility.** Every package card MUST display its price.\n\n**Content Reduction.** Count content rows between the headline and the packages/CTA. If there\nare more than 4–5, remove the weakest. Every row above the fold competes with the CTA.\n\n**Layout.** Packages and the CTA MUST be above the fold. Keeping the purchase action (and\nideally the packages) always visible regardless of scroll is the strongest pattern. Never\nremove the purchase button or the privacy footer.\n\n- The package group and the purchase button must be adjacent. Content between them should move.\n- There must be visible spacing between packages and the purchase button (at least 12px).\n\n**Trust Signals** — required. Every paywall MUST have a short reassurance line below the\npurchase button (between the button and the privacy footer): \"Cancel anytime\", \"No commitment\",\ntrial terms. Order: packages → purchase button → reassurance text → privacy footer. If a free\ntrial exists, trial terms should be visible near the CTA (e.g. \"7-day free trial, then $X/month\").\n\n### Trial presentation (when a free trial exists)\n\n- Mention the trial in the CTA. \"Start Free Trial\" converts better than \"Subscribe\" with trial\n  details in small print.\n- The trial should be in the headline, the CTA, or both — not just legal text.\n- For a multi-day trial (7+ days) using a trial-timeline archetype, check that steps are clear:\n  start date, reminder date, charge date.\n- If trial terms (length, price after trial) are not visible anywhere, add them near the CTA.\n\n### Anti-pattern checks\n\n- **Generic CTA copy**: \"Subscribe\", \"Continue\", or \"Choose\" tells users what to DO, not what\n  they GET. Rewrite to action + benefit.\n- **Identical feature lists on multiple plan cards**: remove the duplicates; comparison should\n  be pricing only.\n- **Negative-only value proposition**: \"No ads, No interruptions, No limits\" sells removal.\n  Rewrite at least some items to what users GAIN.\n- **Legal text as primary content**: terms and renewal policies drowning the sales pitch belong\n  behind links. This does NOT apply to the privacy footer.\n- **Missing CTA button**.\n- **Missing privacy footer** with Terms and Privacy Policy links — App Store compliance.\n\n### Copy issues (fix these last)\n\n- Generic or feature-led copy → outcome-led. \"Access all features\" → \"Master any language\".\n- Paragraphs longer than two lines should be shorter or become bullets.\n- Headlines that describe the product → address the user. \"AI-powered photo editor\" → \"Make\n  every photo stunning\".\n"
}