I Scored 79 Prompts From a Popular Prompt Library. The Average Was 3.2 Out of 10.

Most advice on how to write AI prompts is somebody’s opinion. I wanted evidence, so I went and measured a real library instead of guessing.

Prompt libraries are everywhere now, and most of them are lists: a title, a blob of text, a copy button. Whether the prompts inside them are actually any good is a different question.

I scraped a public prompt library, pulled all 79 prompts with their full text and copy counts, and scored every one against ten techniques that show up in every serious prompt-engineering guide.

The average came out at 3.2 out of 10. The best prompt in the library scored 6. Nothing scored higher.

More interesting than the average was what the gaps had in common. Once you see the pattern you cannot unsee it, and it applies to almost every prompt I have seen shared online. Mine included, before I started checking.

How I measured it

Ten checks, each one a thing a reusable prompt should usually specify: placeholders, role, output format, step structure, examples, constraints, audience, a clarifying-question gate, tone, and success criteria.

Then a script counted how many each prompt had. The checks are regex heuristics, so they catch phrasing rather than meaning. A prompt can specify a format in words my pattern misses. That makes the numbers a floor, not a verdict. Good enough to find the pattern.

Here is the coverage across all 79:

Read the bottom four again. 85% of these prompts never say what shape the output should take. 84% give no example. 85% give the model no way to check its own work.

That is not a library problem. That is how most people write prompts.

The finding that surprised me

I expected the most-copied prompts to be the best ones. Copy count is a crude quality signal, but it is a signal. People come back to what works.

It is not.

• Prompts with 50 or more copies: average 2.2 out of 10
• Prompts with under 50 copies: average 2.7 out of 10

The most-copied prompt in the entire library, at 127 copies, scored zero. It has none of the ten techniques.

Popularity tracks how useful the idea sounds, not how well the prompt is built. People copy a prompt because the title promises something they want, not because the prompt reliably delivers it. Which means you cannot shop for prompts by popularity, and the copy counts on any library you browse are telling you about demand, not quality.

Failure mode 1: saved requests pretending to be templates

That 0 out of 10, 127-copy prompt starts like this:

“Create a Meeting Cost Calculator as a single HTML file with inline CSS and JavaScript.”

It is a good idea for a tool. It is not a template. It is one request, hardcoded to one deliverable, that somebody saved and shared. Want a tip calculator instead? You are rewriting the whole thing.

Nearly a third of the library had this shape. The tell is easy to spot: if you cannot change what it builds without editing the sentence, it is a saved request.

The fix is mechanical. Find the nouns that are specific to your one use case and turn them into slots:

Build {{TOOL_NAME}} as a single HTML file.
What it does: {{WHAT_IT_DOES}}
Inputs: {{INPUT_FIELDS}}
Outputs: {{OUTPUT_VALUES}}

The same prompt now builds a mortgage calculator, a unit converter, or a countdown timer.

Failure mode 2: adjectives doing a constraint’s job

The second pattern is more common and harder to see, because the prompts look thorough. Here is a story-writing prompt from the library, condensed:

Create a captivating story… keep dialogue engaging… an engaging title… captivating dialogue or descriptions… the story should seamlessly blend entertainment and thematic relevance

Five adjectives, all pointing at the same wish. Not one of them changes a single word of the output.

Now compare with the one genuinely useful line in that same prompt: “Use simple language with occasional new vocabulary”. That one is checkable. You can look at the output and say whether it happened. The adjectives you cannot.

This is the single most useful idea in this whole post, so here it is on its own:

Adjectives describe the output you want. Constraints produce it.

“Captivating dialogue” changes nothing. “Cut greetings and small talk that do not reveal character or move the plot” changes every line of dialogue in the story. Same intent, wildly different result.

The test: if you cannot check whether a line happened, it is not doing anything. “Modern, professional design” is unfalsifiable. “Readable at 360px wide, with visible focus states” either is or is not true.

The thing almost nobody does

Of the ten techniques, the rarest was the clarifying-question gate, at 10%. And it is close to free:

If any input, unit, or formula above is ambiguous, ask me up to three
clarifying questions and stop. Do not guess.

Three lines. It converts the model’s most expensive habit, confidently filling a gap in your spec with an invention, into a question you can answer in ten seconds.

Related, and rarer still in practice: telling the model what it cannot know.

