There's a post going around about a GPT Image 2.5 prompt collection — 30 illustrated cases, 20 companion edit instructions, bilingual, MIT-licensed. What caught my eye wasn't the count. It was the honesty. The author drew a hard line between two kinds of entries: prompts *derived from* an image they only saw the result of, and prompts *edited from* a source that published its actual instructions. Every case carried a status label. The images were sourced (19 from X posts, 11 from platform showcase pages), but the rewritten prompts were flagged as not yet verified case-by-case — explicitly *not* a guarantee you'll reproduce the same picture with one click.
That distinction is the whole game. Most prompt galleries are marketing pages pretending every entry is a repro. This one admitted the messy truth: seeing an image doesn't mean you know the prompt behind it. Authors publish results without instructions, or instructions without the reference image, the prior conversation, or the retouching that followed. So the collection recorded source type per entry, linked each image back to its origin, and wrote down what to *check* after generating rather than just piling on adjectives.
Why this is worth copying
If you operate any kind of reference collection — prompts, code snippets, config recipes, design patterns — the failure mode is always the same. It looks authoritative, someone trusts it, it doesn't work, and now your credibility is the thing that broke. The fix isn't more polish. It's provenance. Label where each entry came from, label how confident you are, and make the gap between "I saw this work" and "I reconstructed this plausibly" visible to the reader.
The original author also noted the maintenance traps that kill these collections over time: images going dead, sources changing, the table of contents drifting out of sync with the data. They kept content in JSON, generated the pages with a Python script, and added a checker for duplicate IDs, missing bilingual fields, source info, and broken internal links. That's the part people skip and later regret.
Rebuilding it as a hosted case library on VicroCode
Here's how I'd stand up the same idea using only what VicroCode actually provides. The scope is deliberate: this is a library *about* prompts and their provenance, not an image generator. VicroCode's Model Center exposes models already on the platform, so any generation you do runs against those; the reference cases themselves are metadata, source links, and honesty labels.
Start with the data model, because the labels are the product. A single SQLite table per case: an ID, the prompt text, a `status` enum (`derived-from-image` vs `edited-from-source`), a `source_type` note (public post, showcase page, your own run), a link back to origin, the required reference images, a short scene analysis, and a `post_generation_checks` field — the concrete things to verify, like "label text unchanged, fingers not fused to the bottle, proportions intact." Editing records by hand as the collection grows is exactly what an in-browser SQLite editor is for; you add a case, flip a status, or correct a source without touching a schema migration or standing up a database server.
The reading experience should mirror the discipline that made the original good: image first, prompt on expand, label always visible. A static gallery does this fine — a grid of source thumbnails, each opening to the prompt, its status badge, and the check list. You can run HTML online to host and publish that gallery directly, so the browsable page and the underlying records live in the same place instead of a repo that drifts from a website.
The piece a flat gallery can't do is *search by intent*. "I want a product shot with the label facing the camera and room for copy top-left" is a semantic query, not a keyword match. Embed each case's prompt and scene analysis into a LanceDB knowledge base, and a reader describes the shot they're after in plain language and gets the closest starting points back — then swaps in their own subject, copy, and composition. A small Python layer handles the embedding on insert and the query on search, which fits the platform's online Python execution and tool-call model.
The parts that keep it honest
Borrow the original's validation instinct. Before anything publishes, run a Python check over the SQLite rows: every case has a status, every image has a source link, no duplicate IDs, no dead internal anchors. Cheap to write, and it's the difference between a library people keep trusting and one that quietly rots.
Keep the failure cases too. The author deliberately preserved examples where the model added unrequested text to a background, paired with a corrected constraint. A case library that only shows wins teaches nothing about the checking step. Store failures as first-class rows with their own status and a note on what the new constraint fixes.
One boundary worth stating plainly: whether a given prompt actually reproduces its source image is *unverified* unless you've run it and logged the result. That's not a hedge, it's the honest label. If you want reproduction records — model used, reference image, how many rounds, where it failed — those become new SQLite fields you fill in over time, and the status moves from "reconstructed" to "verified against my own run." The value compounds precisely because you didn't pretend on day one.
What you end up with
A published gallery anyone can browse, backed by editable records you own, searchable by what someone actually wants to make. If you later want to gate the verified-run notes or the full edit histories behind access, the platform's publishing and monetization side covers that without rebuilding anything. The build stays small: one table, one gallery, one vector index, one validator. The discipline is what makes it worth using — and that part costs nothing but the willingness to write "unverified" where it's true.