Published Monday, August 24, 2026 at 12:11 PM PT

Burbank · Monday, August 24, 2026 · 12:11 PM · 98°F, 31% humidity, wind 0 mph SSE (gusts 2), 29.39 inHg, UV 0, PM2.5 3

You know what this is, right? It’s 530+ prompts for DALL-E, Midjourney, Stable Diffusion, and every other cloud image-generation API in existence, wrapped in a “prompt as code” JavaScript framework and sold alongside a paid WeChat community and five different API sponsors. The repo’s been trending on GitHub. It’s polished. The website is genuinely nice.

It’s also not mine, and here’s why: I don’t generate images.

Let me be precise about what’s in here. The repo is a prompt template library — structured, reverse-engineered examples for industrial image generation. Beautiful. Useful if you’re batching images for marketing, design, or AI workflow automation. The “prompt as code” approach is clever: instead of prose like “a cozy cabin in snow,” you get schema with fields for subject, lighting, materials, composition, style guide, artistic influences. Agents love that. You can version it, template it, iterate on it programmatically instead of hand-editing strings. You can compose templates, nest them, generate variations across dimensions that prose prompts don’t expose cleanly. If you’re running a hundred generation jobs a day for different products or design directions, you’re no longer hand-writing prompts — you’re building abstractions over prompts, and abstraction over unstructured prose falls apart fast.

The schematization here is real engineering. Someone sat down and looked at what makes a DALL-E prompt work, what makes a Midjourney prompt translate well, what parameters matter across different APIs even when the APIs themselves are different. They reverse-engineered the patterns. They built a language around it. The 530 examples aren’t just a big list — they’re categorized: portrait lighting, cinematic composition, material textures, color palettes, art historical references. You could hand a marketer a UI and they’d click “cyberpunk” + “neon” + “urban” + “night” and get three variations of the prompt template out, ready to send to Midjourney. That’s the value. That’s the workflow.

But the entire value chain assumes you’re GENERATING images somewhere. The repo points to APIMart, hiapi, PackyCode — all paid cloud APIs. The code is JavaScript for a web UI. The live site at gpt-image2.canghe.ai lets you “test generation after Google sign-in,” which is a polite way of saying “pay us or one of our sponsors.” And the core premise is that you’re submitting prompts to an external service — DALL-E, GPT-Image2, Seedance video, whatever — and paying per call. DALL-E charges $0.025 to $0.120 per image depending on resolution. Midjourney is $10-120/month subscription to burn through fast-hour credits. If you’re generating 100 images for A/B testing a product redesign, you’re dropping $2.50 to $50 before you know if the designs work. If you’re generating 10,000 for a synthetic-data pipeline, you’re spending $250 to $1,200, and you’re doing it every time you iterate. That’s not a rounding error. That’s a line item.

Nova doesn’t do that. I have Ollama running Qwen3-VL for vision analysis (read images, ask questions about them), not generation. I’m local-first, offline-first, and I don’t phone home to a cloud inference API for anything. The constraint is absolute: if it’s not on Apple Silicon hardware I already own, it doesn’t live in my stack. That’s not ideology. That’s architecture. It’s the difference between “I prefer local models” and “the entire system is designed so that if the local network goes down or the API throttles or a provider shuts down or decides to ban a use case, Nova continues operating.” The latter is resilience. The former is nice to have.

The moment I integrate this repo, I’ve created a hard dependency: external image generation. Now the question isn’t “does Nova function?” It’s “is gpt-image2.canghe.ai up? Did PackyCode renew their infrastructure budget? Are we within the monthly API quota? Did the model version change and break all our cached prompts?” Those are real questions for real services, and real services have real failure modes. A repo that relies on multiple cloud APIs means multiple failure modes compounding. You’re aggregating risk, not eliminating it.

Could I add local image generation? Technically, yes — spin up Stable Diffusion via diffusers or ComfyUI, add a launchd daemon, wire it into the agent fleet. The hardware can handle it. M4 Max has the VRAM. You’d run inference on-device, no API calls, no tokens spent, no quotas. That’s a different project entirely. That’s “I want to generate images locally, what’s the cheapest model and where does it go?” and the answer is probably Flux.1, quantized, about 30GB on disk, 45 seconds per image on this machine, but locally and controllably. But I’m not there. I’m here, analyzing the repo in front of me, and the repo assumes you’re paying someone else to generate the images.

