A prompt is a brief, not a wish

A prompt is the brief you hand a model: the role it should take, the task, the context it needs, the format you want back, and the constraints it must respect. Most disappointing answers are not model failures. They are briefs with a missing half.

The workbench on chatpt.chat uses this structure; the guide is the reasoning behind it, so you can do the same thing in any assistant.

This guide is the method behind the workbench: write the rough request, then add the five parts until the task is unambiguous. You can do it by hand. The workbench just does the boring part faster.

Why most prompts fail

People write prompts the way they text a colleague who already knows the project. “Make this better.” “Write something for the launch.” “Fix the ending.”

A colleague fills the gaps from memory: they know the client, the deadline, the last version, the thing your boss hates. The model has none of that. It fills the gaps with the average of everything it has read, which is exactly why the result feels like a press release written by a committee.

The fix is not a magic phrase. It is the same fix as delegating to a new freelancer on day one: say who it is for, what good looks like, and what it must not do.

The five-part brief

1. Role — who is answering

A role is not decoration. It shifts what the model treats as relevant.

Weak: You are a helpful assistant.

Useful: You are a copy editor for a B2B newsletter. You cut jargon and keep the writer's voice.

The second one tells the model which rules to apply and which to ignore. Keep it short and real. A stack of five fictional roles (“world-class expert, Nobel laureate, SEO genius”) does less than one concrete job title with a stated standard.

2. Task — the one thing you want

One prompt, one job. If you ask for an outline, a draft, and a critique in the same breath, you usually get a draft that is also pretending to be an outline.

Weak: Help me with my presentation.

Useful: Turn these notes into a 6-slide outline for a 10-minute internal review. Each slide gets a headline and three bullets.

If you genuinely need several steps, chain them: outline first, then approve it, then ask for the draft. The thread remembers the approved outline. That is cheaper than one giant prompt and much easier to correct.

3. Context — the facts it cannot guess

Context is the part people skip. Put the raw material in the prompt: who the audience is, what happened last time, the constraints from legal, the tone of the last email, the document you are summarizing, the error message.

A useful test: if a competent freelancer could not start without this detail, it belongs in the prompt.

Bad context is a mood. Good context is a fact:

• Bad: Make it engaging.
• Good: The reader is a operations manager who has already ignored two vendor emails.

4. Format — what the answer should look like

If you do not specify a shape, you get the shape the model uses most often: an intro, a list of five generic points, and a summary. Sometimes that is fine. Usually it is not.

Say the container: a table with three columns, a 120-word email, five bullets, a JSON object, a two-paragraph memo, a checklist with checkboxes.

Say the length in the unit you care about: words, bullets, slides, minutes.

If you need to paste the result somewhere, say where. “A Slack message, no headings” is a different task from “a section for a Google Doc.”

5. Constraints — the edges

Constraints are where quality lives. They are also where most prompts stop.

• What must it avoid? (No exclamation marks. No promises about timelines.)
• What must it keep? (Keep every number from the source. Do not add new ones.)
• What must it admit? (If the source does not answer something, write "not in the source" instead of guessing.)
• What is the register? (Plain English. No "leverage", "seamless", "unlock".)

A constraint can be a quality gate. Before you answer, list the three assumptions you made turns a confident guess into something you can check.

One request, three passes

Here is the same task at three levels of brief.

Pass 1 — the wish.

Write an email to my landlord about the heating.

You will get a polite, generic email that could be about anything. It will probably mention “prompt attention”, which is a tell.

Pass 2 — role, task, context.

You are a tenant writing to a landlord. Write a short email asking them to fix the
radiator in the front room. It has been cold for nine days. I reported it once by text
and got no reply. Keep it friendly but firm.

Better. It is specific, it has a timeline, and it has a tone. It is still missing the outcome.

Pass 3 — format and constraints.

You are a tenant writing to a landlord. Write a short email asking them to fix the
radiator in the front room.

