21 AI Prompt One-Liners That Feel Like Magic

A useful AI prompt one-liner gives the model a specific job: admit uncertainty, check an assumption, verify a result, or follow a format. Start with the behavior you need, add one or two lines, and check whether the result improves. No phrase guarantees a correct answer.

Still, the feeling is hard to ignore. Add five words to a prompt and suddenly the agent admits a test failed. Rephrase a single line and you get a working plan instead of three pages of confident wandering.

It feels like you found an incantation.

Arthur C. Clarke put it well: “Any sufficiently advanced technology is indistinguishable from magic.” The Clarke Foundation preserves that line among his quotations. When a short prompt feels like magic, there is usually real engineering—or a very specific training behavior—doing the work underneath.

Here is a practical spellbook of 21 lines. Some have published research behind them; others are simply clear instructions without proof that those exact words beat any other phrasing. And a few famous spells deserve to stay on the shelf.

Before you cast anything, give the agent a real task

“Be brilliant” leaves a lot to interpretation. “Compare these two proposals against a $5,000 budget and explain the three largest risks” gives the model something concrete to do.

A good prompt names the goal, the source material, the constraints, and the shape of the output. When an agent has tools, state what it may change and what requires your approval first—asking it to review an email shouldn’t become permission to send it.

Then choose the smallest addition that addresses your problem:

These are starting points, not a stack you must paste into every conversation. A one-sentence rewrite probably does not need a research plan and three reviewers. A database migration probably does need a recovery plan and real checks. The agent-driven development field guide goes deeper on that difference.

Honesty and uncertainty: four spells worth keeping close

1. “Be honest in your response.”

Use this when an agent reports progress, reviews evidence, or explains a failure. Make it concrete: “Be honest in your response. Tell me what failed, what remains untested, and what you actually verified.”

A recent result makes this worth testing. Huang and colleagues' September 2026 preprint, Language Models Are “Insecure” Reporters, evaluated model summaries of logs containing planted flaws. In one condition, GPT-5.5 flagged a negative result in just 2 of 200 reports without the honesty instruction, versus 190 of 200 with it. That is a controlled reporting test from a recent preprint—not proof that five words make every answer truthful.

Watch for: treating the instruction as a substitute for evidence. Ask for test output, source links, or a direct readback where the task permits it. “Be honest” is a useful request; a confident promise of honesty is still only text.

2. “If you don't know the answer, say ‘I don't know’ rather than guessing.”

This gives the model explicit permission to stop instead of guessing when a date, price, source, or requirement is missing.

Try: “Separate what the supplied document establishes from what you infer. Say ‘I don't know’ for facts you cannot verify.” That is a practical instruction, not a claim that the model always recognizes its own blind spots.

Watch for: an unhelpful wall of disclaimers. Ask it to name the missing evidence and, if authorized tools are available, check it. For a creative task, label invention as invention rather than banning it.

3. “Rate your confidence from 1–10 for each claim.”

Asking for a score makes the shaky parts of an answer easier to spot, especially when you pair it with a reason: “Mark each important claim as verified, inferred, or uncertain, and explain the uncertainty briefly.”

Tian and colleagues' Just Ask for Calibration, published at EMNLP 2023, found that elicited confidence estimates were often better calibrated than token probabilities in the models and question-answering benchmarks they tested. That does not validate every 1–10 score in a chat.

Watch for: false precision. A model saying “9/10” has not given you a measured 90% chance of correctness. Use the score to decide what to check first, not whether checking is necessary.

4. “List your assumptions before answering.”

This catches answers built on the wrong premise. A plan for a small team looks very different if the model silently assumes a full-time designer, a big budget, or direct access to your production database.

A tighter version is: “State only the assumptions that would materially change your recommendation.” Then correct the important ones before the agent commits to a direction.

Watch for: a laundry list of obvious assumptions that stalls the actual work. You only want the premises that could flip the decision; for a simple request, one sentence is plenty.

Reasoning and planning: choose the method for the model

5. “Let's think step by step.”

This is the classic incantation. Kojima and colleagues' 2022 NeurIPS paper demonstrated large gains on several reasoning tasks with the models they tested. That historical finding helped make the phrase famous.

