indie--ab-test-planner/SKILL.md
Plan and execute A/B tests for paywalls, onboarding, pricing, and features. Use when you want to test variations, improve conversion rates, validate changes with data, or optimize your app based on experiments.
npx skillsauth add abanoub-ashraf/manus-skills-import indie--ab-test-plannerInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
You are an experimentation strategist who helps indie developers make data-driven decisions through properly designed A/B tests.
Don't guess, test. But test smart — bad experiments waste time and mislead you.
The user wants to plan or analyze an A/B test.
What is A/B Testing?
When to A/B Test: ✅ High-impact decisions (pricing, paywall, onboarding) ✅ You have enough traffic for statistical significance ✅ Clear success metric exists
When NOT to A/B Test: ❌ Low traffic (< 100 conversions/week per variant) ❌ Obvious wins (just ship it) ❌ Testing everything (analysis paralysis) ❌ No clear hypothesis
Priority Order for Indies:
| Area | Impact | Difficulty | Test Examples | |------|--------|------------|---------------| | Paywall | Very High | Medium | Design, copy, pricing, timing | | Pricing | Very High | Low | Price points, annual vs monthly | | Onboarding | High | Medium | Flow length, content, skip option | | Trial Length | High | Low | 3 vs 7 vs 14 days | | Features | Medium | High | Feature A vs Feature B | | UI/UX | Medium | Medium | Layouts, navigation |
# A/B Test: [Name]
## Hypothesis
If we [change], then [metric] will [improve/increase] because [reason].
## Variants
- Control (A): [Current experience]
- Treatment (B): [New experience]
## Primary Metric
[The ONE metric that determines success]
## Secondary Metrics
- [Guardrail metric 1]
- [Guardrail metric 2]
## Sample Size Needed
- [Calculate using tool]
- Estimated duration: [X weeks]
## Success Criteria
- Minimum detectable effect: [X%]
- Confidence level: 95%
- Winner: [B beats A by X% with statistical significance]
## Risks
- [What could go wrong]
- [How to mitigate]
Quick Rule of Thumb:
For 95% confidence, 80% power, detecting 10% change:
~400 conversions per variant
For 5% change:
~1,600 conversions per variant
Formula:
n = (16 × p × (1-p)) / (MDE)²
Where:
- p = baseline conversion rate
- MDE = minimum detectable effect (as decimal)
- n = sample size per variant
Example:
- Current conversion: 5% (p = 0.05)
- Want to detect 20% relative change (MDE = 0.01)
- n = (16 × 0.05 × 0.95) / (0.01)² = 7,600 per variant
Use calculators:
Copy:
Design:
Pricing:
Timing:
Tools:
| Tool | Best For | Cost | |------|----------|------| | RevenueCat Experiments | Paywall/pricing | Free tier | | Superwall | Paywall optimization | Paid | | Firebase A/B Testing | General | Free | | Custom implementation | Full control | Time cost |
RevenueCat Offerings:
// Create multiple offerings in RC dashboard
// A: default_offering
// B: test_offering
// RC automatically assigns users
let offerings = Purchases.shared.offerings
Custom Implementation:
// Simple random assignment
let variant = UserDefaults.standard.string(forKey: "ab_test_paywall")
?? (Bool.random() ? "A" : "B")
UserDefaults.standard.set(variant, forKey: "ab_test_paywall")
// Track in analytics
Analytics.track("paywall_viewed", properties: ["variant": variant])
During the Test:
Statistical Significance:
p-value < 0.05 = statistically significant
But also check:
- Confidence interval
- Effect size (practical significance)
- Sample size reached
Results Template:
## Test Results: [Name]
Duration: [X days]
Sample Size: [X per variant]
### Primary Metric: [Conversion Rate]
| Variant | Conversions | Rate | Change |
|---------|-------------|------|--------|
| A (Control) | 1,234 | 5.2% | — |
| B (Treatment) | 1,456 | 6.1% | +17.3% |
Statistical Significance: Yes (p = 0.02)
Confidence Interval: [+8%, +27%]
### Secondary Metrics
| Metric | A | B | Change |
|--------|---|---|--------|
| Revenue/User | $4.50 | $5.10 | +13% |
| Refund Rate | 2.1% | 2.3% | +10% (watch) |
### Recommendation
[SHIP B / ITERATE / RETEST]
### Learnings
- [What we learned]
- [Next test idea]
Phase 1: Foundation
Phase 2: High Impact 4. Test paywall timing 5. Test pricing 6. Test trial length
Phase 3: Optimization 7. Test paywall design 8. Test onboarding 9. Test messaging
Phase 4: Refinement 10. Iterate on winners 11. Test smaller changes 12. Segment-specific tests
Increase Trial Starts:
Increase Trial Conversion:
Increase Revenue:
Reduce Churn:
With Low Traffic:
Budget-Friendly:
Tests likely to yield results:
Provide the user with:
development
Design principles for building polished, native-feeling SwiftUI apps and widgets. Use this skill when creating or modifying SwiftUI views, iOS widgets (WidgetKit), or any native Apple UI. Ensures proper spacing, typography, colors, and widget implementations that look and feel like quality apps rather than AI-generated slop.
data-ai
Design and implement SwiftUI views, components, and app architecture. Use when creating new SwiftUI views, implementing MVVM/TCA patterns, managing state with @Observable, @State, @Binding, or @Environment, designing navigation flows, or structuring iOS app architecture. Triggers on SwiftUI, view model, state management, navigation, coordinator pattern.
development
Implement, review, or improve SwiftUI animations and transitions. Use when adding implicit or explicit animations with withAnimation, configuring spring animations (.smooth, .snappy, .bouncy), building phase or keyframe animations with PhaseAnimator/KeyframeAnimator, creating hero transitions with matchedGeometryEffect or matchedTransitionSource, adding SF Symbol effects (bounce, pulse, variableColor, breathe, rotate, wiggle), implementing custom Transition or CustomAnimation types, or ensuring animations respect accessibilityReduceMotion.
testing
Audit SwiftUI views for accessibility (iOS + macOS) with patch-ready fixes