What belongs in a prompt pack people don't refund
A list of prompts is not a product. The contents template that separates a pack buyers keep from one they refund within the hour.
The refund message is almost always the same sentence: "These are just prompts." The buyer paid, opened a PDF with 120 lines of text in it, pasted the first one into whatever generator they use, got something that looked nothing like the sales-page grid, and asked for their money back inside the hour. Nothing was misrepresented. The prompts were real, the images on the sales page were made with them, and the pack still failed, because a prompt string on its own carries almost none of the state that produced the picture.
That gap is a specification problem, not a quality problem. It is also fixable with a contents list, which is what this post is.
Why a prompt alone doesn't transfer
Run the same sentence through two generators and you get two different pictures. Run it through the same generator twice with different settings and you still get two different pictures. The text is one input among six or seven, and the others are the ones that actually decide whether the buyer's first attempt looks like your sample:
- The model, and which version of it
- The seed, if the sample was reproducible at all
- Guidance or CFG strength, which decides how literally the sentence is followed
- The negative prompt, which is often doing more work than the positive one
- Aspect ratio, because framing changes composition, not just crop
- Any reference image and how strongly it was weighted
Ship the sentence, withhold the other six, and you have shipped a screenshot of a recipe. Buyers can tell within one generation. The fix is not more prompts. It is fewer prompts with everything attached.
The contents template
Six sections. A pack with all six can be a third the size of a "500 prompts!" bundle and hold its price better, because the buyer's first run works.
| Section | What it holds | What it prevents |
|---|---|---|
| Model-specific parameter sets | One prompt, one settings block per supported model | "It doesn't look like your example" |
| Reference assets | The actual images, palettes and style refs the samples used | Colour and style drift on run one |
| Failure notes | Known bad outputs and the exact fix | Buyer assumes the pack is broken |
| Variation grid | The axes the prompt is designed to move along | Buyer uses it once and stops |
| Version and changelog | A number, a date, what changed | Silent rot when a model updates |
| Update policy | What you will and won't re-cut, and how they get it | The angriest support emails |
Model-specific parameter sets
This is the section that earns the price. One prompt is not one entry — it is one entry per model you claim to support. If the pack says it works with three generators, there are three settings blocks, and each one has been run.
A usable block looks like this:
PROMPT
Overhead flat-lay of a ceramic pour-over set on warm oak, morning
window light from camera left, shallow depth of field, muted
terracotta and cream palette.
MODEL A — image
aspect ratio: 4:5
guidance: mid
negative: text, watermark, extra spouts, plastic sheen
seed used for sample: 41822
note: holds the palette well, tends to over-polish the wood
MODEL B — image
aspect ratio: 4:5
guidance: low
reference: /refs/pourover-palette.jpg, low weight
note: ignores "shallow depth of field" — append "background
softly blurred" or the whole frame stays sharp
Two things make that block worth money. The first is the seed, which turns your sample into something the buyer can actually land on rather than approximate. Reproducibility is not guaranteed across every model or every provider, so say which samples are seed-locked and which are not — the mechanics of that are covered in seeds and reproducibility. The second is the note. "Ignores shallow depth of field" is the kind of line only someone who ran the prompt forty times writes, and buyers read it as proof the pack was tested rather than assembled.
If you are unsure which models to support, run the same prompt across several in one pass rather than testing them serially — A/B testing models with a single prompt covers the setup, and Versely's agent chat can fan one prompt across several named models in a single request, which is the cheapest way to find out where a prompt survives and where it collapses. The model catalog is the shortlist to draw from.
Reference assets are half the product
Palette, texture, and character consistency almost never come out of words. They come out of images. A pack that promises a coherent look and ships only text is asking the buyer to reconstruct half the input from a JPEG on a sales page.
Include the actual files:
- Style references at the weight you used them
- A palette strip as a real image, not hex codes in a caption
- Any character or product reference the samples depend on
- A folder structure that matches the paths written in the parameter blocks
That last one sounds trivial and is the most common breakage. If the block says /refs/pourover-palette.jpg, the zip should contain refs/pourover-palette.jpg, spelled the same way. Stacking several references at once changes behaviour in ways worth documenting rather than leaving the buyer to discover.
One licensing note that belongs in the same folder as the assets: state what buyers may do with the reference images themselves, separately from what they may do with outputs. Those are different permissions and packs routinely conflate them.
Failure notes: the section nobody ships
Every prompt in a real pack has a failure mode. You already know what they are, because you hit them while building. Writing them down costs an afternoon and changes how the pack reads.
| Symptom | Cause | Fix |
|---|---|---|
| Hands or hardware duplicated | Prompt describes an action the model resolves by adding limbs | Move the action into the negative, describe the pose statically |
| Colours drift warm across a set | No reference, model defaults to golden-hour lighting | Attach the palette strip, lower guidance |
| Text on packaging is gibberish | Model not built for legible type | Generate the pack shot blank, add type in the editor |
| Every output looks like stock | Prompt is a list of nouns with no camera or light | Add one lens fact and one light direction |
Four rows is enough. The point is not exhaustiveness — it is that the buyer, on hitting a bad output, reaches for your document instead of the refund button.
The variation grid
A prompt is a starting point. A grid is a system, and systems get used more than once, which is what turns a buyer into a repeat buyer.
Lay it out as rows and columns and let the buyer read the combinatorics off the page:
| Morning window | Overcast diffuse | Hard side light | |
|---|---|---|---|
| Overhead flat-lay | base prompt | swap "morning window light" → "flat overcast light" | swap → "hard light from camera right, long shadow" |
| Three-quarter, table height | + "camera at table height, three-quarter angle" | same | same |
| Tight macro on the spout | + "macro, 100mm, spout fills frame" | same | same |
Nine images from one prompt, and the buyer can see immediately how to reach a tenth. Say plainly which cells you actually rendered and which are extrapolated — Versely's prompt library is organised the same way, by setting and format, because that is how people shop for a look.
Version number and update policy
Models update. Parameters that were correct in March produce different output in August. A pack with no version number becomes silently wrong and you find out from a one-star review.
Put four things on the sales page and inside the zip:
- A version and a date.
v1.3 — 2026-08-20. Nothing clever. - A changelog. Two lines per release: what broke, what you re-cut.
- A support scope. Name the models the version is validated against, and say that models outside that list are untested rather than unsupported. Those are different promises.
- A delivery method for updates. Free updates for the life of the pack is a strong offer and a real obligation. Paid major versions are also fine. Pick one and write it down.
The pack that survives is the one where a buyer who opens it in six months can tell whether it is current. Everything above exists to answer that question without an email.
FAQ
How many prompts should a pack have?
Fewer than you think, each fully specified. A pack of 30 prompts with parameter blocks for three models, reference assets, and failure notes is a bigger build and a better product than 300 loose lines. Count parameter blocks rather than prompts when you are sizing a pack against a price.
Do I have to include the generated images?
Include enough to prove the pack works and to give buyers a target. A sample image per prompt, at the aspect ratio the block specifies, does that. What matters more is that the sample was made with the settings you shipped — a sample produced with different parameters than the ones in the block is the fastest way to earn a refund.
What if a model updates and half the pack drifts?
That is what the version number and support scope are for. Re-run the affected blocks, adjust guidance or negatives, bump the version, and note it in the changelog. If a model is retired outright, say so in the changelog and either replace the block with another model or reduce the pack's claimed support list. Quietly leaving a dead block in place is what turns a drift into a dispute.
One pack per model, or one pack covering several?
One pack covering several, if you have genuinely tested each. Buyers rarely commit to a single generator and a multi-model pack removes their main objection. But do not list a model you have not run — an untested block is worse than an absent one, because it converts a sale into a refund plus a review. If you sell to other builders, the digital product sellers breakdown covers how packaging choices like this affect repeat purchase.