[trinya]

Why

These three skills were ported from the Rico agent some time ago, and Rico has gained guidance since then that coding agents need too. This PR brings that guidance over. Anything that depends on Rico's runtime is left out.

What changed

revenuecat-store-state

• Failed reads: store_status.status: could_not_check means the store read failed. Empty prices then don't mean "no prices".
• Approved App Store subscriptions: price and intro-offer changes need a future start_date on every changed territory, otherwise the apply fails.
• Prices:
  • Never make up prices or convert them with exchange rates.
  • Play subscriptions use other_regions_config.usd_price/eur_price plus regional_configs.
  • All amounts are amount_micros.
• Patches: omitted fields stay unchanged, null deletes an entry, territories: false removes availability.
• Confirm step:
  • Quote warnings verbatim and never argue a blocker away.
  • Link the review URL for every plan mentioned. This was optional before.
• Apply step:
  • Share the commit-to-store progress URL.
  • Stop polling after about 10 minutes.
  • Apply stops at the first failing item, and a retry re-runs only the items that didn't apply.
• Submitting to Apple: submit only what was asked for or just applied, and report outcomes per product, including skipped ones.
• New Gotchas section:
  • App Store localization length limits.
  • How to retire a product, since store products can't be deleted.
• Kept as is: the rule to confirm before applying.

revenuecat-charts

• New "Choosing dates and resolution" subsection:
  • Ask which reading the user means for ranges like "last 2 weeks", with concrete dates for each.
  • A period's label is the first day of the calendar period, and weeks start on the project's configured day.
  • Prefer daily resolution plus aggregate for trailing windows.
  • Report the dates queried, not the bucket labels.
• Batching: "don't query too many charts at once" becomes per-project calls in parallel batches of 10–20, re-issuing any call that was rate-limited.
• "Why did this metric move" checklist:
  • Every check is mandatory, and hedging doesn't make a guess acceptable.
  • Call get-experiment-results yourself.
  • list-offerings takes no expand and no conclusions from a partial page; get-offering expands take package / package.product (checked against the MCP schema).
  • Before writing "was pulled from the offering", make the call.
  • "Cannot determine why" is a valid answer.
• Comparisons:
  • Keep the blended rate next to the filtered one.
  • Make no gap claim without a matching value.
  • Two metrics track each other only if one is a subset of the other.
• Fan-out: start high-level and ask a clarifying question.

revenuecat-troubleshoot

• Offerings: list-offerings with limit: 100. The default page of 20 can leave out the current offering.
• Play product IDs: the product_id:base_plan_id format is only for subscriptions; one-time products use product_id.
• Durations: a null duration from list-products doesn't mean the product is misconfigured.
• New Check 6: SDK-gated features, handed off to revenuecat-sdk-compatibility (list-sdk-feature-gates / list-sdk-versions). The description now also triggers on this and on "validate my store/product setup".
• iOS checks:
  • The Paid Applications agreement can expire.
  • The Developer Program membership must be active and set to auto-renew.
  • The App-Specific Shared Secret is needed as well as the IAP key.
• Step 6 now names no specific Play track, so it no longer contradicts the Android checklist.

No version bump or CHANGELOG entry. Those go in one release PR together with #62 and #63, so the plugin ships once.

For reviewers

• Which Play testing track actually works? This needs a decision. The troubleshoot Android checklist, and RevenueCat's empty-offerings doc, say products are only fetched once the app is on at least a closed track, and that internal testing isn't enough. But revenuecat-testing-setup (the skill and all its platform files), revenuecat-migrate/platforms/android.md, and revenuecat-troubleshoot/platforms/{android,react-native}.md send testers to Internal Testing. That was already inconsistent before this PR. I didn't rewrite the testing flow here; once we settle which is right, it should be a follow-up.

Testing

Only skill text changed. I checked the MCP parameter names used above against the generated tool schemas.

🤖 Generated with Claude Code

---

Note

Low Risk
Documentation-only updates to agent skill markdown; no application code, APIs, or customer-facing behavior changes.

Overview
Ports updated Rico agent guidance into three RevenueCat skills (revenuecat-charts, revenuecat-store-state, revenuecat-troubleshoot) so coding agents follow stricter, more accurate workflows—no runtime or API code changes.

revenuecat-charts adds a Choosing dates and resolution section (disambiguate “last N weeks/months”, inclusive trailing days, bucket labels vs queried dates, daily + aggregate for trailing windows). Multi-project queries are now batched (parallel get-chart-data per project, 10–20 at a time with rate-limit retries). Metric-shift investigation requires MCP calls before naming offerings/experiments; comparison and fan-out rules are tightened.

revenuecat-store-state clarifies failed reads (could_not_check), pricing rules (no invented prices, Play other_regions_config, amount_micros, patch semantics), mandatory future start_date for approved App Store subscription price changes, stricter confirm/apply (verbatim warnings, review/commit URLs, poll limits, partial apply retries), scoped submit-to-Apple, and a new Gotchas section.

revenuecat-troubleshoot expands triggers (SDK-gated features, store validation), list-offerings with limit: 100, Play ID format for subs vs one-time, get-product-store-state over list-products duration, new Check 6 for SDK compatibility, and richer iOS credential/agreement checks.

^{Reviewed by Cursor Bugbot for commit aa7d765. Bugbot is set up for automated code reviews on this repo. Configure here.}