The prompt is the easy part. What decides whether a stranger reuses it is everything around the prompt, and most published prompts have none of it.
1. A title that names the job
“Turn a bug report into a failing test” tells a reader in four words whether to keep scrolling. “Testing prompt v3” tells them about your filing system. Name the outcome, not the artefact.
2. The model you actually wrote it against
Prompts are not portable in the way people pretend. A prompt tuned against one model’s habit of over-explaining will read as oddly terse on another. Say which model you used. If you tested on more than one, say which ones, and if you tested on none beyond your daily driver, say that too. “Model agnostic” should mean you checked, not that you did not.
3. The refusal condition
This is the field almost nobody writes and it is the one that makes a prompt trustworthy. Every useful prompt has a case where the correct output is “I cannot do this, here is what is missing”. A prompt with no exit is a prompt that will confabulate rather than stop, and it will do it on the day you are not watching.
Write the stop condition into the prompt, then write it again in the entry, so the reader knows it is deliberate and does not helpfully delete it.
4. Where it breaks
Concurrency. Long inputs. Anything where the answer depends on state the model cannot see. Naming two or three real failures costs you nothing in credibility and buys the reader an afternoon. An entry with no limits section reads as untested, because it usually is.
And a licence
Pick one. MIT if you want it used, CC BY if you want credit, CC0 if you have stopped caring. An unlicensed prompt is legally awkward to reuse at work, which is precisely where reuse matters, and entries without one do not pass review here.
