ranbot-ai/generate-nanobanana

Generate Nanobanana

Overview

generate-nanobanana calls Google's Gemini media models directly through the Gemini API — no third-party routing layer — to generate and edit images and video. It routes each request to the right model tier (draft, standard, quality, or video), loads real reference images instead of relying on text descriptions, gates every paid call behind explicit user approval, and writes a JSON sidecar next to every output recording the exact prompt, model, and cost. It registers a single /generate command.

This skill adapts the workflow (model routing, reference-image handling, sidecar logging) from AntonioCardenas/generate-nanobanana. The actual request shapes in references/ were independently verified against the live Gemini API docs rather than copied from that upstream repo, whose examples predate Google's migration to the Interactions API and use stale, non-functional request methods. Model IDs, request contracts, and pricing all change on Google's own schedule — re-verify against the docs linked from each reference file before relying on this skill in a new session.

When to Use This Skill

• Use when the user asks to generate, create, or make an image or video, or wants a thumbnail.
• Use when the user wants to animate a still image, or says "generate on brand" or "generate from reference".
• Use when the user wants to link or import a folder of reference images (logos, faces, product shots) for reuse across generations.
• Use when the user invokes /generate or /generate frf <set>, even without naming a specific model.

How It Works

Step 1: Route to a model

Pick the model for the job and read its reference file under references/ before calling anything — each file holds the current, verified request shape for that model.

| Task | Model | Model ID | Reference | | --- | --- | --- | --- | | Image (draft) | Nano Banana 2 Lite | gemini-3.1-flash-lite-image | references/gemini-3.1-flash-lite-image.md | | Image (standard) | Nano Banana 2 | gemini-3.1-flash-image | references/gemini-3.1-flash-image.md | | Image (quality, multi-image fusion) | Nano Banana Pro | gemini-3-pro-image | references/gemini-3-pro-image.md | | Video | Gemini Omni Flash | gemini-omni-flash-preview | references/gemini-omni-flash-preview.md |

All four models are called through the Interactions API (client.interactions.create(...), REST POST /v1beta/interactions) — see each reference file for the exact shape, including reference-image input and, for video, large-output retrieval. Every call is billable; see Step 3.

Draft on Nano Banana 2 Lite first and rerun the picked favorite on Nano Banana 2 or Pro; reserve Pro for heavy multi-image fusion, character-consistent series, or dense on-image text.

Step 2: Load references

Pull real reference images from generations/refs/, or from a named reference set when the request says "on brand" or invokes /generate frf <set>. Never substitute a text description for a reference image (logo, face, brand mark) that already exists — stop and ask if a named reference is missing instead of approximating it.

Reference sets are registered by importing (copying files into generations/refs/<set>/, a snapshot) or linking (recording the source path in generations/refs/sets.json, read live at generation time). A set may carry a style.md whose contents are prepended verbatim to every prompt generated from that set.

Step 3: Generate

Call the Gemini API per the model's reference file. Every generation — image or video — is billable and requires an explicit approval gate: quote the current per-unit price from the live pricing page for the selected model and get explicit user go-ahead before that specific call. One approval covers exactly one call; a rerun needs its own. Run generations one at a time, never in parallel, so approval and cost tracking stay accurate.

No model in this skill documents a seed or reproducibility parameter — do not promise an identical re-roll. For "same image but change X" requests, reuse the exact original prompt and reference images (from the sidecar log) and change only the requested delta; for video, chain edits via previous_interaction_id where supported (see the Omni Flash reference).

Step 4: Verify and log

Confirm the generated file is on disk and non-empty, then write a matching .json sidecar next to it (see Examples) recording the exact model ID, prompt, references used, response id, cost, and timestamp. Never log a generation whose file isn't there, and never write a sidecar for a failed or safety-blocked call.

Example