To write better AI prompts, stop making the model guess. State the task, give the context it cannot know, such as your audience and goal, set constraints like length and tone, show an example when style matters, and say exactly what format you want back. A prompt like "write a blog post about website speed" leaves all of that out, so the model fills each gap with the most average answer.
I write prompts every day for the AI features on this site, including the chat on the home page and the free AI tools. The free Prompt Improver applies the same structure to any prompt you paste in. Here is the structure, and what I have learned using it in production.
Why do AI prompts give generic answers?
Because a model answers the prompt it was given, not the one you meant. "Write a blog post about SEO" does not say who the post is for, what it should achieve, how long it is, what tone to use or how to format it. The model has to guess all five, and its guess is the middle of everything it has seen.
Every detail you add removes a guess. That is most of what prompt engineering is.
The fix is not longer prompts for their own sake. A long prompt full of vague adjectives, such as "engaging", "high quality" or "professional", still leaves the model guessing, because those words mean something different to everyone. Specific beats long: "for owners of independent restaurants who have never hired a developer" does more work than three paragraphs of adjectives. When you catch yourself writing an adjective, ask what it would look like in the output, and write that instead.
What makes a strong prompt?
Six parts. Not every prompt needs all of them, but every missing one is a guess.
| Part | What it does | Example |
|---|---|---|
| Role or perspective | Sets the expertise and the standard | "Review this like a senior conversion copywriter" |
| Task | The one thing to do | "Rewrite the headline and subheadline" |
| Context | What the model cannot know | "For HR managers at companies with 50 to 500 people. Goal: book a demo" |
| Constraints | Limits on length, tone and content | "Under 12 words. Plain English. No claims I have not given you" |
| Example | Shows the style when words are not enough | A headline you like, or a past post |
| Output format | The exact shape of the reply | "Three options, one per line, then one sentence on which to test first" |
Here is the difference in practice, using the Prompt Improver's own example:
Before:
write a blog post about website speed
After:
You are writing for small business owners who are not technical.
Write a 900-word blog post on why website speed matters for them.
Goal: get readers to book a website speed audit.
Tone: plain, friendly, no jargon. Explain any technical term in one line.
Structure: a two-sentence answer up top, four question-shaped
subheadings, a short checklist, and one call to action at the end.
Do not invent statistics. Where a number would help, write [stat].
How do I structure prompts for the AI tools on this site?
Every tool here runs on one server-side prompt split into two parts: a one-line job and an output spec that describes the exact shape of the reply. The Landing Page Roaster's job, for example, is to review copy like a senior conversion copywriter and rewrite the weakest parts. Its output spec lists every section in order: a one-sentence verdict, four scores out of 10, the problems quoting the exact weak phrases, three headline rewrites from different angles, a table of section fixes, and one tip.
Three lessons from running those prompts:
- Specify the output exactly. Saying "a table with columns Feature, Priority, Effort, Why" gets a table every time. Saying "list the features" gets a different shape each run.
- Write rules for what the model must not do. Every tool prompt forbids inventing claims, numbers, testimonials or client names, and asks for a [placeholder] where proof is needed.
- Give real data instead of hoping. The chat on the home page is given real project counts in its system prompt, labelled as the only project numbers it may chart, so it never needs to invent one.
How are system prompts different from chat prompts?
A chat prompt is used once. A system prompt runs on every request, for every user, including the strange ones. So it needs more than a task: rules for edge cases, what to do when information is missing, what is off limits and the exact format of every reply.
Turn every mistake into a rule
When the model gets something wrong, do not just retry. Add a specific instruction that prevents that mistake, then test again. A good system prompt is mostly a record of mistakes that no longer happen.
On this site the system prompts live only on the server. They are never sent to the browser, and the chat's system prompt is built from my server-side profile, never from what the visitor types.
How do you use the Prompt Improver?
- 1
Paste your prompt
The prompt you would normally type, rough as it is.
- 2
Pick where you will use it
Chat assistant, coding assistant, image generator or API and system prompt. Each needs a different structure.
- 3
Add the goal
What the result should achieve. This is the context most prompts are missing.
- 4
Copy and test
You get a diagnosis of what was missing, the improved prompt, what changed and why, and two variations to try side by side.
It keeps your intent and adds the missing structure. It is free with no sign-up, with ten runs per tool per day.
How do you know if a prompt is better?
Run the old and new versions on the same input, two or three times each, and compare against what you actually needed. Keep what works. Where the new version still goes wrong, add a rule and test again. For anything you will reuse, keep the prompt in a document with a note of what each rule is for.
Prompts are one part of an AI feature; the rest is the product around them. If you are looking for where AI would help your business in the first place, read AI use cases for small businesses. For a working example of prompts, streaming and guardrails in one place, see how I built the AI chat on this portfolio.
