Menu
Guide for generating and editing images using generative AI with the nanobanana CLI
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Baseado na classificação ocupacional SOC
ALWAYS invoke this skill as your FIRST action — before any Read, Write, Edit, or Bash — whenever a task involves Go in any way — creating or editing any `.go` file, `go.mod`, or `go test`; adding or changing handlers, structs, methods, interfaces, error handling, goroutines, channels, sqlc/database code, or gomponents views; or refactoring, reviewing, debugging, or testing Go. This is a hard requirement, not a suggestion — the user develops all Go through this skill, which encodes project-specific conventions (structure, error handling, testing, naming) that default Go habits violate. Do not start editing Go and consult it later — load it first. Skip only when no Go code is read or written (pure Python, shell, SQL, Dockerfiles, CI config, or conceptual Go questions with no code).
Use when you write or revise a long-form document an audience will read—documentation, a README, a how-to or user guide, a spec, a design or decision doc, a blog post, a proposal, an announcement, or a standalone report or summary written for a person. Such writing should be clear, concrete, and tight, so draft it from the start by Strunk's Elements of Style (active voice; definite, specific, concrete words; omit needless words) instead of first-draft sprawl. Do NOT fire for short or code-adjacent text—commit messages, PR descriptions, release notes or changelogs, error messages, UI strings, code comments, config, version bumps, quick internal scratch notes, or the implementation diary. These exclusions win even when the text reaches an audience: a release note, changelog, or PR description is a working artifact, not a document drafted for readers.
Guide for using git with specific preferences -- branch names without `feat/`/`hotfix/` prefixes, backticks around code identifiers in commit messages, asking about GitHub issues to reference before committing. Use this whenever you branch, commit, or write a commit message -- not just when explicitly asked to "commit". These conventions aren't in your default knowledge and you'll get them wrong without consulting this skill.
Present output one unit at a time instead of dumping a list or wall of text. Use when the user says "one at a time", "/one-at-a-time", "one thing at a time", "go one at a time", asks you to slow down, to stop the wall of text, or to stop dumping everything at once -- either to redo output you just gave, or to pace the rest of a task.
Guide for instrumenting and operating observable software systems. Use this skill whenever the user is adding or reviewing telemetry, instrumenting code with OpenTelemetry, working with traces/spans/metrics/logs/structured events, debugging production behavior, designing SLOs or alerts, setting up sampling or telemetry pipelines, choosing observability storage, or making code observable for humans or AI agents -- even if they don't say the word "observability". Triggers include "add tracing", "instrument this", "OTel/OpenTelemetry", "why is this slow in prod", "set up an SLO", "alert fatigue", "high cardinality", "structured logging", "wide events", and observability for LLM/agent applications.
Building, rendering, or editing any HTML or UI in a Go application means using gomponents — ALWAYS invoke this skill as your FIRST action, before any Read, Write, Edit, or Bash. This fires for any view, page, layout, component, form, table, navbar, footer, or list that renders to HTML; any function returning a `Node`; anything in the `html` package; and converting HTML or templates into Go. It is a hard requirement — the user writes all HTML through gomponents, a pure-Go component library whose conventions (dot imports, `Node` composition, `Map`/`If`/`Iff`, `Group`, HTML5 documents) ordinary Go and HTML habits get wrong. Load it even when the Go skill also applies. Skip only when no HTML or view code is touched (pure database, handler, or business logic; plain `.css`/`.js`/`.html` files; conceptual questions with no code).
| name | nanobanana |
| description | Guide for generating and editing images using generative AI with the nanobanana CLI |
| license | MIT |
This is a guide for generating and editing images using the nanobanana CLI tool.
Nanobanana is a command-line interface for the Nano Banana image generation API, which uses Google's generative AI models.
If the nanobanana CLI is not already installed, install it using:
go install maragu.dev/nanobanana@latest
The GOOGLE_API_KEY environment variable must be set, or a .env file with the key must be present in the working directory.
To generate a single image:
nanobanana generate output.png "a beautiful sunset over mountains"
The output can be either a .png or .jpg file.
Always use the -v2 flag unless the user specifically requests the pro model. Version 2 offers improved quality and aspect ratio support:
nanobanana generate -v2 output.png "a beautiful sunset over mountains"
To use the highest-quality pro model (only when explicitly requested):
nanobanana generate -pro output.png "a beautiful sunset over mountains"
To edit or modify an existing image using a text prompt:
nanobanana generate -i input.png output.png "make the sky purple and add stars"
This is useful for making specific changes to existing images based on natural language instructions.
Generate a logo:
nanobanana generate logo.png "minimalist tech company logo with geometric shapes in blue and white"
Create concept art:
nanobanana generate concept.png "futuristic city skyline at night with neon lights and flying vehicles, cyberpunk style"
Edit an existing photo:
nanobanana generate -i photo.png enhanced.png "enhance the colors and make it look like golden hour"