Firebase In App Messaging Agent Skill
Use when running in-app message campaigns, triggering/suppressing messages, configuring opt-in data collection, testing on specific devices, or handling message callbacks.
Install
one command, takes just this skill from the repositorynpx skills add https://github.com/evanca/flutter-ai-rules --skill firebase-in-app-messagingThe instruction itself
13 sections, as written by the authorFirebase In-App Messaging Skill
This skill defines how to correctly implement Firebase In-App Messaging in Flutter applications, covering setup, programmatic triggers, privacy controls, testing workflows, and campaign management.
When to Use
Use this skill when:
- Setting up Firebase In-App Messaging in a Flutter project.
- Triggering or suppressing in-app messages programmatically.
- Implementing opt-in data collection for GDPR or user privacy compliance.
- Testing campaigns with specific devices before rollout.
- Configuring message types, targeting rules, and A/B tests.
1. Setup and Configuration
flutter pub add firebase_in_app_messaging
import 'package:firebase_in_app_messaging/firebase_in_app_messaging.dart';
- Initialize Firebase before using any In-App Messaging features.
- In-App Messaging retrieves messages from the server once per day by default to conserve power.
Setup Checklist
- Confirm
Firebase.initializeApp()completes before accessing In-App Messaging. - Create a test campaign in the Firebase console to verify the integration.
- Locate the Installation ID for device-specific testing (see Testing section).
2. Message Triggering and Display
Use Google Analytics events to trigger in-app messages without additional code. For programmatic triggering:
// Trigger a message tied to a custom event
await FirebaseInAppMessaging.instance.triggerEvent("purchase_complete");
Suppress Messages During Critical Flows
class PaymentScreen extends StatefulWidget {
@override
State<PaymentScreen> createState() => _PaymentScreenState();
}
class _PaymentScreenState extends State<PaymentScreen> {
@override
void initState() {
super.initState();
// Suppress messages during payment
FirebaseInAppMessaging.instance.setMessagesSuppressed(true);
}
@override
void dispose() {
// Re-enable messages when leaving payment flow
FirebaseInAppMessaging.instance.setMessagesSuppressed(false);
super.dispose();
}
}
- Suppression is automatically turned off on app restart.
- Suppressed messages are ignored — their trigger conditions must be met again after suppression is lifted.
- Common flows to suppress: payment processing, onboarding wizards, form submission screens.
3. User Privacy and Opt-In Data Collection
By default, In-App Messaging automatically delivers messages to all targeted users.
Disable automatic collection — iOS (Info.plist):
<key>FirebaseInAppMessagingAutomaticDataCollectionEnabled</key>
<false/>
Disable automatic collection — Android (AndroidManifest.xml):
<meta-data
android:name="firebase_inapp_messaging_auto_data_collection_enabled"
android:value="false" />
Enable for users who opt in at runtime:
// Call after user consents to data collection
Future<void> enableMessaging() async {
await FirebaseInAppMessaging.instance.setAutomaticDataCollectionEnabled(true);
}
// Call if user revokes consent
Future<void> disableMessaging() async {
await FirebaseInAppMessaging.instance.setAutomaticDataCollectionEnabled(false);
}
- Manually set preferences persist through app restarts, overriding configuration file values.
- For GDPR compliance, disable automatic collection by default and enable only after explicit user consent.
4. Testing and Debugging
Find the Installation ID
- Android: Filter logcat by
FIAM.Headless— look forStarting InAppMessaging runtime with Installation ID YOUR_INSTALLATION_ID. - iOS: Add
-FIRDebugEnabledas a runtime argument in Xcode scheme settings. Look for[Firebase/InAppMessaging][I-IAM180017]in the console.
Test a Campaign
- In the Firebase console, open the campaign and select Test on your Device.
- Enter the Installation ID from the step above.
- The test message appears on the next app launch or foreground event.
- Always test on actual devices for proper rendering and behavior.
- Test each message type (modal, banner, card, image-only) to verify layout on different screen sizes.
5. Campaign Management
- Create campaigns in the Firebase console under Messaging > In-App Messaging.
- Message types: modal, banner, card, or image-only.
Campaign Configuration Workflow
- Design — Select the message type and customize appearance (title, body, image, button).
- Target — Define the audience by app version, language, user segment, or Analytics-based conditions.
- Schedule — Set start/end dates and frequency caps (once, once per session, etc.).
- Trigger — Choose the Analytics event that displays the message (e.g.,
app_open,purchase_complete). - Test — Use device testing before publishing.
- Publish — Launch the campaign and monitor performance.
- Use custom metadata (key-value pairs) to pass additional info accessible when users interact with messages.
- Use A/B testing to optimize message content, timing, and conversion rates.
- Monitor campaign performance (impressions, clicks, conversions) through Firebase console analytics.
References
Other skills for the same job
different authors, same section of the catalogue
Use when testing the golden_chat golden build
Use when testing the golden_chat_empty golden build
Use when testing the golden_chat_single golden build
Use when testing the golden_chat_topics golden build
Hunt account takeover taxonomy — 9 distinct paths to ATO, plus chains. Paths: (1) password reset flaws (host-header injection redirects token, predictable/numeric token, Referer leak, no-expiry/reuse), (2) email change without re-auth, (3) OAuth account-link CSRF, (4) MFA bypass (per hunt-mfa-bypass), (5) session fixation, (6) JWT manipulation (forge token to another identity; crypto details → hunt-jwt-crypto), (7) password change without step-up (chain with login timing/length oracle), (8) social-recovery / security-question brute-force, (9) SSO subdomain takeover at OAuth redirect_uri. Chains: cookie theft + password oracle + no step-up = persistent ATO; lax redirect_uri = auth-code theft; dangling-CNAME takeover at redirect_uri = ATO. Validate: demonstrate real takeover of test account B from attacker A's session; OOB/Collaborator confirm blind token-leak steps. Use when hunting ATO chains, testing password reset / email change / MFA / OAuth / session / JWT, or chaining primitives toward Critical.
> Use this skill for hands-on DOCA Ethernet packet-queue work on a BlueField DPU or ConnectX NIC — bringing up a `doca_eth_rxq` or `doca_eth_txq` on a port / representor / SF, picking among the four `enum doca_eth_rxq_type` values (`_REGULAR` / `_CYCLIC` / `_MANAGED_MEMPOOL` / `_SHARED_MEMPOOL`), sizing burst or scatter-gather length against the `_cap_*` queries, submitting `doca_eth_txq_task_send` / `_lso_send` (carrying packet `doca_buf`s — no `doca_eth_frame` struct exists), or debugging DOCA_ERROR_* from an Ethernet call. Trigger on arrive", "send-task returns AGAIN at line rate", "which queue type for fixed-MTU ingress", "device open fails without sudo", or "is L3 checksum offload available here". Refuse and route elsewhere for installing DOCA, flow-rule / steering programming, host↔DPU control messaging, or RDMA data movement.
Use when the user asks to "build our social crisis protocol", "mentions are exploding — what do we do first", or "when do we pause the posting queue"; produces a 1-5 severity ladder with tunable Estimated trigger thresholds (mention-velocity multiples vs the 7-day listening baseline, sentiment flip, journalist/regulator contact, employee-conduct class), the first-mechanical-action rule — pause ALL scheduled posts AND paid amplification, with dated state markers dropped to the channels proposal protocol and reconciled post-incident — a pre-approved holding-statement library with committed update cadences, when-NOT-to-post rules, a spokesperson/approval matrix, and a post-crisis retro template; re-runs the social-quality-auditor pre-publish gate before un-pausing the queue. Not for email deliverability incidents (blocklist, spam-rate spikes) — use deliverability-qa; inside a launch window launch-day-conductor owns incident handling. 社媒危机预案/暂停队列/声明库/发言人矩阵
Use when the user asks to "test our messaging before we scale it", "design a message-market-fit panel", or "run a 5-second comprehension test on our new tagline"; produces a message-test design spec — hypothesis, panel and recruit criteria, comprehension / 5-second / message-market-fit (Wynter-style) protocols, stimulus set drawn from the canon, success thresholds, and a stop/revise decision rule — for the TALE Evaluate phase so the message is validated before any paid scale. It designs the test; it never runs the experiment or adjudicates a claim. Not for running the panel or A/B experiment — use send-experiment-designer or ad-test-designer; not for analyzing the results — use performance-analyzer; not for authoring the message itself — use message-system-architect. 消息测试/理解度测试/面板设计/五秒测试/消息市场契合
How to use it
Take evanca/firebase-in-app-messaging from the repository into ~/.claude/skills for personal
use, or into .claude/skills inside a project.
The agent identifies a skill by the name field in its header. Two skills with the
same name cannot sit side by side — one of them will be ignored.