How to Write a Prompt for a Task You Don't Understand Yet

TL;DR: Do not try to be specific. Run a sequence instead: map the territory, ask what a good answer looks like, make the model interview you, collect the vocabulary, ask where practitioners disagree, then write the real prompt. Verify as you go, because this is exactly when you cannot spot a wrong answer.

What do you do when you cannot specify what you want?

Every guide to prompt engineering starts from the same assumption: you know what you want and your job is to describe it well. Be specific. State the format. Give an example.

That advice collapses the moment you are handed something genuinely unfamiliar. A compliance questionnaire in a regulation you have never read. A dataset from a team whose acronyms you do not recognise. A brief that says "put together the migration plan" when you could not name the parts of a migration plan. You cannot be specific about a deliverable you would not recognise as correct.

The fix is not a better single prompt. It is accepting that your first several prompts are not for producing the work. They are for reducing the size of your unknown until a specific prompt becomes possible.

Run them in order. Each one gives you the raw material for the next.

Why is this the moment you are least able to catch a mistake?

Because the only thing standing between you and a confident wrong answer is your own knowledge of the subject, and you have just admitted you have none. This is the honest core of the whole technique, and it belongs at the top rather than buried in a closing caveat.

When you prompt about something you know well, you catch errors without noticing you are doing it. A wrong figure looks wrong. A missing step feels missing. Strip that away and every sentence arrives with the same even confidence, whether it is textbook-correct or quietly invented. That is what makes hallucination dangerous here specifically. It is not that models are wrong more often on unfamiliar topics. It is that you have lost your only detector. If you have never seen the failure mode up close, why ChatGPT makes things up is worth reading before you rely on any of this.

So verification is not step eight. It runs alongside every other step, and these four prompts belong in every exploratory session from the first minute.

For every substantive claim in your answer, name a specific source I could open
myself: a document title, a standard number, an author, or an organisation. If a
claim has no such source, mark it [no source] rather than inventing one.

Now rate your own answer. Which parts are you most confident about, and which are
you least confident about? For the least confident parts, tell me exactly what
would need to be checked and where I would check it.

Argue against the answer you just gave me. What would a sceptical practitioner in
this field say is oversimplified, outdated, or wrong about it? Be specific about
which sentence they would object to.

Which parts of that answer are settled and uncontroversial, and which parts are
your interpretation or a summary of one common view? Separate them into two lists.

Anthropic's own documentation on reducing hallucinations makes the first move explicit as a basic strategy: "Explicitly give Claude permission to admit uncertainty." The same page recommends making the response auditable by having the model cite quotes and sources for each of its claims (platform.claude.com, Reduce hallucinations, accessed 29 August 2026). The technique is not exotic. It is just the one people skip when they are in a hurry.

Step 1: how do you map the territory before solving anything?

Ask what this kind of task usually involves before you ask about your specific instance. You are trying to see the standard shape: the phases, the artefacts people produce, who is normally involved, and where it typically goes wrong.

I have been asked to [TASK] in [FIELD/CONTEXT]. I have no background in this.
Before we solve anything, describe what this kind of task normally involves:
the usual phases, the documents or artefacts that get produced at each phase,
and who is typically involved. Assume I know nothing.

What are the standard deliverables for [TASK]? For each one, tell me in a sentence
what it contains, roughly how long it usually is, and who reads it.

What does the timeline for [TASK] usually look like, and which parts take longer
than people expect? Flag anything that depends on someone outside my control.

What are the three most common ways [TASK] goes wrong for someone doing it for
the first time? For each, describe the mistake and what it looks like early,
before it becomes obvious.

That last one is the highest-yield question on the page after step 3. Failure modes are how experienced people actually hold a domain in their heads, and they compress a lot of tacit knowledge into a short answer. The same move works for code, which is why reading an unfamiliar codebase with AI starts with structure rather than with the bug you were sent to fix.

Step 2: what would a good answer even look like?

You need something to judge against, and right now you have nothing. So ask for the standard of quality before you ask for the work.

Describe what a genuinely good [DELIVERABLE] looks like versus a mediocre one.
Give me five specific, observable differences. Not adjectives, things I could
actually check by looking at a document.

Write me a short checklist a reviewer would use to assess a [DELIVERABLE].
Order it by what they would notice first.

Show me a condensed example of a [DELIVERABLE] for a situation like mine, then
annotate it: for each section, say what job that section is doing and what would
be missing if it were absent.

The annotated example is worth more than the example. A sample document tells you what to copy. An annotated one tells you what each part is for, which is what you need when your situation does not match the sample exactly, and it never does.

Step 3: how do you make the model interview you instead of guessing?

This is the single highest-leverage move on this page. Instead of writing a specification you are not qualified to write, hand that job back and make the model tell you what it needs to know.

I need help with [TASK] but I do not know enough to brief you properly.
Before you attempt anything, ask me the five questions you would most need
answered to be genuinely useful. Ask all five at once, numbered. Do not start
the task until I reply.

Read what comes back twice. The answers matter, but the questions matter more. They are a compressed statement of what the field thinks is important, produced before you had to know any of it. If the model asks about your jurisdiction, jurisdiction is load-bearing. If it asks who signs off, approval is a real stage you had not accounted for.

When you cannot answer a question, say so out loud rather than guessing:

Here are my answers. For questions 2 and 4 I genuinely do not know. Tell me how
someone in my position would normally find out, who I would ask, and what happens
if I proceed without knowing.

