10,000 Prompts, a CMS, and a GitHub Actions Pipeline That Keeps the README Fresh

What it does

awesome-nano-banana-pro-prompts is a curated collection of 10,000+ prompts for Google's Nano Banana Pro AI image generation model, organized by category and translated into 16 languages. The README is auto-generated from a headless CMS every 4 hours.

Why I starred it

Most "awesome" lists are just hand-maintained markdown files. This one has actual infrastructure behind it. The prompts live in a Payload CMS, get synced through GitHub Issues, and the README is regenerated by a TypeScript pipeline running on a cron. That's a different level of effort for an awesome list, and the architecture is worth studying.

How it works

The repo has no src/ directory. The entire codebase lives in scripts/ — four TypeScript files and a utils folder that do all the heavy lifting.

The CMS-to-README pipeline

scripts/generate-readme.ts is the entry point. It loops through all 16 supported languages, fetches prompts and categories from a Payload CMS instance, sorts them, and writes locale-specific README files (README.md, README_zh.md, README_ja-JP.md, etc.).

The CMS client in scripts/utils/cms-client.ts uses qs-esm to build query strings for the Payload REST API. The fetching strategy is two-pass: first grab featured prompts (up to 30, sorted by -featured, sort, -sourcePublishedAt), then iterate over every use-case category and fetch up to 20 prompts each. Deduplication happens via a Set of prompt IDs:

const seenIds = new Set(featuredPrompts.map((p) => p.id));

for (const category of useCaseCategories) {
  const prompts = await fetchPromptsByCategory(
    category.id,
    category.title,
    locale
  );
  for (const prompt of prompts) {
    if (!seenIds.has(prompt.id)) {
      seenIds.add(prompt.id);
      categoryPrompts.push(prompt);
    }
  }
}

This is straightforward but sequential — each category fires its own HTTP request. With 20+ categories, that's 20+ API calls per language, times 16 languages. The workflow runs every 4 hours so latency doesn't matter much, but it's not built for speed.

Issue-to-CMS sync

scripts/sync-approved-to-cms.ts handles community contributions. When someone submits a prompt via a GitHub Issue template and a maintainer approves it, a workflow triggers this script. It parses the issue body by splitting on ### headings, maps field names (the issue template uses display labels like "Original Author" which get normalized to author_name), downloads any attached images, re-uploads them to the CMS via scripts/utils/image-uploader.ts, and creates or updates the prompt record.

The field name mapping is explicit:

const FIELD_NAME_MAP: Record<string, keyof IssueFields> = {
  'generated_image_urls': 'image_urls',
  'original_author': 'author_name',
  'author_profile_link': 'author_link',
  'prompt_language': 'language',
  'need_reference_images_': 'need_reference_images',
};

A cleanFieldValue function strips _No response_ placeholders from the GitHub Issue form. Small detail, but it avoids junk data in the CMS.

Markdown generation

scripts/utils/markdown-generator.ts is the largest file (~400 lines). It builds the README section by section — header, language navigation badges, gallery CTA, table of contents, stats, featured prompts, regular prompts, footer. Each section is a pure function returning a markdown string.

One detail I liked: the cleanPromptContent function strips code fence markers (```) from prompt text before rendering. Community-submitted prompts often arrive wrapped in code blocks, and this normalizer handles nested or misformatted fences gracefully with a multi-pass regex approach.

The README caps at 120 regular prompts per language to avoid GitHub's rendering limits, then links out to the web gallery for the rest.

i18n

The scripts/utils/i18n.ts file provides a t() function used throughout the markdown generator. All 16 languages have translation keys for UI strings like "Featured Prompts", "Browse by Category", "Submit New Prompt". The CMS handles content translation (prompt titles, descriptions) while the i18n module handles structural text.

Using it

The repo is a content library, not a CLI tool. The main interaction is browsing prompts:

# Clone and generate READMEs locally
git clone https://github.com/YouMind-OpenLab/awesome-nano-banana-pro-prompts.git
cd awesome-nano-banana-pro-prompts
cp .env.example .env
# Fill in CMS_HOST and CMS_API_KEY
pnpm install
pnpm generate

For most people, the value is just reading the README and copying prompts to use with Gemini's image generation.

Rough edges

The entire pipeline depends on a private CMS instance. Without CMS_HOST and CMS_API_KEY, you can't run pnpm generate locally — which means you can't verify the output or contribute to the tooling without access. The repo is open source, but the data layer isn't.

There are no tests. Zero. The TypeScript is well-structured enough that it probably doesn't break often, but there's nothing guarding against a CMS schema change or a malformed issue body.

The sequential category fetching could be parallelized with Promise.all, but since it only runs in CI every 4 hours, nobody's felt the pain.

Git history is entirely automated docs: auto-update README [skip ci] commits — dozens per day. The actual code changes are buried under machine-generated noise. Last meaningful code commit is hard to find.

The 10,000+ prompt count is impressive but also means the README files are massive. GitHub's markdown renderer struggles with files this large, which is why they cap at 120 prompts and redirect to their web gallery.

Bottom line

If you're working with Google's Nano Banana Pro model and want prompt inspiration, the collection is genuinely large and well-categorized. If you're building your own CMS-backed awesome list or automating README generation from structured data, the scripts/ directory is a clean reference implementation worth reading.