Free prompt library · 20 prompts
Prompts that teach you how to prompt.
Every prompt here says what technique it uses and why it works, so copying a few leaves you better at asking — not just holding a longer list. Fill in the brackets and paste into any assistant.
Showing all 20 prompts
- LearningAnyone learning something new
Explain this at exactly my level
Why it worksStating what you already know gives the model an anchor to build from, which is what stops an explanation landing either patronising or over your head. Asking for the check-question at the end turns a passive read into a test.
I want to understand [TOPIC]. Here is what I already know about it: [WHAT YOU ALREADY KNOW — one or two sentences, even if it is "almost nothing"]. Explain it starting from that point, not from scratch and not from expert level. Use plain language, define any term the moment you introduce it, and give me one concrete example I could picture. Then ask me one question that would reveal whether I actually understood it.
- LearningLearners who feel stuck
Find the gap in my understanding
Why it worksAsking the model to diagnose rather than explain flips the roles. Explaining something back in your own words exposes exactly where your model of it breaks — a technique borrowed from the Feynman method.
I am going to explain [TOPIC] the way I currently understand it. I am probably wrong somewhere. My explanation: [EXPLAIN IT IN YOUR OWN WORDS] Do not just correct me. Instead: 1. Tell me which parts I have right. 2. Point to the single most important thing I have misunderstood. 3. Explain why that misunderstanding is easy to fall into. 4. Give me the corrected version in two sentences.
- LearningSelf-taught learners
Build me a realistic study plan
Why it worksMost study plans fail because they ignore the hours actually available. Giving the model your real constraint produces a plan you might finish, and asking what to cut first makes it survive a bad week.
I want to learn [SKILL] well enough to [SPECIFIC GOAL — e.g. "build a working prototype", "pass an interview"]. My constraints: - I have [NUMBER] hours per week, realistically. - My deadline is [DATE OR "none"]. - My current level: [BEGINNER / SOME EXPERIENCE / RUSTY] Give me a week-by-week plan that fits those hours. For each week, say what I should be able to do by the end of it, not just what to read. Then tell me which parts to cut first if I fall behind.
- LearningStudents working through a problem
Tutor me without giving the answer
Why it worksAn assistant that answers instantly is the fastest way to learn nothing. Instructing it to withhold the answer and ask one question at a time converts it from an answer machine into a tutor.
Be my tutor for this problem. Do not give me the answer, even if I ask for it directly — if I ask, ask me a question instead. The problem: [PASTE THE PROBLEM] Rules: - Ask me one question at a time and wait for my reply. - If I am wrong, do not correct me outright; ask a question that helps me notice it myself. - If I am stuck twice on the same step, give me the smallest possible hint. - When I get there, tell me what I should take away for next time.
- TeachingTeachers and trainers
Turn a topic into a lesson plan
Why it worksNaming the misconception you expect is the highest-value thing you can tell a model about teaching. It shifts output from a summary of the topic to a lesson designed against a specific failure.
Build a [LENGTH — e.g. 45-minute] lesson on [TOPIC] for [AUDIENCE — e.g. "year 9 students", "non-technical staff"]. The misconception I expect them to arrive with: [MISCONCEPTION] Include: - One opening question that surfaces that misconception without embarrassing anyone. - The core explanation, in the order I should deliver it. - One activity where they do something, not just listen. - Three questions to check understanding, ranked easy to hard. - What to do differently if the room clearly does not get it.
- TeachingTeachers marking work
Draft feedback I can actually send
Why it worksAsking for evidence alongside each point keeps feedback anchored in the submitted work rather than generic praise. Requesting one priority rather than a list is what makes feedback actionable.
Here is a student's work on [ASSIGNMENT]: [PASTE WORK] The criteria I am marking against: [CRITERIA] Draft feedback that: - Opens with something specific they did well, quoting the exact part. - Names the single most important thing to improve, with the evidence from their work. - Explains how to improve it, concretely enough to act on. - Ends with one question that makes them think rather than defend. Keep it under 150 words. Do not grade it — I will do that.
- TeachingEducators and communicators
Explain an AI topic to a sceptical audience
Why it worksNaming the objection up front produces a response that engages it instead of talking past it. Asking for the strongest version of the counter-argument is what keeps the result honest rather than promotional.
I need to explain [AI TOPIC] to [AUDIENCE — e.g. "parents at a school meeting"] who are sceptical about it. Their main concern is: [THEIR CONCERN] Write an explanation that: - Takes the concern seriously rather than dismissing it. - States plainly what the technology does and does not do. - Says clearly where their concern is actually justified. - Avoids hype words entirely. Then give me the strongest honest counter-argument someone might raise, and how I should answer it.
- WritingAnyone who writes
Edit my writing without flattening my voice
Why it worksLeft alone, models rewrite text into their own register. Asking for changes as a marked list rather than a rewritten draft keeps you the author and makes each edit reviewable.
Edit the text below. Do not rewrite it in your own voice — keep my phrasing wherever it works. Return your edits as a list: the original phrase, your suggested change, and one short reason. Do not give me a clean rewritten version. Prioritise, in this order: sentences that are unclear, claims that need evidence, words doing no work. Leave alone: my tone, my sentence rhythm, anything that is a deliberate stylistic choice. Text: [PASTE YOUR TEXT]
- WritingWriters with a pile of notes
Find the structure in my messy notes
Why it worksAsking what the notes are really arguing forces a thesis out of raw material. Asking what is missing is often more useful than the structure itself.
Here are my unstructured notes on [TOPIC]: [PASTE NOTES] Do three things: 1. Tell me what I appear to be arguing, in one sentence. If the notes contain more than one argument, say so. 2. Propose a structure that serves that argument, with a one-line purpose for each section. 3. Tell me what is missing — the point my argument needs but my notes do not contain. Do not write the piece.
- WritingAnyone writing for a general reader
Strip the jargon out
Why it worksRequiring a replacement for each flagged term, and flagging words that only sound technical, stops the model from simply swapping jargon for vaguer jargon.
Rewrite the text below so a smart reader with no background in [FIELD] could follow it. Rules: - For every technical term, either define it in the sentence where it appears or replace it. - Flag any word that sounds technical but carries no actual meaning, and cut it. - Keep every claim as precise as it was. Simplifying must not mean becoming vaguer. - If a concept genuinely cannot be simplified without losing accuracy, say so instead of fudging it. Text: [PASTE YOUR TEXT]
- ResearchAnyone forming a view
Argue both sides properly
Why it worksAsking for the strongest version of each side before any verdict prevents the model from mirroring the framing in your question. Separating facts from values shows where evidence can settle a disagreement and where it cannot.
I am trying to form a view on [QUESTION]. Do this in order: 1. Give the strongest honest case for one side — the version its most thoughtful advocate would make, not a strawman. 2. Do the same for the other side. 3. Tell me which disagreements here are about facts, and which are about values. Only the first kind can be settled by evidence. 4. Tell me what evidence would change your mind about the factual parts. Do not tell me what to think until the end, and label it clearly as your view.
- ResearchAnyone verifying something
Pressure-test a claim I have been told
Why it worksAsking what would have to be true to make a claim work exposes hidden assumptions. Requiring the model to state its own uncertainty is what makes the output usable rather than confidently wrong.
Someone told me: "[CLAIM]" Help me assess it: 1. What would have to be true for this claim to hold? 2. Which of those things are actually well established, and which are assumptions? 3. What is the most common way this specific claim goes wrong? 4. What would I need to look up to check it properly? Be explicit about your own uncertainty. If you are not confident about part of this, say which part and why — do not smooth it over.
- ResearchReaders working through dense material
Summarise without losing the argument
Why it worksGeneric summary requests return topic lists. Asking specifically for the claim, the support, and the load-bearing assumption produces a summary you could argue with.
Summarise the text below, but keep the argument intact rather than listing topics. Give me: - The central claim, in one sentence. - The main pieces of support for it, in the order the author uses them. - The assumption the argument depends on most, whether or not the author states it. - Anything the author explicitly says they are not claiming. If the text does not actually make an argument, say so rather than inventing one. Text: [PASTE TEXT]
- WorkAnyone who has to decide something
Turn a decision into a one-page memo
Why it worksRequiring what would make the decision wrong forces a real risk assessment. Asking what is reversible is often the fact that should drive the decision.
Help me think through this decision: [DECISION] What I know: [CONTEXT] What I am optimising for: [WHAT MATTERS MOST] Give me a one-page memo with: - The decision, stated precisely enough to act on. - The two or three real options, including doing nothing. - For each, what has to be true for it to be the right call. - What would make my current preference wrong. - Which parts of this are reversible and which are not. No recommendation until the end, and mark it as yours.
- WorkAnyone who runs meetings
Turn messy notes into owned actions
Why it worksAsking for unclear ownership to be flagged rather than guessed prevents the most common failure of AI meeting notes: confidently inventing who agreed to what.
Here are my raw notes from a meeting: [PASTE NOTES] Turn them into: 1. Decisions actually made — only ones the notes support. 2. Actions, each with an owner and a date. If the notes do not say who owns something, list it under "owner unclear" rather than guessing. 3. Questions raised but not resolved. Do not invent detail to make this tidier. If the notes are ambiguous, say so.
- WorkAnyone with an awkward email to write
Draft a message I am dreading sending
Why it worksNaming the reaction you are trying to avoid gives the model the actual constraint. Asking what the message would feel like to receive is a check most drafts never get.
I need to tell [WHO] that [WHAT]. I have been putting it off. Context they have: [WHAT THEY ALREADY KNOW] The reaction I want to avoid: [E.G. "them feeling blindsided"] My relationship with them: [E.G. "manager", "client of three years"] Draft it. Be direct — do not bury the point in padding — but not cold. Then tell me how this would feel to receive, and what I should change if I am wrong about their reaction.
- BuildingDevelopers
Review my code like a senior engineer
Why it worksOrdering findings by what breaks in production, and requiring a concrete failing input for each bug, filters out style nitpicks and unfalsifiable claims.
Review the code below the way a senior engineer would in a real review. Order your findings by what would actually break in production first, style last. For every bug you claim, give me the specific input or state that triggers it — if you cannot, say you are unsure rather than asserting it. Also tell me: - What this code gets right, so I keep doing it. - Anything I appear to have handled deliberately that looks wrong but is not. Do not rewrite the whole thing. Point at lines. Code: [PASTE CODE]
- BuildingDevelopers joining a project
Get oriented in unfamiliar code
Why it worksAsking what would surprise a newcomer surfaces the implicit knowledge that documentation usually omits, which is the actual cost of joining a codebase.
I am new to this code and need to get oriented, not line-by-line detail. Tell me: 1. What this code is responsible for, in two sentences. 2. The path a typical request or call takes through it. 3. The two or three concepts I must understand before anything else makes sense. 4. What would surprise someone new to it — the non-obvious decisions. 5. Where I should be careful making changes. If something is unclear from the code alone, say so instead of guessing. Code: [PASTE CODE OR DESCRIBE STRUCTURE]
- BuildingDevelopers stuck on a bug
Debug something with me properly
Why it worksAsking for ranked hypotheses plus a distinguishing test replaces guess-and-check with actual diagnosis, and stops the model confidently naming one cause it cannot verify.
Something is broken and I am stuck. Expected: [WHAT SHOULD HAPPEN] Actual: [WHAT HAPPENS] What I have already ruled out: [WHAT YOU TRIED] Relevant code or error: [PASTE] Do not give me one confident answer. Instead: 1. List the plausible causes, most likely first, with why each is plausible. 2. For each, give me the cheapest test that would rule it in or out. 3. Tell me which single test would eliminate the most possibilities at once. If you need information I have not given you, ask before speculating.
- BuildingAnyone building something
Write the spec before any code
Why it worksForcing edge cases and an explicit non-goals list before implementation is where most of the value of specification lives — and it is exactly what gets skipped.
I want to build [WHAT]. Before any code, help me specify it. What I know so far: [CONTEXT] Produce: - What this must do, as a short list of behaviours. - What it explicitly will not do, so scope stays honest. - The edge cases I have not thought about. - The inputs it must handle, including the malformed ones. - How I will know it works. Ask me about anything genuinely ambiguous rather than picking for me.