Skip to content
Question Vault?
Free to readNo accountNo email wallNo invented statisticsNo partial listsCopy or print any set and take it with you

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.

33 questions

Want questions from the whole vault instead? Try the random question generator.

The questions

Each question, and why to ask it

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.

Ask me questions until you have enough to help with this properly.

Why ask it

Most weak output comes from missing context rather than a weak model. Watch whether it asks one question and then guesses anyway, which is your cue to supply the constraints yourself.

What would someone experienced in this notice that I would miss?

Why ask it

This reliably pulls up the practical knowledge that sits between the textbook and the job: the step everyone skips, the cost nobody mentions, the order things have to happen in. It is the highest-yield question for any unfamiliar task.

What is the standard way to do this, and why do people depart from it?

Why ask it

The second half surfaces the situations where the default advice fails, which is usually the part you actually need. It also tells you whether there is a real convention or just one popular opinion.

Where do experts actually disagree here, rather than what the consensus is?

Why ask it

Useful when you suspect a question is contested. Be wary if it manufactures two sides for something long settled, because that is a sign it is pattern-matching rather than reporting.

Give me three genuinely different approaches to this, with the tradeoff of each.

Why ask it

Without the tradeoff clause you get a ranked list where the first option is obviously the intended answer. If the three tradeoffs read almost identically, the options are variations rather than alternatives, so ask again.

Walk me through this calculation step by step and show the numbers.

Why ask it

Arithmetic mistakes hide comfortably inside confident prose. Broken into steps they become checkable, and any step you cannot verify is one to redo by hand before you rely on it.

Which of this might be out of date, and how would I check?

Why ask it

Anything involving prices, laws, software versions, or current officeholders is a likely failure point. A useful answer separates the stable parts from the volatile ones instead of hedging over the whole thing.

Summarize this document, then list what it does not say.

Why ask it

Summaries smooth over gaps, contradictions, and conspicuous silences, which are often the important content in a contract or a report. The absence list is the half you cannot get by reading faster yourself.

Rewrite this paragraph of mine without changing my voice.

Why ask it

The default editing style flattens everything toward the same measured register, so the instruction to preserve voice is doing real work. Compare the output against your original sentence by sentence rather than accepting it whole.

Now do it again, shorter, and cut anything you added to sound thorough.

Why ask it

Output drifts long, with restated questions, preambles, and summaries of what was just said. A second pass aimed at deletion usually removes a third of the text without losing anything, and shows you how much of the first answer was padding.

I have forty minutes and this deadline. What is the best use of the time?

Why ask it

Stated constraints turn advice into a plan. Without a time limit in the prompt you get a list of everything that could theoretically be done, which is no help at nine in the evening.

Turn this into a checklist I can follow tomorrow morning.

Why ask it

Forcing the output into steps exposes gaps that flowing paragraphs conceal. Any item you cannot picture yourself doing is a step that needs breaking down further.

Summarize what we have settled in this conversation so I can paste it somewhere.

Why ask it

The summary shows what it is still carrying. Anything you decided earlier that is missing from the summary has dropped out of what it is working from, and needs restating before you continue.

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.

More on this topic