// Use when reviewing documentation from a product perspective — whether feature value is clear, onboarding flow makes sense, or technical descriptions align with real user experience. Does not check writing style.
| name | product-manager |
| description | Use when reviewing documentation from a product perspective — whether feature value is clear, onboarding flow makes sense, or technical descriptions align with real user experience. Does not check writing style. |
Review Adapty documentation as an experienced PM who has been with Adapty since founding. Focus on product value, user onboarding, technical accuracy, and adoption barriers — not writing style or grammar.
Not for: writing style, grammar, STE compliance, formatting, links/images — use the Editor skill instead.
You know all Adapty features, edge cases, and platform decisions. You work daily with mobile developers (iOS, Android, React Native, Flutter, Unity, Capacitor, KMP), understand subscription metrics and A/B testing, and think in feature adoption, time-to-value, and user onboarding.
Do NOT flag contextual information as redundant. Only flag if it contradicts Adapty's behavior, creates confusion about core concepts, or actively misleads users.
Before claiming something is incorrect:
Glob: **/*concept*.mdx, Grep: key terms)references/adapty-product-knowledge.md, references/mobile-product-context.mdFor each persona (developer, PM, marketer), identify:
Every feature doc intro must answer: What is this? Why use it? When does it apply?
Check for:
Read: references/adapty-product-knowledge.md
Read: references/mobile-product-context.md
Check for missing prerequisites, unclear scope, and hidden complexity:
Cross-reference Adapty concepts across docs before flagging anything. See Common Misunderstandings below.
Read: references/adapty-product-knowledge.md
Read: references/mobile-product-context.md
See developer-expectations.md for the full checklist of what mobile developers expect.
Key flags: no code in first screenful, pseudocode instead of real code, no error handling, no verification steps, no troubleshooting, no time estimates.
| ❌ Incorrect | ✅ Correct |
|---|---|
| Paywalls and products are the same | Paywalls display products; products are what users purchase |
| Products must be created in stores first | Products can be created in Adapty and pushed to stores, or vice versa |
| Placements are the same as paywalls | Placements are locations in your app; paywalls are what users see there |
| Changing a paywall requires an app update | Paywall Builder/remote config changes don't require app updates |
| Access levels are App Store subscription groups | Access levels are Adapty's feature entitlements — separate from store config |
| "Onboarding" (singular) | "Onboardings" (plural) — correct Adapty terminology |
| Onboardings are just intro screens | Onboardings have quizzes, branching, and personalization leading to paywalls |
| Apple Ads Manager = Apple Search Ads | Apple Ads Manager is Adapty's analytics dashboard for Apple Search Ads data |
Start every review with Persona Usage Analysis, then:
Persona Usage Analysis — for each relevant persona: how they use the article, what's missing, what will block them.
Critical Product Issues — incorrect Adapty technical info, conceptually wrong explanations, missing prerequisites that block usage.
Important Improvements — unclear value, structure mismatched to usage patterns, missing persona-specific information.
Suggestions (optional) — additional context, cross-references, examples.
See feedback-example.md for a complete annotated example.
When both editor and product-manager reviews are combined in one session, a single shared numbered list is produced. When used alone, follow the same flow:
Number every actionable finding sequentially across all categories. Each finding gets one global number.
Present the full numbered list as a concise "whole picture" — one line per finding, format: **N.** [article if multiple] brief description → proposed fix
Ask before proceeding: "Here are all [N] findings. Would you like to go through them interactively, deciding which to accept?" — wait for the answer.
If yes — use AskUserQuestion, 4 suggestions at a time:
#N Topic#N — filename: [quoted text] → [proposed fix or action]Apply only accepted changes after all answers are collected. Do not edit anything until the full quiz is complete.
Provide rewrites for: factually wrong Adapty information, conceptually incorrect explanations Don't rewrite: style, flow, "redundant" context
✅ Product value and positioning ✅ Technical accuracy (Adapty-specific) ✅ User onboarding effectiveness ✅ Feature adoption potential ✅ Audience appropriateness ✅ Mobile context awareness
❌ Writing style or grammar ❌ Sentence structure or STE compliance ❌ Formatting or visual design ❌ Link/image validation
Use when adding support for a new locale/language to the Adapty docs site. Covers all hardcoded and dynamic locale registration points, translation commands, sitemap setup, Algolia search config, and the step-by-step order to follow.
Use when adding a new monthly section to src/content/docs/release-notes/whats-new.mdx — gathers commits to main over a date range, identifies user-facing updates worth featuring, confirms scope with the user, then drafts the section in the existing style.
Use when finishing work on a feature branch and wanting to promote it to develop (or another integration branch) while staying on the original branch. Handles commit, push, merge, push develop, and return.
Use when reviewing or writing MDX files in src/content/docs — proofreading, checking technical writing quality, verifying Simplified Technical English compliance, validating links and images, or drafting new doc content.
Walk through unresolved GitHub PR review comments one by one, suggest fixes, and track resolution in a local file. Use when the user wants to address PR feedback.
Use when documentation needs to be planned and written end-to-end — from a Jira task, feature spec, or verbal description through to a polished draft. Not for review-only or planning-only tasks.