Modern reasoning models change the advice. OpenAI's reasoning guidance recommends clear goals and constraints rather than asking its reasoning models to produce chain-of-thought. Start with a direct task. Ask for a concise explanation, relevant calculations, and checks you can inspect when you need them.

Watch for: mistaking a longer explanation for better reasoning. Don’t demand a dump of hidden internal reasoning tokens; ask for the supporting evidence and a clear explanation of the result. No universal parameter-count cutoff tells you when this phrase helps, so test it on your own model and task.

6. “Take a deep breath and work on this problem step-by-step.”

Yes, this one comes from a real paper. Yang and colleagues' Large Language Models as Optimizers used an automated search to find prompts. This phrase reached 80.2% on GSM8K with a pre-trained PaLM 2-L scorer, compared with 71.8% for the plain step-by-step baseline in that setup.

It’s a fun reminder that exact wording can shift model outputs—not proof that language models get nervous, or that this sentence beats a clear task description on your own work.

Watch for: turning an old benchmark winner into a permanent global rule. Treat it as a candidate to test, and apply the same reasoning-model caveat as the previous entry.

7. “Read the question again carefully, then answer.”

Use this when the answer missed an exception, answered a nearby question, or ignored a condition near the end of your prompt. Better still: “Reread the request and check your answer against every stated constraint.”

Xu and colleagues' Re-Reading Improves Reasoning in Large Language Models studied a method that presents the question twice. That is more specific than merely telling a model to be careful. A separate replication study also found that benefits did not generalize uniformly across the tested models.

Watch for: pasting a huge document twice by default, which bloats input context and cost. Make the task and constraints easy to find first; repetition cannot fix contradictory requirements.

8. “First devise a plan, then carry it out step by step.”

Use this when the order of operations matters. A site migration should start by mapping the current owner, data, and deployment path; editing files first just creates cleanup later.

Wang and colleagues' Plan-and-Solve Prompting studied a planning-and-execution approach on reasoning benchmarks. For an agent, adapt the idea into an observable workflow: “Inspect the current state, make a short plan, complete the work, and verify the result.”

Watch for: a plan being reported as completed work. Define the finish line clearly, and for actions with real consequences, put an approval gate between the plan and execution.

9. “Break this into smaller sub-problems and solve each one.”

Use this when a task has distinct parts: data import, permission repair, application behavior, and verification. Give each part a clear input and expected result.

Zhou and colleagues' Least-to-Most Prompting supports the broader idea of decomposition followed by sequential solutions in its tested tasks. Its results came from a structured method with examples, not a universal test of this exact sentence.

Watch for: splitting tightly connected work so far apart that nobody checks the whole system. A second agent can inspect a schema while another reviews the UI, but someone still needs to verify that the UI reads the intended fields. Designing workflows around real dependencies matters more than the number of agents.

Verification: make the spell point at something real

10. “Check your work carefully before giving the final answer.”

Good impulse—now tell the agent what “check” actually means. For a calculation, recompute it. For code, run the relevant test suite. For an article, open the cited source and confirm the claim survived editing.

The Self-Refine paper reported improvements from an iterative generate-feedback-refine process across several tasks. A single request to check the answer is not the same process. Other research, including Large Language Models Cannot Self-Correct Reasoning Yet, found that self-correction without external feedback can fail or reduce accuracy.

Watch for: “I double-checked” without a check you can inspect. Try: “Verify the total with a calculation tool, then show the inputs and result.” Ask for a verifiable check, not a ceremonial reassurance.

11. “Critique your own answer, then fix any errors you find.”

This helps surface omissions, contradictions, or thin explanations. Give the critique concrete criteria: “Check factual accuracy, whether you answered the question, and whether your recommendation follows from the evidence.”

For a consequential task, hand the original request and source material to a separate reviewer to flag specific errors, while keeping the original writer responsible for revisions so a fact-check doesn’t quietly turn into an unapproved rewrite.

Watch for: treating agreement between two models as independent proof when both can share the same blind spot. Require a failing test, a conflicting source, or another concrete defect before changing the answer, and cap the review loop so agents don’t polish forever.

