Genkit

Genkit

Use this skill when the main question is "should this feature become a reusable server-owned AI workflow, and if so what is the smallest Genkit shape worth owning?"

The job is not to dump a long Genkit tutorial, CLI catalog, or Firebase product tour. The job is to frame the current packet, choose one operating mode, define one backend flow boundary, decide whether Genkit is actually the right layer, and route adjacent work away before the skill turns into app SDK wiring, Firebase ops, or generic framework comparison.

Read references/intake-packets-and-fallbacks.md before handling mixed or ambiguous requests. Read references/modes-and-routing.md before choosing a primary mode. Read references/deployment-and-runtime-boundaries.md when runtime choice is the real open question. Read references/evals-and-observability.md when the workflow already exists and confidence is the bottleneck.

When to use this skill

• A backend or full-stack feature needs a reusable AI flow instead of one-off provider calls scattered through route handlers
• The work needs typed input/output contracts, flow ownership, or one AI capability reused across multiple clients, jobs, or surfaces
• The workflow needs tool calling, retrieval, prompt files, structured outputs, evaluation, or local tracing under a server-owned boundary
• The request is clearly about Genkit or server-side Firebase AI workflow design, not direct app/client SDK integration
• The open question is how to structure, debug, evaluate, or deploy an existing Genkit flow to Firebase, Cloud Run, or another backend runtime

When not to use this skill

• The main job is direct mobile/web app integration with Firebase AI Logic client SDKs → firebase-ai-logic
• The main job is Firebase bootstrap, emulator usage, hosting/functions deploy, auth/login, or admin CLI work → firebase-cli
• The request is mostly frontend streaming/rendering/app wiring without backend workflow ownership → relevant frontend/web skill
• The real question is framework choice (`Genkit` vs `Firebase AI Logic` vs `Vercel AI SDK` vs direct SDKs) → survey
• A plain provider SDK or simple route handler is probably enough and the user is not asking for reusable workflow structure → 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
• ownership: client feature | backend capability | mixed | unknown
• packet: route handler | feature brief | architecture note | deployed flow | eval/trace complaint | deploy plan | none
• workflow need: simple generation | structured output | tools | retrieval | prompt files | evals | observability | deployment | unknown
• delivery pressure: single endpoint | multi-surface reuse | launch readiness | migration | reliability concern | unknown

Quick frame:

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

Step 2: Choose the intake packet first

Use references/intake-packets-and-fallbacks.md.

Pick the packet the user actually has now:

• new backend capability packet
• existing route/handler packet
• deployed flow quality packet
• deployment/runtime packet
• comparison/fallback packet
• no usable packet yet

Output this step as:

## Intake Packet
- Current packet:
- Why it is enough (or not enough):
- Missing context to collect next:

Rule: do not force Genkit just because the app already uses Firebase.

Step 3: Decide whether Genkit is the right layer

Make the ownership decision explicit before choosing a mode.

Choose Genkit when the dominant need is:

• a reusable server-side AI contract
• typed flow input/output boundaries
• one place to own tool/retrieval/prompt orchestration
• evaluation, tracing, or deployment support for a maintained backend feature

Do not force Genkit when the request is mainly:

• direct client/mobile/web SDK usage
• a thin one-off model call that can stay in a normal backend route
• a generic framework comparison with no chosen ownership layer yet
• a reliability/durability question better owned by queue/job/workflow infrastructure

State the decision in one line:

## Layer Decision
- Use Genkit: yes | no | maybe-after-survey
- Why:

Step 4: Choose one primary operating mode

Pick one primary mode from references/modes-and-routing.md.

Primary modes:

• flow-foundation
• tool-and-agent
• retrieval-and-prompt
• evaluation-and-observability
• deployment-runtime
• comparison-or-fallback

Rule: one primary mode, optional secondary mode. Do not mix backend flow design, frontend app wiring, deployment ops, and architecture comparison into one blob.

Step 5: Freeze one smallest flow boundary

If Genkit is the right layer, define the smallest useful workflow contract:

• one named backend capability
• one input/output schema or contract
• what must remain server-side
• where tools/retrieval belong, if anywhere
• which client(s) or jobs call it

Good boundary examples:

• support reply + ticket action flow shared by web app and internal admin tools
• document-grounded answer flow with one retrieval source and schema-valid output
• existing flow that now needs eval coverage before a Cloud Run rollout

Bad boundary examples:

• every AI feature in one mega-flow
• client-side app integration disguised as a server workflow
• adding tools, retrieval, and multi-agent logic before one basic flow works

Step 6: Name the fallback or route-out honestly

Use references/intake-packets-and-fallbacks.md.

Common route-outs:

• direct Firebase app/client SDK integration → firebase-ai-logic
• Firebase CLI / emulator / deploy / admin work → firebase-cli
• frontend streaming/rendering/app wiring → relevant frontend/web skill
• framework comparison or architecture uncertainty → survey
• thin synchronous model call that can stay inside one existing route → note plain provider SDK / route-handler fallback instead of forcing Genkit
• durability / retries / background orchestration dominating the problem → note queue/job/workflow substrate as a complement or better first layer