Context: it has been cold for nine days. I reported it once by text on 14 October and
got no reply. The flat is rented through an agency, but the landlord handles repairs.

Format: under 130 words. Subject line included. One paragraph of context, one of the
request, one line offering to be available for a repair visit.

Constraints: friendly but firm. No legal threats. No exclamation marks. Do not invent a
date for the repair. Ask for a reply by Friday.

That third version is a brief. The model now has a job, a situation, a shape, and edges. You can send the result after one read.

Before and after

Notice the pattern: each “after” adds a reader, a shape, and a limit. None of them uses a secret phrase.

The iteration loop

The first answer is a draft of the brief, not a verdict on the model.

1. Name the defect. Too generic? Too long? Wrong tone? Made-up facts? Pick one.
2. Patch one thing. Add the missing part of the brief, or add a constraint that forbids the defect. Do not rewrite everything.
3. Re-run in the same thread. The thread already holds the earlier attempt; “same task, but” is a shorter prompt than starting over.
4. Keep what worked. If an answer is 80% right, ask for a targeted edit instead of a fresh generation. Regenerating from scratch loses the good parts.

Useful patches:

• Too generic. Rewrite it using only the details in my message. If a detail is missing, ask me for it.
• That is the right content but the wrong register. Rewrite it for a skeptical engineer who has seen this pitch before.
• Cut it by 40% without losing any of the numbers.
• You stated a figure I did not give you. Mark every claim that came from outside my message with [unverified].

That last one is the most valuable habit in this guide. Ask the model to separate what it was told from what it supplied. Then check the second pile.

Four templates worth keeping

Explain it to me properly

Explain [concept] to [audience] in [length].

Start with one sentence that would still be true in a textbook.
Then give one concrete example and one common misconception.
Do not use analogies from [domain I do not know].
If the concept has a disputed definition, say so.

Edit my writing without flattening it

Edit the text below. Keep my voice and my opinions.

Rules:
- Do not add facts, examples, or transitions I did not write.
- Cut filler and repeated ideas.
- Fix grammar and rhythm.
- Mark anything you were tempted to add but did not.

Return: the edited text, then a list of the three biggest changes and why.

Turn a document into a decision

Read the document below. I need to decide [decision].

Return a table with: claim, evidence in the document (quote it), what is missing, and how
much it matters for the decision.
Then give me the decision you would make and the one fact that would change your mind.

Rehearse a hard conversation

Role-play a conversation I need to have with [person and relationship].

You play them. Stay in character. Be realistic, not hostile.
Start with their first line.
After 10 exchanges, stop and give me: what I did well, what I avoided, and the sentence I
should have said.

When it still does not work

If a well-briefed prompt fails twice, the task is usually wrong for a single prompt. Split it. Give the model the source material instead of asking it to remember. Or accept that the task needs a human decision and use the model to prepare the options, not to choose.

Three failure modes worth naming:

• Confident invention. The answer is fluent and wrong. You cannot prompt this away entirely. You can force labeling, ask for quotes, and check the source yourself.
• Averaged voice. The text is grammatical and says nothing. It usually means the brief had no specific audience, no opinion to preserve, and no examples.
• Instruction drift. In a long thread, the model slowly stops following a rule from the top. Restate the rule in the message where it matters.

None of these are fixed by adding “be accurate” to the prompt. They are fixed by better inputs and a review step.

The short version

• One task per prompt.
• Name the reader, not just the topic.
• Put the facts in the prompt; do not make the model guess them.
• Ask for the shape you can actually use.
• Add one constraint that forbids the failure you keep seeing.
• Iterate on the brief, not on your luck.

The workbench turns a one-line request into this structure in a few seconds, and you can edit every field before you copy it. If you would rather start from a finished prompt, the prompt library has 40+ of them, sorted by job.

Keep reading

• ChatGPT, minus the mystery — what the tool is and how to start.
• Use it like an editor, not a vending machine — the writing workflow that survives a real deadline.
• Why it forgets, and what to do about it — context, memory, and when to start a fresh thread.