Route Firebase AI feature work into either direct app/client Firebase AI Logic SDK integration or a server-owned Genkit workflow. Use when a web, mobile, backend, or full-stack feature needs model calls, typed outputs, reusable flows, tools, retrieval, prompt files, evals, observability, or deployment. Choose client-ai-logic, flow-foundation, tool-and-agent, retrieval-and-prompt, evaluation-and-observability, deployment-runtime, or comparison-or-fallback; route Firebase platform/operator work to `firebase-cli` and broad framework comparisons to `survey`.
Route Firebase AI feature work into either direct app/client Firebase AI Logic SDK integration or a server-owned Genkit workflow. Use when a web, mobile, backend, or full-stack feature needs model calls, typed outputs, reusable flows, tools, retrieval, prompt files, evals, observability, or deployment. Choose client-ai-logic, flow-foundation, tool-and-agent, retrieval-and-prompt, evaluation-and-observability, deployment-runtime, or comparison-or-fallback; route Firebase platform/operator work to `firebase-cli` and broad framework comparisons to `survey`.
allowed-tools
Read Write Bash Grep Glob
compatibility
Covers both direct Firebase AI Logic client SDK integration and server-owned Genkit workflow planning. Best for repository packets, app feature wiring, backend routes, flow/eval docs, Cloud Run plans, and launch-readiness reviews.
Use this skill when the main question is "should this Firebase AI feature be a direct client SDK integration or a reusable server-owned Genkit workflow?"
The job is not to dump a long Genkit tutorial, CLI catalog, or Firebase product tour.
Frame the current packet, choose one ownership boundary and operating mode, then keep
Firebase platform operations and broad framework comparisons routed to adjacent skills.
A mobile or web app needs direct Firebase AI Logic client SDK integration, including model setup, structured output, streaming, App Check, or safe client/server boundaries
A backend or full-stack feature needs a reusable Genkit flow instead of one-off provider calls scattered through route handlers
The work needs typed contracts, tool calling, retrieval, prompt files, evaluation, tracing, or deployment under a server-owned boundary
The request is explicitly about Firebase AI Logic, Genkit, or deciding between their client-owned and server-owned shapes
An existing Firebase AI feature needs debugging, evaluation, observability, or launch-readiness review
When not to use this skill
The main job is Firebase bootstrap, emulator usage, hosting/functions deploy, auth/login, or admin CLI work → firebase-cli
The request is generic frontend streaming/rendering with no Firebase AI SDK or Genkit boundary → relevant frontend/web skill
The real question is broad framework choice (Genkit vs Vercel AI SDK vs other frameworks) → survey
A plain provider SDK or simple route handler is enough and Firebase/Genkit is not a requirement → note the fallback and keep the answer lightweight
Instructions
Step 1: Frame the current packet
Record the smallest useful intake before recommending Genkit.
Capture:
app shape: web | mobile | backend | fullstack | mixed | unknown
App shape: fullstack
Ownership: backend capability
Packet: existing API route + support feature brief
Workflow need: retrieval + one ticket tool + evals later
Delivery pressure: reuse across web app and internal ops panel
Rule: one primary mode, optional secondary mode.
Do not mix client SDK wiring, backend flow design, deployment ops, and architecture comparison into one blob.
Step 5: Freeze the smallest feature boundary
For client-ai-logic, define:
one app feature and model interaction
input/output or streaming contract
client-visible versus server-only data and configuration
App Check/auth/error handling and abuse boundaries
For a server-owned Genkit mode, define:
one named backend capability and typed flow contract
what must remain server-side
tools/retrieval/prompts, if any
which clients or jobs call it
Avoid mega-flows, exposing server secrets to clients, or adding tools/retrieval before one basic path works.
Input: “Build a Genkit backend flow for our support app: retrieve help articles, call one ticket tool, and expose one server endpoint the web app can reuse.”
Expected shape:tool-and-agent or retrieval-and-prompt, explicit server-owned flow boundary, and one tool/retrieval plan.
Example 2: Direct Firebase app feature
Input: “Add Gemini-powered summaries directly inside our Firebase web app with the Firebase SDK.”
Expected shape:client-ai-logic, with an app-owned SDK boundary, structured output or streaming contract, App Check/auth, and no unnecessary server flow.
Example 3: Existing flow needs confidence before launch
Input: “Our Genkit flows work locally, but we need a practical eval and observability plan before deploying to Cloud Run.”
Expected shape:evaluation-and-observability, small evidence loop, and runtime specifics kept separate from Firebase CLI operations.
Example 4: Framework choice is still unclear
Input: “Should we use Genkit, Firebase AI Logic, Vercel AI SDK, or just direct SDK calls for this Firebase app?”
Expected shape:comparison-or-fallback, route broad framework selection to survey, then return here with either client-ai-logic or a server-owned Genkit mode.
Best practices
Choose the client or server ownership boundary before naming tools or models.
Prefer one crisp feature/flow boundary over a giant AI feature bucket.
Keep secrets and protected resources server-side; define App Check/auth and abuse boundaries for direct client work.
Acknowledge plain route-handler / provider-SDK fallbacks when they are enough.
Treat runtime choice as an architecture decision, not proof that Genkit is mandatory.
Use traces and evals before widening rollout.
Sync compact discovery surfaces whenever the front-door boundary changes.
