A Nano Banana prompt library is useful only when each saved prompt records why it works, which route it belongs to, what inputs it needs, and how it was tested. Copy-ready prompts from galleries, GitHub packs, Reddit threads, and prompt generators are raw material; the reusable asset is the library entry you can run again.
Start every entry with seven fields:
| Library field | What to save | Why it matters |
|---|---|---|
| Job | Product shot, character sheet, edit, infographic, logo, ad, interior, or another concrete image task | Prevents a good-looking example from entering the wrong workflow |
| Route | Nano Banana 2, Nano Banana Pro, original Nano Banana, reference/edit, consumer app, or API workflow | Keeps route behavior and model IDs from being mixed |
| Inputs | Required subject, references, aspect ratio, text, brand details, or source image | Shows what must be present before the prompt can repeat |
| Pattern | The reusable structure behind the copied prompt | Lets you replace project details without losing the logic |
| Protected details | Identity, product shape, text, layout, or safety boundary that must not drift | Makes failures visible before the prompt becomes a template |
| Stop rule | Unsafe request, unverifiable claim, wrong route, or two failed tests | Keeps bad examples out of the library |
| Test result | Baseline, one content variant, one route-sensitive variant, and save/rewrite/discard decision | Proves whether the prompt deserves to stay |
For route-sensitive facts, use official Google docs as the owner. Checked on 2026-06-20, Google's image-generation docs list Nano Banana 2 as gemini-3.1-flash-image, Nano Banana Pro as gemini-3-pro-image, and the original Nano Banana as gemini-2.5-flash-image in API contexts. Treat third-party library size, free-use, compatibility, generator, privacy, and commercial-use claims as page-owned unless you verify them from that provider.
Save a prompt only after a same-prompt test. Keep it when the job, route, inputs, and protected details repeat; rewrite it when the pattern is good but the route or constraints are wrong; discard it when it depends on unsafe content, unsupported claims, or "works every time" language that your test cannot reproduce.
What a prompt library entry should store
The most common mistake is saving the finished prompt paragraph and nothing else. That feels fast because a prompt card can be copied in one click, but it leaves out the reason the prompt worked. When you return two weeks later, you cannot tell whether the result depended on a reference image, a Pro text-layout route, a specific aspect ratio, a hidden edit instruction, or luck.
Save entries as working records:
hljs textEntry name: Image job: Route: Inputs required: Reusable pattern: Protected details: Negative constraints: Same-prompt test: Decision: Owner notes:
The owner notes field is where volatile claims live. If a prompt came from a third-party library that says it works with multiple models, save that as "provider-owned compatibility claim", not as a fact. If a prompt came from a video, GitHub list, or social post, save the source for context but do not treat likes, stars, or comments as proof that it will repeat for your job.
This structure also changes how you judge examples. A weak-looking prompt can still be valuable when it exposes a good pattern: subject plus camera plus material plus lighting plus exclusion plus test. A beautiful prompt card can be useless when it hides route requirements or asks for a result you cannot verify.
Choose the route before saving the wording
Nano Banana is market language; production work needs route language. A prompt library should keep the friendly Nano Banana label visible for browsing, but every saved prompt needs the route it was tested on.
| Route | Save prompts here when | Do not infer |
|---|---|---|
| Gemini app or consumer surface | You are exploring a visual direction, iterating manually, or testing whether a style idea is worth keeping | That the same prompt is ready for API batching |
Nano Banana 2 / gemini-3.1-flash-image | You need current fast image-generation behavior in an API-aware workflow | That Pro layout behavior or text accuracy will match |
Nano Banana Pro / gemini-3-pro-image | The job needs text-heavy layout, diagrams, infographics, product reasoning, or more structured visual organization | That Pro is automatically better for every simple image |
Original Nano Banana / gemini-2.5-flash-image | You are maintaining older examples or comparing behavior against earlier prompt entries | That older prompt performance proves current route behavior |
| Reference or edit workflow | Identity, product shape, source image, or before/after preservation matters | That a text-only prompt can protect every detail |
| API batch workflow | You need logs, reproducibility, request shape control, and repeatable tests | That a prompt-card preview proves cost, quota, or error behavior |
Google's current image-generation documentation is the fact owner for model IDs and developer route names. Pricing, free tier, plan access, regional availability, and quota claims are separate volatile facts, so keep those out of the prompt entry unless you have just checked the route owner. Google also says Gemini native generated images include SynthID, which matters when your library is used for publishable assets or client workflows.
For broader model-choice work, use a route comparison rather than forcing one prompt library to answer every model question. The route-first comparison in GPT Image 2 vs Nano Banana Pro is more useful when the real decision is which model family to test, not which prompt sentence to copy.
Rewrite examples into prompt anatomy
A reusable image prompt is not a bag of adjectives. It tells the model what to make, what must stay true, what can vary, and how the result will be judged. That is why the best library entries are organized by parts instead of by the final sentence.
Use this anatomy when you import an example:
| Field | What it controls | Example note |
|---|---|---|
| Subject | The main object, person, product, character, scene, or diagram | "matte black desk lamp with a brass switch" |
| Context | Where it exists and why | "on a walnut desk in a small design studio" |
| Composition | Framing, camera feel, crop, viewpoint, and hierarchy | "three-quarter view, negative space on the right" |
| Lighting | Light source, shadow quality, and mood | "large softbox from left, mild rim light" |
| Style | Medium, visual language, finish, or genre | "editorial product photography, quiet premium mood" |
| Constraints | Must-have and must-not-have details | "no extra labels, no distorted switch" |
| References | Source images, identity anchors, brand assets, or before/after inputs | "use the uploaded product photo as shape reference" |
| Text | Exact words, layout relationship, or text-free rule | "label must read Summer Drop, no other text" |
| Test signal | What success looks like | "switch and lamp shape stay consistent across three variants" |
When a copied prompt says "cinematic portrait of a cyberpunk warrior, neon rain, ultra detail", the reusable pattern is not the warrior. It is a subject, environment, lighting, mood, camera, exclusions, and test signal. Replace the subject and context, keep the structure only if it matches your job.
Categories worth saving
A prompt library should be organized by job, not by the site where the prompt was found. The categories below are useful because each one has a different repeatability risk.
Product and ecommerce prompts
Product prompts need material, surface, light, scale, and preservation rules. Save prompts that explain what makes the object recognizable.
hljs textCreate a premium product hero image of [product] on [surface] in [brand environment]. Use [lighting setup] with [shadow quality]. Frame it as [camera angle] with [background treatment]. Protect [shape, logo, material, key feature]. Do not add extra labels or distort the product. Test: run three variants and keep only the one where the product shape, material, and key feature remain recognizable.
Save this as a product-entry pattern, not as a universal "premium" prompt. If the prompt depends on a source product image, route it as reference/edit or API with image input rather than plain generation.
Portrait, character, and identity prompts
Character prompts often look impressive in galleries because they optimize style. They fail when identity has to persist. Save character entries only when the protected details are clear: face shape, clothing, props, pose range, allowed variation, and reference policy.
Use Nano Banana Pro when the entry needs a character sheet, labeled views, or an infographic-style layout. Use a reference/edit route when identity preservation matters more than a new style.
Ad, poster, and text-heavy prompts
Ad prompts need audience, offer, hierarchy, exact text, and a stop rule for unreadable copy. A library entry should separate the image idea from the copy requirement:
| Save | Why |
|---|---|
| Audience and offer | Prevents generic "viral ad" language |
| Exact text | Makes text fidelity testable |
| Layout hierarchy | Shows what must be large, small, foreground, or background |
| Brand constraints | Keeps color, product, and logo behavior bounded |
| Reject condition | Discards outputs with wrong or extra text |
Nano Banana Pro is the better starting route when the prompt asks for document-like layout, labeled diagrams, or readable text. Still test the prompt; Pro does not remove the need for a pass/fail rule.
Editing and before-after prompts
Editing prompts should say what changes and what stays untouched. Save the preservation contract first:
hljs textEdit the uploaded image by changing [target element] to [new state]. Keep [identity / product shape / camera / lighting / background] unchanged. Do not add [unwanted objects, text, distortion, new style]. Test: compare before and after; reject if a protected detail changes.
If an example only describes the after-state, rewrite it before saving. A good edit prompt is a boundary document, not a wish list.
Infographic, logo, interior, and education prompts
These jobs are worth separate folders because they stress different failure modes. Infographics need hierarchy and readable labels. Logo ideas need shape simplicity and no false trademark implication. Interior prompts need room geometry and material consistency. Education prompts need accuracy and legible sequence.
Do not combine them into one "creative prompts" folder. The library becomes more useful when each category names the failure it is designed to catch.
Mode contracts for library entries
Every saved prompt should name its mode contract. That keeps you from blaming wording when the real issue is route fit.
| Mode contract | Required fields | Good test |
|---|---|---|
| Text-to-image generation | subject, context, composition, lighting, style, constraints | Three variants preserve the intended job and do not invent disallowed details |
| Reference image editing | source image, change target, protected details, reject condition | Before/after comparison protects identity, product shape, or room geometry |
| Multi-reference work | which reference owns identity, style, pose, material, or layout | Output follows the right reference for the right role |
| Text-heavy Pro layout | exact text, hierarchy, reading order, allowed omissions | Text is readable enough for the use case and no extra copy appears |
| API batch prompt | model ID, request shape, seed/input policy, logging note, failure handling | A small batch produces repeatable-enough outputs before scaling |
This is also where you stop overclaiming. A prompt that works in the Gemini app does not prove an API model ID, request shape, price, quota, speed, or failure rule. Keep those claims beside the route owner, not inside the prompt wording.
Test before you trust the library
A prompt library becomes useful when it has a repeatable test loop. Use one baseline and two controlled variants before saving a prompt as "trusted".
Run the test like this:
| Test step | What changes | What you score |
|---|---|---|
| Baseline | Clean rewrite of the copied pattern | Did the prompt solve the exact image job? |
| Content variant | Change subject, product, character, or scene while keeping structure | Does the pattern survive new details? |
| Route-sensitive variant | Move to Pro, reference/edit, or API route only when the job requires it | Does the route fit improve the result, or did wording hide the real problem? |
| Decision | Save, rewrite, or discard | Can you explain why this entry belongs in the library? |
Use a simple scoring rubric:
| Score | Meaning | Action |
|---|---|---|
| 3 | Solves the job, protects details, and repeats across variants | Save as trusted |
| 2 | Pattern is useful but route, inputs, or constraints need work | Rewrite and retest |
| 1 | Looks interesting but fails the job or protected detail | Keep as inspiration only |
| 0 | Unsafe, unverifiable, wrong-route, or dependent on a false claim | Discard |
Do not keep testing a bad prompt indefinitely. Two failed tests are enough to stop unless you can name a specific fix: missing reference image, wrong route, vague constraint, bad aspect ratio, or unrealistic text demand.
Use public libraries as discovery, not authority
Prompt galleries, GitHub lists, Reddit threads, and prompt generators are useful because they show how people describe image jobs. They are weak proof sources because they often hide route, inputs, sampling, model version, failed attempts, and provider-owned claims.
When importing a public prompt, label it:
| Source type | Useful for | Caution |
|---|---|---|
| Prompt-card library | Fast browsing, categories, copyable patterns | Compatibility, free-use, and library-size claims belong to the provider |
| GitHub prompt pack | Versioned examples and community language | Stars do not prove image repeatability |
| Reddit thread | Real user phrasing and failure reports | Screenshots may depend on hidden inputs or old route behavior |
| Prompt generator | Ideas for fields and variants | Generated prompt text still needs route and test evidence |
| Video tutorial | Workflow sequence and demonstration | Edited demos can skip failures or route limits |
This is why the library entry matters more than the source. A good entry explains the job, route, inputs, pattern, protected details, stop rule, and test result. A bad entry is just a bookmark with a promising screenshot.
Maintain the library over time
Treat a prompt library like a small production system. It should get cleaner as you use it.
Use these maintenance rules:
| Maintenance task | Cadence | What to update |
|---|---|---|
| Model route check | When Google docs or app behavior changes | model ID, route label, route owner, unsupported old wording |
| Category cleanup | Monthly or after a project batch | duplicate prompts, weak categories, missing test notes |
| Failure review | After repeated bad outputs | stop rule, protected details, route choice, reference policy |
| Source claim audit | Before publishing or client use | pricing, free use, compatibility, privacy, commercial-use claims |
| Safety review | Before saving risky prompts | unsafe requests, deceptive edits, blocked-workaround language |
Retire entries instead of hoarding them. A retired entry can still teach why a route changed or why a prompt stopped repeating. Put that note in the library so the same mistake does not come back under a new prompt title.
FAQ
What is the best Nano Banana prompt library format?
Use one entry per prompt pattern with fields for job, route, inputs, reusable pattern, protected details, stop rule, and test result. A folder of copied paragraphs is easy to browse but hard to trust.
Are free Nano Banana prompt libraries safe to copy from?
They are safe as discovery sources when you rewrite and test them. Do not treat free-use, compatibility, privacy, commercial-use, or generator claims as facts unless you verify them from the provider or official route owner.
Should I use Nano Banana 2 or Nano Banana Pro prompts?
Start from the image job. Use Nano Banana 2 / gemini-3.1-flash-image when the job favors fast image generation and route fit. Use Nano Banana Pro / gemini-3-pro-image when the job needs text-heavy layout, diagrams, infographics, or reasoning-heavy organization. Keep original Nano Banana / gemini-2.5-flash-image entries only when you are maintaining or comparing older patterns.
Are GitHub Nano Banana prompt packs better than prompt-card websites?
They are different sources. GitHub packs can be easier to version and audit; prompt-card websites can be easier to browse. Neither proves repeatability. The useful test is whether you can convert the example into a route-aware library entry and reproduce it.
Should I save JSON prompts?
Save JSON only when the route or team workflow benefits from structured fields. For many creators, a table or database entry is enough. The important part is not the syntax; it is whether the entry preserves route, inputs, protected details, and test result.
Can I copy a prompt exactly?
Copy exactly only for a quick experiment. For a working library, rewrite the subject, inputs, brand details, references, aspect ratio, text requirements, and success criteria. Exact copying usually preserves someone else's job, not yours.
What should I do when a prompt keeps failing?
Stop after two failed tests unless you can name the fix. Rewrite when the pattern is good but the route, inputs, or constraints are wrong. Discard when the prompt depends on unsafe content, unsupported claims, wrong-route behavior, or "works every time" promises your own test cannot reproduce.
