How to Write Better AI Prompts — A Practical Framework

Most disappointing AI output isn't a model problem. It's a briefing problem. The model answered exactly the question it was asked — the question just wasn't the one you meant.

This is the framework we use when writing every prompt in the Prompt Jugaad library. It works on ChatGPT, Gemini, Claude, Copilot and Grok, and it takes about thirty seconds to apply.

The five parts of a working prompt

Every reliable prompt answers five questions for the model. Skip one and the model fills the gap with an average of everything it has ever read — which is the definition of generic.

1. Role — who is answering

Assigning a role narrows the model's vocabulary, priorities and standards before it writes a word.

You are a senior backend engineer reviewing a pull request from a junior developer.

That single line changes what gets flagged, how blunt the feedback is, and which trade-offs get mentioned.

2. Context — what it needs to know

Context is everything the model cannot infer: the audience, the stakes, the history, the constraints you're working under.

The reader is a non-technical client who has already been told this project was on schedule.

3. Task — what you actually want

State the deliverable, not the topic. "Write about onboarding" is a topic. "Write a 200-word onboarding email that gets the user to complete their profile" is a task.

4. Format — what it should look like

Models are excellent at following structure and terrible at guessing it.

Return your answer as:
1. One-line summary
2. Three bullet points of evidence
3. A recommended next step (one sentence)

5. Constraints — what to avoid

Constraints are where most of the quality gain hides. Length limits, banned phrases, tone rules, "no preamble", "don't hedge".

Under 150 words. No bullet points. Don't use the words "leverage", "robust" or "seamless".

Putting it together

Here's the same request written badly and then well.

Weak prompt:

Write a follow-up email to a client.

Strong prompt:

You are an account manager at a small design studio.

Context: We missed a delivery deadline by four days because of a
dependency on the client's own feedback, which arrived late. The
relationship is good and we want to keep it that way.

Task: Write a follow-up email that acknowledges the slip, states the
new delivery date (next Tuesday), and gently notes what we need from
them to hold that date.

Format: Subject line, then body. Under 150 words.

Constraints: Warm but not apologetic. No corporate filler. Don't blame
the client explicitly.

The second prompt takes forty seconds longer to write and saves three rounds of editing.

Four mistakes that quietly ruin results

• Asking two things at once. "Summarise this and suggest improvements" produces a weak summary and weaker suggestions. Split it into two turns.
• Leaving format to chance. If you didn't ask for a table, you'll get prose and then spend five minutes reformatting.
• Being polite instead of specific. "Could you maybe make it a bit more engaging?" gives the model nothing to act on. "Cut the first paragraph and open on the statistic" does.
• Accepting the first answer. The first output is a draft. Follow up with "Now cut it by 40% and make the opening line concrete" — iteration is part of the technique, not a sign the prompt failed.

Iterate in one direction at a time

When output is close but not right, change exactly one thing per turn: tone, or length, or structure — never all three. Otherwise you can't tell which instruction did the work, and you'll carry useless instructions into every future prompt.

Try it now

Three prompts from our library that show this framework in practice:

• Email Rewriter — role, tone constraints, and a strict output format
• Brutally Honest Feedback — constraints doing the heavy lifting
• Explain Like I'm Five — audience as the entire brief

Copy one, run it, then rewrite it for your own situation. The framework sticks faster from editing a working prompt than from reading about one.