Two prompts in this library ask for things no model can reliably know. One asks for current affiliate commission rates. The other implicitly asks for domain names that are still available. Neither prompt acknowledges the limit, so both get confident, plausible, out-of-date answers, and the person using them finds out the expensive way.

The fix is one paragraph:

You cannot check current rates. They change often and you may be out of
date. Give figures as recollection, label each high or low confidence, and
give me a URL to verify. Never state a rate as current fact.

If your prompt asks for anything time-sensitive, priced, legal, or inventory-dependent, it needs a version of that paragraph.

The ten point checklist

Run any prompt you rely on through these ten. You will not want all ten every time. A code-generation prompt does not need a target reader. But you should be deciding to skip them rather than never considering them.

1. Placeholders. Could someone else use this without editing prose?
2. Role, with stated priorities, not just a job title. “A developer who cares about accessibility and edge cases” beats “an expert developer”.
3. Output format. The single biggest gap. Say the shape.
4. Steps, for anything multi-part.
5. Examples. One worked example beats a paragraph of description.
6. Constraints. Name the failure you keep getting, not the success you want.
7. Audience. Changes depth, jargon and length.
8. Clarify gate. Ask, do not guess.
9. Tone, or you get generic corporate voice.
10. Success criteria. A checklist the model runs against its own draft before answering.

Number 10 costs four lines and catches the misses you would otherwise find yourself. Nine out of the ten prompts I rewrote ended with one.

One rewrite, start to finish

Back to the 127-copy calculator prompt. What it is missing: it builds exactly one thing, “modern, professional” means nothing, there is no output format so you get chatty commentary wrapped around your code, nothing about empty inputs or zero or negative numbers, and no definition of done.

The rewrite keeps the idea and replaces every wish with a test:

You are a front-end engineer who ships small, self-contained browser tools.
You care about accessibility and edge cases, and you write vanilla
JavaScript with no frameworks or build steps.

## Task
Build {{TOOL_NAME}} as a single HTML file.
What it does: {{WHAT_IT_DOES}}
Inputs: {{INPUT_FIELDS}}
Calculated outputs: {{OUTPUT_VALUES}}

## Before you build
If any input, unit, or formula is ambiguous, ask up to three clarifying
questions and stop. Do not guess at a formula.

## Hard constraints
- One .html file, inline style and script. No external requests of any kind.
- Vanilla JS only. No frameworks, no build step.
- Recalculates live on input. No submit button.
- Must work offline opened via file://

## Handle these explicitly
- Empty fields on load: neutral zero state, never NaN.
- Zero, negative, non-numeric: inline message next to the field.
- Very large numbers: thousands separators, no layout overflow.

## Design
- Style: {{STYLE}}
- Readable at 360px and at 1440px.
- <label for> on every input, visible focus states, and results in an
  aria-live="polite" region.
- Colour is never the only signal.

## Output format
Return the complete file in one html code block. Nothing before or after.

## Before you finish, verify
- [ ] Opens directly in a browser with no server.
- [ ] Every output updates when any input changes.
- [ ] Every invalid-input case shows a message instead of NaN.
- [ ] Tab order reaches every control, focus always visible.
- [ ] Zero network requests.

Scored on the same ten checks: 0 out of 10 becomes 7 out of 10, better than anything in the original library.

Note what actually changed. It is not longer for the sake of it. Three of the ten prompts I rewrote came out shorter than the originals. Every added line either names a decision or states a test. The NaN line alone fixes the most common bug in generated calculators, and it costs eight words.

What to do with this

Pick the prompt you use most. Not your cleverest one, your most-used one. Run it against the ten. You will typically find output format, success criteria and the clarify gate all missing, and adding those three takes about five minutes.

Then check it for adjectives. Every time you find one describing the output, ask what test would replace it. “Professional” becomes what would you check? “Engaging” becomes what would you cut?

That is the whole method. It is not sophisticated, but almost nobody does it, which is exactly why the average across 79 shared prompts was 3.2 out of 10.

Prompts built this way

I applied all ten points to a library of my own. Every prompt in it names its output format, its constraints, and how to check the result, and the ones that ask for anything a model cannot reliably know say so up front.

Browse the CyberTrickz prompt library. Free, no sign-up, copy button on every one.

Method note: 79 prompts scraped from a public prompt library and scored with a script against ten prompt-engineering techniques. The library’s ideas are genuinely good. Several of these prompts are clever concepts thinly specified, which is the point. The problem is technique, not imagination.