Step 7: Pick the smallest next slice

Do not jump to a giant system diagram. Return the smallest next slice that makes Genkit real:

• define one flow contract
• wrap one existing route into a flow
• add one tool boundary
• add one retrieval boundary
• add one eval set with representative inputs
• choose one runtime/deploy shape

Step 8: Use evals and traces when confidence is the bottleneck

Use references/evals-and-observability.md.

When the workflow already exists, prefer: 1. representative inputs 2. local trace review / Developer UI inspection 3. small eval set 4. contract / prompt / tool cleanup 5. rollout only after the evidence loop is good enough

Step 9: Return the Genkit brief

# Genkit Brief

## Scope
- App shape:
- Ownership:
- Intake packet:
- Primary mode:
- Confidence:

## Layer Decision
- Use Genkit: yes | no | maybe-after-survey
- Why:

## Backend Flow Boundary
- Capability:
- Input / output contract:
- Server-only responsibilities:
- Tools / retrieval / prompt-file needs:

## Smallest Next Slice
1. ...
2. ...
3. ...

## Route-outs / Fallbacks
- ...

Examples

Example 1: Reusable backend support workflow

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, one tool/retrieval plan, no route to firebase-ai-logic.

Example 2: Direct Firebase app feature

Input: “Add Gemini-powered summaries directly inside our Firebase web app with the Firebase SDK.”

Expected shape: route to firebase-ai-logic unless the request clearly adds a server-owned workflow requirement.

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, route runtime specifics through the deployment boundary without turning the answer into Firebase CLI ops.

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 to survey, and only return to genkit if the chosen ownership layer is a reusable backend workflow.

Best practices

1. Choose Genkit because you need a server-owned workflow layer, not just because the product uses Firebase. 2. Start from the packet and ownership decision before naming tools or models. 3. Prefer one crisp flow boundary over a giant AI feature bucket. 4. Keep direct app/client SDK work routed to firebase-ai-logic. 5. Acknowledge plain route-handler / provider-SDK fallbacks when they are enough. 6. Treat runtime choice as an architecture decision, not proof that Genkit is mandatory. 7. Use traces and evals before widening rollout. 8. Sync compact discovery surfaces whenever the front-door boundary changes.

References

• Firebase Genkit docs: https://firebase.google.com/docs/genkit
• Genkit docs: https://genkit.dev/docs/
• Genkit flows docs: https://genkit.dev/docs/js/flows/
• Genkit client access docs: https://genkit.dev/docs/client/
• Firebase AI Logic docs: https://firebase.google.com/docs/ai-logic
• ../firebase-ai-logic/SKILL.md
• ../firebase-cli/SKILL.md
• ../survey/SKILL.md

Genkit deployment and runtime boundaries

Use Firebase when

• the product already lives deeply inside Firebase
• callable/API integration should stay close to existing Firebase app workflows
• teams want one platform story for auth, app surfaces, and deployment

Watch for:

• secret handling
• deployment ownership
• keeping app-side AI work and backend AI work clearly separated

Use Cloud Run or another backend runtime when

• the team wants a clearer service boundary
• the AI workflow serves multiple surfaces or non-Firebase systems
• runtime control, networking, or scaling policy matters more than Firebase coupling

Watch for:

• auth between services
• rollout strategy
• cold starts / latency budgets
• logging and metrics ownership

Keep local-first when

• the flow boundary is still changing
• prompt quality is unstable
• tools or retrieval steps still need inspection

But do not confuse local trace success with production readiness.

Decision prompt

Ask: 1. Who owns the workflow in production? 2. Which clients must call it? 3. Does the team want Firebase alignment or a more explicit service boundary? 4. What must stay server-side for security or policy reasons?

Genkit evals and observability

Start with a tiny quality loop

Before scaling usage, define:

• 3-10 representative inputs
• what success looks like
• what failure is unacceptable
• whether review is human, automatic, or mixed

Good Genkit quality signals

• schema-valid structured output
• retrieval actually improves answers
• tool calls happen only when justified
• traces are understandable enough to debug regressions
• deployment logs and runtime metrics match product expectations

Common failure patterns

• prompt compensates for a bad schema
• retrieval is noisy, so the model looks worse than it is
• tool use is added before one basic flow is stable
• nobody can explain where the output broke in the trace
• "we'll add evals later" becomes permanent

Practical operator loop

1. Run the flow locally in Developer UI 2. Inspect traces on representative inputs 3. Add or refine a small eval set 4. Fix prompt/schema/tool boundaries 5. Re-run before widening rollout

Route-outs

If the team mainly needs app-side abuse controls, client integration, or Firebase SDK usage, route back to firebase-ai-logic. If the team mainly needs platform logging/ops, pair with monitoring-observability.

Genkit intake packets and fallbacks

Pick the packet the user already has

1. New backend capability packet

Use when the user has a feature brief, product request, or API idea and wants one reusable server-owned AI capability.

Good signs:

• one backend responsibility is emerging
• multiple clients or internal tools may call the same capability
• typed input/output and ownership matter

