Firebase Ai Logic

Firebase AI Logic

When to use this skill

• Add Gemini-powered features directly inside a Firebase app.
• Build in-app text, chat, multimodal, structured-output, or streaming experiences.
• Decide whether a request should stay in the client/app layer or move to a backend workflow.
• Add Firebase-specific production controls such as App Check, quota awareness, and Firebase service integration around the AI feature.
• Handle app-side AI for web, mobile, Flutter, Unity, or similar Firebase-supported client surfaces.

Do not use this skill when

• The user needs server-owned flows, tool calling, RAG, evaluators, traces, prompt files, or reusable backend orchestration → use genkit.
• The user needs Firebase project setup, emulator, hosting/functions deploys, or CLI operations → use firebase-cli.
• The user is not committed to Firebase and mainly needs a generic provider SDK comparison → use a provider-specific or framework-selection skill instead.

Operating model

Treat firebase-ai-logic as the client/app integration anchor in a three-way lane: 1. App/client feature integration → firebase-ai-logic 2. Backend workflow orchestration → genkit 3. Firebase platform / operator tasks → firebase-cli

Do not blur these roles. If the request spans more than one role, split the packet and route each part explicitly.

Instructions

Step 1: Classify the request before giving implementation advice

Choose one mode first.

Mode A — Direct feature fit

Use this when the user wants to add an in-app AI feature such as:

• chat or assistant UI
• summarization or rewriting in the app
• multimodal prompts from user content
• structured output for app workflows
• streaming model responses into the UI

Deliver:

• whether Firebase AI Logic is the right lane
• what belongs in the app layer vs what should move out
• the minimum Firebase dependencies/services involved

Mode B — App wiring and UX integration

Use this when the user already chose Firebase AI Logic and needs help wiring it into the app.

Focus on:

• where the model call lives in the app architecture
• request/response lifecycle in UI state
• loading/error/retry/fallback UX
• prompt/template ownership in the app
• content moderation / safety surface the app must expose

Mode C — Production hardening

Use this when the feature exists or is close to launch.

Focus on:

• App Check / abuse prevention
• quota, cost, and rate-limit implications
• monitoring and failure visibility
• remote rollout / feature-flag strategy if relevant
• privacy boundaries for user input and generated output

Mode D — Escalation boundary

Use this when the user started with a client-side request, but the shape now implies backend orchestration.

Escalate to genkit when you see:

• tool calling or agent loops
• retrieval / RAG / database-grounded generation
• reusable flows shared across platforms
• evaluation harnesses, traces, or systematic observability
• secrets or privileged APIs that should not sit in the client

Step 2: Normalize the request packet

Rewrite the request into this brief before answering:

## Firebase AI Logic packet
- App surface: web | iOS | Android | Flutter | Unity | mixed
- User-facing feature: chat | summary | generation | multimodal | structured output | streaming
- Data involved: user text | images | docs | app state | Firebase data
- Safety/privacy concern: none | moderate | high
- Production stage: prototype | internal beta | launch prep | live issue
- Boundary check: stays in app | split with backend | move to `genkit`

If the packet says split with backend or move to genkit, say so immediately instead of pretending one skill owns the entire solution.

Step 3: Give app-layer guidance, not a giant code dump

For Firebase AI Logic requests, structure the answer in this order: 1. Why this should stay in the app layer 2. What to wire in the client UI/runtime 3. What Firebase-specific controls matter 4. What not to put in the client 5. When to escalate to `genkit` or `firebase-cli`

Use short code or pseudo-structure only when it clarifies the integration. Prefer architecture and boundary guidance over long SDK snippets.

Step 4: Cover the Firebase-specific concerns

Always touch the concerns that make this lane distinct from raw provider SDK usage:

• App Check / abuse prevention when relevant
• quotas / cost / rate awareness
• Firebase service interplay (Auth, Remote Config, analytics/monitoring, storage, functions handoff if needed)
• platform support implications for the target app surface
• rollout strategy for model changes or feature exposure when the request is production-facing

Step 5: Enforce honest route-outs

Use these route-outs explicitly.

Step 6: Output format

Respond with a compact packet like this:

## Recommendation
- Lane: Firebase AI Logic | Split with Genkit | Not a Firebase AI Logic fit
- Why: ...

## App-layer plan
1. ...
2. ...
3. ...

## Firebase-specific controls
- App Check / abuse:
- Quota / cost:
- Monitoring / rollout:

## Route-outs
- `genkit`: ...
- `firebase-cli`: ...

Best practices

1. Keep simple user-facing AI in the app layer only while it remains low-privilege and low-orchestration. 2. Move backend-worthy behavior out early; do not bolt tools/RAG/evals onto a client-only design. 3. Treat App Check, quota, and launch-readiness as first-class concerns, not afterthoughts. 4. Prefer one clear feature packet per response instead of mixing app UX, backend orchestration, and Firebase ops into a single blob. 5. When uncertain, explain the split between app-side Firebase AI Logic and backend-side genkit before proposing implementation steps.

