Fetches axiom-in-app-purchases from charleswiltgen/axiom and configures it for Cursor.
3
Select Cursor when prompted
The CLI shows a list of agents. Use arrow keys and space to select Cursor:
◆ Which agents do you want to install to?
│
│ ── Universal (.agents/skills) ────────────────
│ · Cline · Codex · Goose · Windsurf
│ ●Cursor(selected)
│ · Cursor · Aider · Continue
4
Verify installation
Confirm successful installation by checking the skill directory location:
.cursor/skills/axiom-in-app-purchases
Restart Cursor to activate axiom-in-app-purchases. Access via /axiom-in-app-purchases in your agent's command palette.
⚠
Security Notice
We perform automated surface-level scans (Gen AI Scanner, Socket, Snyk) during installation. These checks detect common vulnerabilities but do not guarantee complete security. Always review skill source code and verify the publisher's reputation before production use.
Skills execute code in your environment. Always review source, verify the publisher, and test in isolation before production.
Debugging purchase failures, missing transactions, or restore issues
Setting up StoreKit testing configuration
Implementing subscription status tracking
Adding promotional offers or introductory offers
Server-side receipt validation
Family Sharing support
❌ Do NOT use this skill for:
StoreKit 1 (legacy API) - this skill focuses on StoreKit 2
App Store Connect product configuration (separate documentation)
Pricing strategy or business model decisions
⚠️ Already Wrote Code Before Creating .storekit Config?
If you wrote purchase code before creating .storekit configuration, you have three options:
Option A: Delete and Start Over (Strongly Recommended)
Delete all IAP code and follow the testing-first workflow below. This reinforces correct habits and ensures you experience the full benefit of .storekit-first development.
Why this is best:
Validates that you understand the workflow
Catches product ID issues you might have missed
Builds muscle memory for future IAP implementations
Takes only 15-30 minutes for experienced developers
Option B: Create .storekit Config Now (Acceptable with Caution)
Create the .storekit file now with your existing product IDs. Test everything works locally. Document in your PR that you tested in sandbox first.
Trade-offs:
✅ Keeps working code
✅ Adds local testing capability
❌ Misses product ID validation benefit
❌ Reinforces testing-after pattern
❌ Requires extra vigilance in code review
If choosing this path: Create .storekit immediately, verify locally, and commit a note explaining the approach.
Commit without .storekit configuration, test only in sandbox.
Why this is problematic:
Teammates can't test purchases locally
No validation of product IDs before runtime
Harder iteration (requires App Store Connect)
Missing documentation of product structure
Bottom line: Choose Option A if possible, Option B if pragmatic, never Option C.
Core Philosophy: Testing-First Workflow
Best Practice: Create and test StoreKit configuration BEFORE writing production purchase code.
Why .storekit-First Matters
The recommended workflow is to create .storekit configuration before writing any purchase code. This isn't arbitrary - it provides concrete benefits:
Immediate product ID validation:
Typos caught in Xcode, not at runtime
Product configuration visible in project
No App Store Connect dependency for testing
Faster iteration:
Test purchases in simulator instantly
No network requests during development
Accelerated subscription renewal for testing
Team benefits:
Anyone can test purchase flows locally
Product catalog documented in code
Code review includes purchase testing
Common objections addressed:
❓ "I already tested in sandbox" - Sandbox testing is valuable but comes later. Local testing with .storekit is faster and enables true TDD.
❓ "My code works" - Working code is great! Adding .storekit makes it easier for teammates to verify and maintain.
❓ "I've done this before" - Experience is valuable. The .storekit-first workflow makes experienced developers even more productive.
❓ "Time pressure" - Creating .storekit takes 10-15 minutes. The time saved in iteration pays back immediately.
The Recommended Workflow
StoreKit Config → Local Testing → Production Code → Unit Tests → Sandbox Testing
↓ ↓ ↓ ↓ ↓
.storekit Test purchases StoreManager Mock store Integration test
Why this order helps:
StoreKit Config First: Defines products without App Store Connect dependency
Local Testing: Validates product IDs and purchase flows immediately
Production Code: Implements against validated product configuration
Unit Tests: Verifies business logic with mocked store responses
Sandbox Testing: Final validation in App Store environment
Benefits of following this workflow:
Product IDs validated before writing code
Faster development iteration
Easier team collaboration
Better test coverage
Mandatory Checklist
Before marking IAP implementation complete, ALL items must be verified:
Phase 1: Testing Foundation
Created .storekit configuration file with all products
Verified each product type renders correctly in StoreKit preview
Tested successful purchase flow for each product in Xcode
All purchase logic must go through a single StoreManager. No scattered Product.purchase() calls throughout app.
importStoreKit@MainActorfinalclassStoreManager:ObservableObject{// Published state for UI@Publishedprivate(set)var products:[Product]=[]@Publishedprivate(set)var purchasedProductIDs:Set<String>=[]// Product IDs from StoreKit configurationprivatelet productIDs =["com.yourapp.coins_100","com.yourapp.premium","com.yourapp.pro_monthly"]privatevar transactionListener:Task<Void,Never>?init(){// Start transaction listener immediately transactionListener =listenForTransactions()Task{awaitloadProducts()awaitupdatePurchasedProducts()}}deinit{ transactionListener?.cancel()}}
Why @MainActor: Published properties must update on main thread for UI binding.
Load Products (At Launch)
extensionStoreManager{funcloadProducts()async{do{// Load products from App Storelet loadedProducts =tryawaitProduct.products(for: productIDs)// Update published property on main threadself.products = loadedProducts
}catch{print("Failed to load products: \(error)")// Show error to user}}}
Call from: App.init() or first view's .task modifier
Listen for Transactions (REQUIRED)
extensionStoreManager{funclistenForTransactions()->Task<Void,Never>{Task.detached {[weakself]in// Listen for ALL transaction updatesforawait verificationResult inTransaction.updates {awaitself?.handleTransaction(verificationResult)}}}@MainActor
✓
Make data-driven prioritization decisions faster
Stakeholder Communication
Draft PRDs, status updates, and stakeholder presentations
›Access to product documentation and roadmap tools (Jira, Notion, etc.)
›Understanding of product management frameworks (RICE, Jobs-to-be-Done, etc.)
›Stakeholder contact information and communication channels
Time Estimate
30-60 minutes to see productivity improvements
Steps
1Install product management skill
2Start with user story generation for known feature
3Progress to competitive analysis: research 2-3 competitors
4Use for roadmap prioritization: apply RICE/ICE scoring
5Draft stakeholder communications and refine based on feedback
6Build template library for recurring PM tasks
7Share effective prompts with product team
Common Pitfalls
⚠Not validating competitive research—verify facts before sharing
⚠Accepting user stories without involving engineering team
⚠Over-relying on frameworks without qualitative judgment
⚠Not customizing outputs to company culture and communication style
⚠Skipping stakeholder validation of generated requirements
Best Practices
✓ Do
+Validate research and competitive analysis with real data
+Collaborate with engineering when generating technical requirements
+Customize frameworks and templates to your company context
+Use skill for first drafts, refine with stakeholder input
+Document successful prompt patterns for PM tasks
+Combine AI efficiency with human judgment and intuition
✗ Don't
−Don't publish competitive analysis without fact-checking
−Don't finalize user stories without engineering review
−Don't make prioritization decisions solely on AI scoring
−Don't skip customer validation of generated requirements
−Don't ignore company-specific context and culture
💡 Pro Tips
★Provide context: company goals, constraints, customer feedback
★Ask for alternatives: 'Show 3 ways to prioritize this roadmap'
★Request stakeholder-specific formatting: 'Executive summary vs. engineering spec'
★Use skill for 70% generation + 30% customization to company needs
When to Use This
✓ Use when
Use for user story writing, competitive research, roadmap prioritization, stakeholder communication, and PRD drafting. Best for reducing repetitive documentation and research work.
✗ Avoid when
Avoid for strategic product vision (requires deep customer empathy), pricing decisions (needs market and financial expertise), or when face-to-face customer discovery is more valuable than speed.
Learning Path
1Basic: user stories, feature specs, status updates