Next move:

• choose flow-foundation, tool-and-agent, or retrieval-and-prompt
• define one smallest flow contract

2. Existing route/handler packet

Use when the team already has a Next.js / Express / Fastify / server route and wonders whether to wrap it in Genkit.

Good signs:

• prompt logic is duplicated across handlers
• tool/retrieval steps are starting to sprawl
• observability/evals are hard because there is no clear workflow boundary

Next move:

• decide whether the route should stay a plain handler or become one named flow
• only promote to Genkit if reuse, tracing, or workflow structure materially matters

3. Deployed flow quality packet

Use when Genkit already exists and the pain is confidence, not initial setup.

Good signs:

• traces exist but nobody trusts the workflow
• structured outputs are flaky
• prompt/tool/retrieval regressions are reaching production

Next move:

• choose evaluation-and-observability
• define representative inputs and the smallest eval loop

4. Deployment/runtime packet

Use when the flow exists and the main uncertainty is Firebase vs Cloud Run vs another service boundary.

Good signs:

• the feature already works locally
• rollout, auth, secret ownership, or client access is the real question
• the team is asking where the workflow should live in production

Next move:

• choose deployment-runtime
• decide owner, callers, and server-only responsibilities before naming commands

5. Comparison/fallback packet

Use when the user is still deciding whether Genkit should exist at all.

Good signs:

• “Genkit or Firebase AI Logic?”
• “Genkit or direct SDK calls?”
• “Should this just be a route handler / queue worker / Vercel AI SDK feature?”

Next move:

• choose comparison-or-fallback
• route to survey if a real architecture comparison is needed
• keep a plain-SDK fallback visible if the capability is too small for Genkit

Fallback gradient

Treat these as legitimate alternatives, not failures:

1. Direct Firebase app/client integration

• Best fit: firebase-ai-logic
• Use when the job is in-app/mobile/web SDK usage, App Check-aware clients, or direct Gemini features in the product surface.

2. Plain provider SDK + route handler

• Best fit when one synchronous backend capability is small, isolated, and unlikely to need reusable flow structure yet.
• Mention this fallback when Genkit would be more framework than benefit.

3. Queue/job/durable workflow substrate

• Best fit when retries, background execution, or long-running orchestration dominate the problem.
• Genkit can complement this, but it should not hide the fact that durability may be the first design choice.

4. Framework comparison

• Best fit: survey
• Use when the user has not yet chosen between Genkit, Firebase AI Logic, Vercel AI SDK, LangChain, or direct SDKs.

5. Firebase platform operations

• Best fit: firebase-cli
• Use when the work is mostly bootstrap, emulators, deploys, auth/login, or admin operations.

Short decision prompts

Ask these internally before choosing Genkit: 1. Is the capability server-owned, or is it really an app/client feature? 2. Will more than one route/client/job reuse this logic? 3. Are traces, evals, typed contracts, or tool/retrieval boundaries important enough to justify a framework layer? 4. Would a plain route handler or queue worker solve the problem with less overhead? 5. Is the user actually asking for a framework comparison instead of an implementation brief?

Genkit modes and routing

Mode selector

1. Flow-foundation mode

Use when the main need is one reusable backend AI capability with a clean contract.

Good fits:

• summarize or classify content server-side
• expose one AI-backed endpoint to multiple clients
• convert duplicated prompt logic into one maintainable flow

2. Tool-and-agent mode

Use when the flow must trigger deterministic actions or coordinate with trusted tools.

Good fits:

• support assistant that files tickets
• internal copilot that queries one or two services
• backend workflow with explicit model/tool boundaries

3. Retrieval-and-prompt mode

Use when grounding and prompt management matter more than raw generation.

Good fits:

• knowledge-backed assistant
• doc-grounded answerer
• prompt-file-driven feature with structured output

4. Evaluation-and-observability mode

Use when Genkit already exists and the bottleneck is confidence, not implementation.

Good fits:

• launch-readiness checks
• prompt regressions
• flaky structured outputs
• traces nobody has reviewed yet

5. Deployment-runtime mode

Use when the flow exists and the open question is how or where to run it.

Good fits:

• Firebase vs Cloud Run choice
• callable/API shape decisions
• secret/config ownership
• rollout and monitoring planning

6. Comparison-or-fallback mode

Use when the user is still deciding whether Genkit should exist at all.

Good fits:

• Genkit vs Firebase AI Logic
• Genkit vs direct SDK route handler
• Genkit vs Vercel AI SDK / another framework
• small backend feature that may not justify a workflow layer

Route-outs

• Direct Firebase app/client SDK integration → firebase-ai-logic
• Firebase CLI / emulator / project operations → firebase-cli
• Generic architecture / framework discovery → survey
• Frontend-only app wiring → relevant web/frontend skill
• Thin synchronous backend model call → plain provider SDK / route-handler fallback
• Durability / retries / background execution dominating the problem → queue/job/workflow substrate note

Boundary reminder

If the request never leaves the app layer, never needs server-owned orchestration, or is still mostly a framework-choice question, Genkit is probably not the right first answer.