Examples

Example 1: Should stay in Firebase AI Logic

Input: "Add streaming Gemini summaries inside our Firebase web app for article previews."

Output shape:

• lane = Firebase AI Logic
• plan focuses on app UI state, streaming rendering, prompt ownership, failure states, and App Check/quota guardrails
• route-out notes that reusable summarization pipelines or evaluation harnesses belong in genkit

Example 2: Should split with Genkit

Input: "Our mobile app needs chat, tool calling, and retrieval over Firebase data with server-side observability."

Output shape:

• lane = Split with Genkit
• Firebase AI Logic stays at the app interaction edge only if needed
• backend workflow, retrieval, tools, and observability move to genkit

References

• Firebase AI Logic overview
• Firebase AI Logic get started
• Firebase AI Logic production checklist
• Genkit docs

Firebase AI Logic feature packets

Use these packet shapes to keep answers concrete without turning the skill into an SDK dump.

Packet: chat / assistant UI

• app surface
• session/state model in the UI
• streaming or non-streaming
• moderation / error fallback
• boundary check: any tool use or retrieval?

Packet: summary / rewrite

• source text origin
• length/latency expectation
• output format requirements
• retry and cache behavior
• boundary check: is this reusable backend logic across clients?

Packet: multimodal feature

• input media type
• upload/storage path
• synchronous vs async UX
• privacy implications of uploaded content
• boundary check: does media processing need server-side handling?

Packet: structured output feature

• schema shape needed by the app
• validation and fallback path if output is malformed
• UI consequences of partial failure
• boundary check: does the schema feed downstream services better owned by a backend flow?

Packet: launch hardening

• user cohort / rollout plan
• App Check / abuse posture
• quota/cost visibility
• monitoring owner
• escalation criteria for moving to genkit

Firebase AI Logic modes and routing

Core boundary

Use firebase-ai-logic when the job is primarily direct app/client SDK integration for Gemini-powered features inside a Firebase app.

Keep the lane split three ways:

• firebase-ai-logic — app/client feature integration
• genkit — server-owned workflows, tools, retrieval, evals, observability
• firebase-cli — project, emulator, deploy, and operator tasks

Modes

1. Direct feature fit

Use when the user asks for in-app chat, summaries, structured output, multimodal prompts, or streaming.

2. App wiring and UX integration

Use when the user needs to decide where requests live in the app, how UI state handles streaming/loading/errors, and how prompt ownership fits the product.

3. Production hardening

Use when the user is preparing to ship and needs App Check, quota/cost awareness, rollout control, and monitoring.

4. Escalation boundary

Use when the original app-side request now includes tools, retrieval, shared backend logic, evaluations, traces, or privileged APIs. At that point, route the orchestration layer to genkit.

Fast routing checklist

• Stays here: direct app feature, low-privilege model call, UI streaming, structured output in app workflow
• Move to `genkit`: tools, RAG, reusable flows, evals, backend observability, secret-bearing integrations
• Move to `firebase-cli`: project bootstrapping, emulator work, deploy/config changes

Anti-patterns

• Treating Firebase AI Logic as the owner of backend agents or tool orchestration
• Using genkit by default for every Firebase AI request, even when the user only wants an in-app feature
• Mixing deploy/operator instructions into an app-integration answer

Firebase AI Logic production controls

What makes this lane production-specific

Firebase AI Logic is not just a raw model-call wrapper. In production-facing app work, the recurring concerns are:

• abuse prevention from real clients
• quota and cost exposure
• rollout/change management for user-visible AI behavior
• privacy boundaries for prompts and generated output

Checklist

App Check / abuse prevention

• Check whether the app is public-facing or susceptible to unauthorized client use.
• If yes, include App Check or an equivalent Firebase abuse-prevention story in the recommendation.
• Do not present client-side model calls as "just ship it" work without this guardrail.

Cost and quota

• Call out whether the feature could produce bursty usage, long streams, or repeated regeneration.
• Recommend basic safeguards such as request throttling, retries with limits, and UI patterns that do not encourage accidental spam.

Monitoring / visibility

• For production or beta launches, mention how the team will watch failures, latency, and cost/usage changes.
• If the user asks for systematic traces, evaluators, or reusable backend observability, route that part to genkit.

Rollout / model changes

• If launch risk matters, recommend remote configuration, staged rollout, or a feature flag rather than hard-coding one permanent exposure plan.

Privacy boundary

• Highlight whether user-generated or sensitive content is involved.
• If the app needs privileged joins, server secrets, or protected systems, move that work out of the client lane.

Common recommendation pattern

1. Keep the user-facing feature in Firebase AI Logic. 2. Add app-level controls for abuse, quota, and fallback behavior. 3. Escalate backend-only concerns to genkit. 4. Escalate deploy/config mechanics to firebase-cli.