Based on my answers, what have I told you that is unusual or likely to cause
trouble, and what have I not mentioned that you would have expected me to?

Now ask me five more questions, but only ones that my previous answers have made
newly relevant. Skip anything you can already infer.

Step 4: how do you get the vocabulary so you can read on your own?

Vocabulary is leverage. The moment you know what a thing is called, you can search for it, read what practitioners wrote about it, and understand the answer when someone explains it to you. Until then you are dependent on one source, which is a bad position to be in on a subject you cannot check.

List the 15 terms someone working on [TASK] would use constantly. For each: a
one-line definition, and the mistake beginners make about it. Order them by how
often they come up.

What do practitioners in this field call the thing I described as "[MY CLUMSY
PHRASE]"? Give me the standard term and any near-synonyms, and tell me if the
distinctions between them matter.

Which terms in this field sound like they mean the same thing but do not?
Give me the pairs and the actual difference.

Then, before any of it leaves your mouth in front of someone who knows:

For each term you gave me, name where the definition comes from: a standard, a
textbook, a regulator, a widely used tool's documentation, or common usage with
no formal definition. Mark anything you are not certain about.

Step 5: where do practitioners in this field disagree?

Every real field has arguments in it. Those arguments are where the judgement lives, and a summary that flattens them into consensus has removed the only interesting part.

Where do experienced practitioners genuinely disagree about [TASK]? For each
disagreement: what the two positions are, what each side is optimising for, and
what would make me pick one over the other in my situation.

What is the conventional advice on [TASK] that experienced people often ignore,
and why do they ignore it?

What has changed about how [TASK] is done in the last few years, and what advice
that is still widely repeated is now out of date?

Asking for disagreement also does something useful to the answer itself. A model asked to summarise tends to converge on the safest, blandest version of a topic. Asked to argue both sides, it has to produce specifics, and specifics are checkable. The general form of that trick is covered in how to get ChatGPT to disagree with you.

Step 6: now write the specific prompt

Six steps in, you finally have what the standard advice assumed you had at the start: the shape of the task, a quality bar, the questions that matter, the vocabulary, and a sense of where the real decisions are. Now be specific.

Here is everything I now know about my situation: [PASTE YOUR ANSWERS FROM
STEP 3]. Using the vocabulary and structure we established, draft a
[DELIVERABLE]. Follow the reviewer checklist from earlier. Where you had to
assume something I did not tell you, mark it clearly as an assumption.

Before drafting, restate my task back to me in your own words, including the
constraints and the success criteria. If your restatement is wrong, I will
correct it and we will not have wasted a draft.

Draft two versions with different underlying approaches. For each, state the
approach in one sentence and say what it trades away. Do not tell me which is
better until I have read both.

The marked assumptions are the part to read first. They are a list of the things you still do not know, written by the only participant who noticed. If you are starting from a topic that is still too vague to phrase at all, our research question generator does the narrowing step on its own.

Step 7: how do you find out what you have misunderstood?

You have absorbed a lot of information quickly, from one source, with no ability to check it. Some of it landed wrong. Find out which parts before someone else does.

Quiz me on what we have covered. Ten questions, hardest last, one at a time.
Wait for my answer before giving the next one, and tell me when I am wrong
rather than being encouraging about it.

Here is my understanding of [TOPIC] in my own words: [YOUR SUMMARY].
Correct it. Point out anything that is wrong, oversimplified, or uses a term
incorrectly. Do not be diplomatic about it.

Given what I have told you about my situation, what am I most likely to have
misunderstood? What does a newcomer to this field usually get subtly wrong in
the first week?

What are the three questions I should be asking that I have not asked yet, and
who should I be asking them of?

That final prompt is the exit. Its output is not an answer, it is an agenda for a conversation with someone who actually knows the field, and that conversation is where this always had to end.

What this actually gets you

A map, not expertise. You will be able to follow the conversation, ask questions that do not waste the expert's time, read the documentation without bouncing off the vocabulary, and recognise roughly where you are. That is a large gain over where you started, and it is genuinely not the same thing as knowing what you are doing.

For anything consequential, the output is a set of questions to take to a real practitioner, not an answer to act on. Legal, medical, financial, safety, or any decision someone else will act on: this sequence prepares you for that conversation and does not replace it. Anthropic's guidance on reducing hallucinations closes on exactly this point, noting that these techniques significantly reduce hallucinations but do not eliminate them, and that you should "Always validate critical information, especially for high-stakes decisions" (platform.claude.com, Reduce hallucinations, accessed 29 August 2026).

One honest limit while we are here, since we sell a prompt tool. A prompt enhancer improves the wording of a prompt: structure, specificity, format, the parts that make a model respond better. It cannot supply domain knowledge you do not have, and it will cheerfully polish a question that is pointed at the wrong thing. That is what the sequence above is for. Work out what to ask first, then make the asking good.

The prompts in this post are worth keeping, because you will meet an unfamiliar task again and you will not remember the wording. Prompt Architects saves them with variables for the bracketed parts, so [TASK] and [FIELD/CONTEXT] get filled in rather than retyped, and they follow you across ChatGPT, Claude and Gemini. The free plan covers 5 prompt enhancements per day, forever, according to our FAQ page, with no card required, and Pro is $4.99 a month at the time of writing. Note that our pricing page currently displays only the paid plans, so the daily free figure comes from the FAQ.