Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx skills add evanca/flutter-ai-rules --skill revenuecat-testinggit clone --depth 1 https://github.com/evanca/flutter-ai-rulesWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/evanca/flutter-ai-rules/revenuecat-testing)<a href="https://agentmods.dev/skills/evanca/flutter-ai-rules/revenuecat-testing"><img src="https://agentmods.dev/badge/skills/evanca/flutter-ai-rules/revenuecat-testing.svg" alt="Measured on agentmods" height="20"></a>- NVIDIA SkillSpector pass
What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00041 | $0.01192 |
| Opus 5 | $0.00020 | $0.00596 |
| Sonnet 5 | $0.00008 | $0.00238 |
| Haiku 4.5 | $0.00004 | $0.00119 |
Grade A, and why
revenuecat-testing scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 8d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 42 lines — stays where its author put it; the contents beside it link to each section on GitHub.
RevenueCat Testing
Help a developer systematically verify their RevenueCat integration works before shipping — turning "I added RevenueCat, does it actually work?" into a concrete, checkable QA plan. The full use-case matrix, methods, platform differences, and the verifiable signal for each case live in references/use_cases.md. Read it for exact event names and preconditions; this file is the operating guide.
The organizing principle: every RevenueCat behavior has a verifiable signal — a specific dashboard event (INITIAL_PURCHASE, TRANSFER, EXPIRATION, PRODUCT_CHANGE, CANCELLATION), a period_type value, or a CustomerInfo/debug-log state. A test isn't "did the app not crash"; it's "did the expected event appear in the customer's history with the right fields." Always tie a test to its signal, or it isn't really testing anything.
How to use this skill
- Get the setup facts: platform(s) (iOS / Android / cross-platform / web billing), SDK (native, RN, Flutter, etc.), whether they've enabled debug logs and sandbox accounts yet, and what specifically they're trying to verify or why they think something is broken.
- Establish prerequisites first — most "purchases don't work" reports are config problems visible before any purchase:
- Debug logs on before
configure()(iOSPurchases.logLevel = .debug; AndroidsetLogLevel(LogLevel.DEBUG)), and check for "Invalid Product Identifiers" and error-level logs. Fix those before touching purchase flows. - Sandbox environment set up; multiple sandbox test IDs ready if any account-switching is in scope.
- Point them at the debug overlay (
debugRevenueCatOverlay()/DebugRevenueCatBottomSheet) to preview offerings and run test purchases quickly.
- Debug logs on before
- Map their goal to use cases from the reference and produce the plan (below).
Reference implementation (especially for Flutter): RevenueCat ships an official Purchase Tester sample app at github.com/RevenueCat/purchases-flutter/tree/main/revenuecat_examples/purchase_tester. It's a runnable app exercising the flows this skill tests — dedicated screens for product change (product_change_testing_screen.dart), paywalls and paywall-footer, customer center, virtual currency, winback offers, and custom paywall-impression testing — plus an end-to-end integration test at integration_test/app_test.dart. Point Flutter users there to (a) run a known-good build to isolate whether a bug is in their code vs. their store/RevenueCat config, and (b) model their own integration_test widget tests on app_test.dart. For non-Flutter SDKs, RevenueCat has equivalent Purchase Tester apps in each SDK repo.
What ships with it
1 file beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 8d ago First seen · 42 lines · 41 tokens per session scan A 0e4f9b2e71ad
revenuecat-testing is a skill published in the GitHub repository evanca/flutter-ai-rules (634 stars, last pushed 8d ago), licensed MIT. It adds 41 tokens to every session and 1,192 once invoked, about $0.0002 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other skills, from other repositories
Flutter Testing Patterns
Flutter app testing with widget tests, integration tests, golden tests, Mockito, bloc testing, and Flutter Driver for end-to-end scenarios.
flutter-mcp-toolkit-control
Drive a running Flutter app — tap, scroll, type, fill forms, hot-reload, navigate. Use when you need to interact with the UI.
harness-engineering-lifecycle
Design, implement, and integrate generalized validation harnesses across a producer-consumer boundary after a local harness contract exists. Use when refactoring custom validation CLIs/MCPs for large polyrepos, extending Steward across sibling repos, or deploying a local tool to a consumer project for dogfooding and…
flutter-mcp-cli-runtime-validation
Run Flutter MCP runtime validation from CLI in two steps (launch app, then run validate-runtime), including toolkit-extension gating, screenshot/layout capture, app error collection, optional reload verification, and retry handling for transient first-connect failures.
flutter-mcp-toolkit-dogfood-iterations
Runs and records fluttertestapp dogfood iterations (toolqualityrubric, rundogfoodeval.sh, dogfoodwebeval.yaml). Use when scoring MCP/intentcall quality, appending iteration N, comparing regressions, or CI static/weekly eval gates.
Cursor AI Testing Patterns
Effective test automation patterns with Cursor AI IDE including Composer for test suite generation, Cmd+K for inline test edits, Chat for test debugging, codebase-aware test generation, and rules configuration for testing conventions.