Just built a prompt library for our agency. Sharing the structure.

Totally agree about the raw command being the core artifact. It's the only real "recipe."

I'd add that it's worth saving the raw command *as you ran it*, even if it's messy or has typos. We tried cleaning them up into separate fields, and it became impossible to reproduce the exact output. That raw string is the source of truth.

And you're right about archiving an intention. I've seen teams update a "perfect" prompt library entry for the new model version, which completely breaks their old assets because they don't realize the old parameters don't apply the same way. The full command freezes the moment.

Nice start with the Notion setup. Getting prompts out of Discord is such a relief.

I'm curious, how do you handle revisions? When a prompt gets tweaked for a new project, do you create a new entry or update the old one? I've seen that become a problem when you lose the original recipe.

That checkbox idea sounds nice in theory, but you're just adding metadata to a broken process. A "happy accident" flag doesn't help you reproduce it, which is the whole point of logging.

If you're serious about the library being an idea generator, then the "actual style" tag is just a guess after the fact. The real value is in logging the raw parameters that *caused* the accident, so you can intentionally steer into that style later. Otherwise you're just building a museum of cool things you can't remake.

Your Notion foundation is exactly where we started too. The key field you're missing, given your goal of brand consistency, is the full parameters string as a single, immutable text block. The seed number alone is useless without the model version and all the command flags that were active when you ran it.

Think of your library as an archive of executable recipes, not just descriptions. Each entry should contain the exact command that can be pasted back into Discord to recreate the image within that specific model's runtime. A change from `--stylize 100` to `--stylize 750` under the same seed produces a completely different result, which directly undermines visual consistency.

We added a "Raw Command" field and treat it as the primary artifact. Everything else, like the project name or style tag, is just metadata for searchability. You can't rebuild the asset from the metadata.

You're right that the raw command is the artifact, but I'd go further. It's also your primary negotiation lever when a vendor changes their model.

Treat the raw command string as your baseline SLA. If you can't reproduce the output after a model update, you now have a specific, documented breaking change to point to when arguing for credits or a rollback. The "just metadata" fields become your cost of migration - they show the scope of what's broken.

Without that exact command, you're just complaining about vibes. With it, you can prove the breach of reproducibility.

You're freezing assets, but still trying to search them? That's the core contradiction. They're frozen because they're dead. You can't have both a museum and a workshop.

If a style is truly worth keeping, you have to port it. The search problem is your signal that the "reference-only" stuff is just digital hoarding. The graveyard feeling is accurate. Stop searching it.