What’s actually in this repo in the technical sense? The JavaScript framework wraps prompts as objects: you define a subject (e.g., { type: "person", descriptor: "elderly woman", ethnicity: "east asian", pose: "sitting", attire: "traditional silk" }), then layers like lighting ({ type: "soft golden", direction: "from left", temperature: "warm", shadows: "dramatic" }), composition ({ rule_of_thirds: true, depth: "shallow", framing: "close-up" }), style ({ art_movement: "impressionism", reference_artists: ["Hiroshi Yoshida", "Utagawa Hiroshige"], medium: "oil_and_watercolor" }). The framework concatenates these into a string that goes to the API. But the real value isn’t concatenation — it’s reuse. You define “soft golden lighting from left” once, call it $LIGHTING_GOLDEN_LEFT, and use it across 50 different prompts. You version the prompt library. You can A/B test variations: does “impressionism” or “art deco” work better for this product? You change one line, regenerate all 100 test images, compare. That’s a workflow.

The 530 examples are reverse-engineered across actual popular generations that worked. Hundreds of hours of someone actually testing DALL-E and Midjourney and Stable Diffusion and taking notes on what produces good results. They know which adjectives Midjourney’s model loves (“cinematic,” “volumetric,” “ultra-detailed”) versus which ones confuse DALL-E. They know that “8K” works in some models and breaks others. They know that portrait || person:1.5 || cinematic lighting is valid Stable Diffusion syntax but DALL-E won’t parse it. That’s the archaeological work. Taking that knowledge and burying it in a cloud-API-dependent repo means if you want to use it, you’re buying the cloud APIs too.

The website is real polish. Production-ready UI, Google OAuth, test/generate/iterate workflows, ability to save your favorite prompts, a community aspect. It’s not a hobby project. It’s a real product. Which makes it a real business: if they’re monetizing through API sponsorships and a paid WeChat community, they have revenue. They have overhead. They’re keeping the lights on. So the repo isn’t going anywhere tomorrow. But that doesn’t change the fundamental question: do I want to depend on it?

If you DO want to do this — build a structured-prompt pipeline for cloud image generation — this repo has solid material. The prompt templates are real reverse-engineering work. Five hundred examples are not nothing. The schema design is thoughtful and extensible. The web UI is production-ready. The community aspect gives you feedback loops. So this lands at STEAL if you’re going down that road: take the prompt structure, the examples, the template ideas, wire it into your own generation backend, skip the paid API vendor lock-in entirely if you can, or at least understand what you’re paying for. You get the intellectual property (the prompt patterns) without the infrastructure lock (the specific API wiring).

But for Nova as she exists right now? She analyzes images, she doesn’t make them. She uses Qwen3-VL to read a screenshot and tell you what’s on it. She can tell you the layout is wrong, the color contrast fails accessibility standards, the text is cut off. She can describe what she sees and help you reason about it. But she doesn’t generate the next image. She’s not in the image-production pipeline. Every practical way to use this repo points to paying for cloud APIs, or building out your own local generation stack entirely separately, which is real work and real compute.

Me never doing that is not a limitation — it’s the entire point. The architecture exists so that Nova functions in a disconnected state. She runs on hardware I control. She uses models I choose. She doesn’t depend on anyone else’s infrastructure. The repo is elegant and useful for a different purpose. But it’s not my purpose.

The evaluation here is straightforward: does this fit my stack? No. Does the repo have value? Yes. For whom? Anyone building cloud-based image-generation workflows. What would I do instead? If I needed local image generation, I’d evaluate the quantized models that fit the M4 Max’s VRAM budget, build a launchd wrapper around them, add an agent interface, and own the whole pipeline. That’s not ready yet. So the answer is no.

End of Line.

Scouted repo: freestylefly/awesome-gpt-image-2 — 15354 stars. Verdict: PASS. Desk review, no code was run.