Questions to Ask ChatGPT
Prompts to use with ChatGPT, grouped from quick explanations through drafting, analysis and planning, with notes on what each one tends to return and where the answer needs checking.
The questions
Open any question for the note
Explain [concept] to me as if I have never heard of it, then again for someone who works in the field.
Why ask it
Asking for two levels in one go lets you spot the gap between them. If the expert version is just the beginner version with jargon added, the model does not have much depth on the topic and you should verify before relying on it.
What is the simplest possible version of [thing I am trying to build or do]?
Why ask it
Left to itself the model tends to answer with the elaborate version, because thorough looks like helpful. Naming simplicity as the goal usually cuts the answer to a third of its length and surfaces which steps were optional all along.
Give me twenty ideas for [project], including five you think are bad.
Why ask it
A high number forces it past the obvious first three, and asking for bad ideas stops it from padding the list with near-duplicates of the good ones. The rejects are often the useful part, because they show where the boundary of the idea space is.
What are the arguments for [option A] over [option B], and then the reverse?
Why ask it
Asked one at a time it will argue whichever side you named, so the second half is what matters. Compare the two lists: if one is thin, that is a hint about which case is genuinely harder to make, not just which one you asked for first.
Rewrite this so it is half as long and says the same thing: [paste text].
Why ask it
Cutting is the task it does most reliably, because it needs no facts it does not already have in front of it. Read what it dropped. Anything you miss was load-bearing, and that tells you what the piece is actually about.
Draft a [email, memo, message] doing [specific job], in the tone of the sample I am pasting below.
Why ask it
Without a sample the output arrives in a flat corporate register that colleagues recognise instantly. With three or four paragraphs of your own writing attached, sentence length and habits carry over, and you are editing rather than starting over.
Here is my draft. Tell me what is unclear, not what is good: [paste draft].
Why ask it
Unprompted feedback is heavily complimentary, which is worthless for revision. Barring praise pushes it toward the sentences a reader would stumble on. Confusion is something a language model can genuinely detect, unlike whether an argument is correct.
What questions should I be asking about [situation] that I have not thought to ask?
Why ask it
Useful before a meeting or a decision, because the model has seen many versions of the situation and will name the routine considerations you have skipped. Treat the list as a checklist of blind spots, not as advice.
Walk me through [process] one step at a time, and wait for me to say I have done each step.
Why ask it
Otherwise you get all twelve steps at once and no chance to report that step three failed. Pacing the answer means errors surface where they happen. Watch whether it actually waits, since it often forgets the instruction after a few turns.
I want to learn [skill]. What should I practise first, and how will I know I am getting better?
Why ask it
Curriculum ordering is a reasonable use, but the second half is the test. Vague progress markers mean it is reciting a syllabus. Specific ones, things you can check yourself this week, mean the plan is usable.
What do people usually get wrong when they try [task] for the first time?
Why ask it
Common beginner errors are well documented, so this is the kind of thing the model has actually read a great deal about. Expect a mix of real pitfalls and generic caution. The specific ones with mechanisms attached are the ones to trust.
Give me practice problems on [topic], one at a time, and tell me where I went wrong before showing the answer.
Why ask it
Generating exercises is easy for it. Marking them is less reliable, so check any arithmetic or code yourself. Asking for the diagnosis before the solution stops you reading the answer and assuming you would have got there.
Here is my data. What patterns do you see, and what would change your reading of it? [paste data]
Why ask it
It will find patterns whether or not any exist, so the second clause matters. If nothing could change its interpretation, the reading is decorative. Verify every number it quotes back at you, since figures get transcribed loosely.
Help me find the bug: here is the code, the input, and what I expected to happen instead.
Why ask it
All three parts are needed. Given only code it guesses at intent and fixes things that were never broken. Given expected versus actual behaviour it narrows quickly, and it is unusually good at spotting the off-by-one you have stared past.
Turn this goal into a plan with dates: [goal, plus what time and money I actually have].
Why ask it
Stating the constraints up front is what stops the plan being fantasy. Plans that ignore your real limits read well and collapse in week two. If it does not push back on a deadline you know is tight, ask directly whether the schedule is realistic.
Argue against the position I just took, as strongly as you can.
Why ask it
The model defaults to agreement, so you have to ask for opposition explicitly. What comes back shows you which of your reasons are load-bearing. If the counterargument is easy to knock down, ask for a harder one before you feel reassured.
Play the interviewer for a [role] and ask me one question at a time, then critique my answer.
Why ask it
Rehearsal out loud is the point, not the questions themselves. It holds a role for a surprising number of turns. Its critique tends to reward structure over substance, so use it to fix rambling, not to judge whether your example was strong.
What are the standard tools and terms in [field] that an outsider would not know?
Why ask it
Vocabulary is the fastest way into an unfamiliar field, and naming the terms lets you search properly afterwards. Tool recommendations may be out of date or invented outright, so confirm each one exists before you spend time on it.
What would have to be true for [plan or belief] to be a mistake?
Why ask it
This inverts the usual request for support and produces the failure conditions you can actually watch for. Answers that only list vague external risks mean it has not engaged; you want conditions you could check next month.
Where in this answer are you least confident, and what should I check myself?
Why ask it
Stated confidence is not a reliable measure of accuracy, but the flagged parts are usually worth a second look, and it will sometimes retract an invented detail when asked. Treat it as a starting point for verification, not a guarantee.
Getting more out of the conversation
Practical guidance for the conversation itself
Writing the prompt
Say who the answer is for
The same question answered for a beginner and for a specialist produces different text. Naming the reader, including yourself, removes a guess the model would otherwise make badly.
Paste the thing in
Descriptions of your draft, your data or your code produce generic answers. The actual text produces specific ones. This is the single biggest difference between a useful reply and a forgettable one.
Name the constraint
Length, budget, deadline, reading level, what you have already tried. Unstated constraints get ignored, and you end up rejecting an answer for a reason you never mentioned.
Ask for the failure mode
Add "and tell me where this could go wrong" to almost any request. The default reply is confident and complete, and the caveats have to be requested.
What to check before you use it
Citations, names and titles
- Sources may be plausible and nonexistent; search for each one before citing it
- Quotations attributed to real people are frequently paraphrased or invented
- Statistics arrive with no source attached even when they sound precise
- Legal, medical and tax specifics vary by jurisdiction and go out of date quietly
Arithmetic and code
- Recompute any figure you plan to act on, including ones it copied from your own data
- Run generated code rather than reading it and assuming it works
- Check that libraries, functions and command flags it references actually exist
Agreement is not confirmation
If you push back, it will usually concede, whether or not you were right. Reversal under pressure tells you nothing about the facts. Go and check instead.
When the first answer is not right
Say what was wrong with it
"Too long", "too general", "you assumed I have a team" all work better than "try again", which tends to produce a reworded version of the same answer.
Start a new conversation when it drifts
Long threads accumulate earlier assumptions and corrections. If it keeps returning to something you already ruled out, open a fresh chat and restate the problem cleanly.
Ask for the reasoning separately
Request the conclusion first, then ask how it got there. Reasoning produced after the fact is easier to inspect for the step where it went off.