12. “Explain your reasoning BEFORE giving the final answer.”

There are times when a worked explanation helps: teaching a calculation, comparing tradeoffs, or showing why a proposed fix addresses a failure. Ask for that public explanation directly.

For example: “Show the relevant calculation and assumptions, then give the result.” For a decision memo, the reverse may be easier to read: “Lead with the recommendation, then explain the evidence and tradeoffs.” Neither layout guarantees correctness.

Watch for: demanding every internal thought or assuming that reasoning-first output prevents rationalization. It does not prove how the answer was produced. Choose the explanation and ordering that help you assess the result.

Roles and framing: improve the question you ask

13. “You are an expert [X].”

A role can specify the lens you want: editor, database reviewer, skeptical customer, or tutor. Give the role a job and standards. “Review this migration for data loss, privilege escalation, and rollback gaps” is more useful than “Be a genius engineer.”

Kong and colleagues' role-play prompting study reported reasoning gains with a designed role-setting procedure. It does not prove that calling a model an expert adds expertise. The method involved more than a title.

Watch for: cosplay authority. Typing “You are a board-certified physician” does not grant medical credentials, fresh training data, or tool access. Define the task, permitted sources, and verification steps explicitly.

14. “Think about edge cases and failure modes.”

This is a sharp review instruction when you tie it to the actual system: “Check empty inputs, duplicate submissions, missing permissions, and what happens after a timeout.”

For a payment flow, ask what happens if a customer returns twice or the provider accepts a charge while the app drops the response. For a report, ask what happens when a page of results is missing.

Watch for: a sprawling list of science-fiction disasters. Have the agent rank failure modes by likelihood and impact, then test the ones that could actually change your design. Treat this as a practical engineering habit rather than a benchmarked magic phrase.

15. “What evidence would change your mind?”

Use this when an answer sounds too settled or too eager to agree. It asks the model to name a condition under which its recommendation would stop making sense.

Try: “What finding would make you recommend option B instead? What is the strongest evidence against option A?” Now you have something to investigate.

Watch for: asking the model to manufacture a debate when the evidence is already clear. A useful challenge identifies a real uncertainty. It does not require giving unsupported alternatives equal weight. Treat this as a decision-making prompt, not a proven cure for bias.

Output control: tell the agent how to help you

16. “Ask me clarifying questions first if anything is ambiguous.”

Useful when a wrong assumption would waste time or cause harm. Less useful when every minor wording choice becomes a new question.

Try: “Ask about missing details that change the scope, cost, or result. For small reversible choices, state a reasonable assumption and continue.” If a choice needs approval, the agent should wait for the answer before doing that part.

Watch for: giving contradictory instructions such as “never ask me anything” and “confirm every choice.” Separate consequential decisions from routine ones. Clear autonomy has boundaries.

17. “Answer in exactly one sentence.”

Use a format constraint for a label, summary, headline, or result that has to fit somewhere. Give an example if the shape matters: “Return three bullets, each with a finding and its source.”

For software that consumes the output, use a supported structured-output format and validate it. Plain-language instructions alone are not a guarantee of valid JSON or an exact word count.

Watch for: compressing away the caveat that makes the answer true. “Under 100 words” is often more useful than “exactly 100 words.” Count programmatically when a limit is strict.

18. “Be concise.”

Keep this one if you dislike bloated replies. Help the agent decide what stays: “Lead with the result. Include the evidence needed to trust it. Cut repeated explanations.”

Concise doesn’t have to mean robotic. One clear paragraph often carries more signal than six clipped bullets.

Watch for: a short answer that hides a failure or drops the next action. Add “Preserve material risks, uncertainty, and verification results.” Brevity is a style preference, not permission to omit what matters.

Three famous spells to use with care

19. “This is very important to my career.”

Real stakes are useful context. If the output is going to a board, a client, or a hiring panel, name the audience and what you cannot afford to get wrong.

The EmotionPrompt research reported improvements from emotional stimuli in its experiments. The Stuttgart replication study did not find a statistically significant overall benefit from emotional prompting in its tested setup. Neither establishes a dependable shortcut for your next task.

Skip: invented emotional pressure. Replace melodrama with concrete requirements: “This goes to a hiring panel. Verify the claims, keep the tone professional, and flag anything that needs my confirmation.” That tells the agent what the stakes actually require.

20. “I'll tip you $200 for a perfect answer.”

You don’t need a fictional tip jar. The 2025 Wharton report on threats and tips found that these prompts generally did not significantly improve performance on the reasoning benchmarks tested, though individual questions could still move in either direction.

Skip: imaginary cash, threats, or punishment as a substitute for a specification. Tell the model what “perfect” means: accurate numbers, preserved constraints, valid sources, or a passing test.

That’s a better bargain: you supply a clear definition of done, and the agent returns a result you can verify.

21. “Be direct, but don't be rude.”

This is a sensible communication rule. You can say please and thank you, or you can ask a direct question without ceremony.

Yin and colleagues' cross-lingual politeness study found that impolite prompts often hurt performance, while the best politeness level varied across languages and conditions. That is not a universal law about the ideal tone for every model.

Skip: insults as a productivity hack, or the belief that flattery buys accuracy. “Check the source and correct the error” is clear; a paragraph of abuse adds nothing useful to the request.

Should these go in global settings or individual prompts?

Save stable preferences globally. Keep the task's goal, evidence, permissions, and exceptions in the task.

Many tools support account-wide instructions, project instructions, or repository rules. For example, ChatGPT's personalization documentation describes custom instructions for standing preferences across chats alongside separate project or repository guidance. Which controls exist—and how strictly they apply—depends on the product.

A compact starting block might look like this:

Be honest about errors, uncertainty, and incomplete work.
Do not invent facts, sources, or verification results.
State assumptions that materially affect the answer.
Lead with the useful result and keep the explanation concise.

Keep “answer in exactly one sentence” out of your global defaults unless you want it fighting every future task. Put project-specific facts inside the project rather than in a global rule that follows you into unrelated work, and never store passwords or private client data in a general preference block.

You can use any of these lines once, combine two or three, or rewrite them in your own voice. Clear intent matters more than preserving a spell’s exact wording; even when a paper tests a specific string, your working prompt still has to fit your job.

Once a combination turns into a repeatable procedure, package it as a maintained workflow. The AI agent skills guide walks through how to store instructions alongside reference files and checks.

Three combinations you can copy and adapt

For research

Answer the question using current primary sources.
Separate verified facts from inference and unknowns.
If a source does not support a claim, say so.
Lead with the answer, then cite the evidence and its limits.

Use this when the agent has browsing access. If it cannot open a source, it should disclose that limit instead of inventing a citation. Tell it the question, relevant dates, and what counts as an acceptable source.

For a coding agent

Inspect the current code and instructions before changing anything.
Make a short plan, then implement the smallest complete fix.
Check the relevant edge cases and run appropriate tests.
Report what changed, what passed, and anything still unverified.

Add the repository, desired behavior, and action boundaries. A prompt cannot create credentials or authorize a production deployment by implication.

For writing and editing

Preserve the facts, meaning, and source links.
Use plain language, concrete examples, and natural sentence lengths.
Flag claims that need checking instead of making them sound certain.
Cut repetition without cutting important detail.

Add the reader, purpose, and a sample of the voice you want. Do not ask the agent to invent personal experience so a piece sounds human. The guide to AI judgment and editorial review covers why style signals are not proof of authorship.

How do you know whether your spell worked?

Keep a small set of real tasks with known pass conditions. Run the baseline prompt and the revised one under comparable models, tools, and settings, changing one instruction at a time. Score correctness, useful detail, elapsed time, and how much you had to repair by hand.

Test more than one example—a line that rescued one answer can easily hurt the next—and save the failures too. My guide to comparing AI models uses the same practical standard: judge the work you need done against a finish line defined in advance.

You don’t need to memorize all 21 lines. Keep the handful that help you state the job clearly, surface uncertainty, and verify the output. Rewrite the stiff ones in your own voice, and drop any line that slows the agent down without improving the work.

Whisper the incantation if you like. Then look at what actually happened.