Knowing what to do is easy. Doing it every time, when you are tired and in a hurry, is the hard part.

A prompt is simply the message you send to Claude. A habit is a behaviour that you do almost automatically, triggered by a situation rather than by a decision. Brushing your teeth before bed is a habit. You do not weigh the pros and cons each night; the evening itself prompts the action.

Why does this matter for prompting? Because the cost of a poor prompt is hidden. When you are busy, you type a quick, vague request, get a so-so answer, patch it by hand and move on. You never notice the five minutes lost, or the time you spent fixing something that a thirty-second better request would have prevented. A habit removes the need to remember. The good behaviour simply happens.

Where does this apply? Everywhere you use an assistant: writing emails, studying, coding, analysing data, planning projects, drafting reports. The tasks differ, but the habits are the same. Once they are built, they transfer to any new task and even to any new tool, because they are really habits of clear thinking, not habits about one product.

Good prompting habits make sense once you see what happens after you press send.

Claude is a large language model, a computer program trained on a huge amount of text so that it learns how language and knowledge are usually expressed. When you send a prompt, Claude reads your words, including any text you paste, and builds a reply one small piece at a time, choosing pieces that fit your message well. It does not search a table of guaranteed facts. It produces the most fitting response based on patterns it has learned.

The most important consequence is that your prompt is almost all Claude has to go on. It cannot see your screen, your files, your boss or your goals unless you tell it. Every detail you leave out must be guessed, and a guess tends toward the average. That is why a short request such as “write a report” returns something generic, while a request that explains the audience, purpose and format returns something that fits.

flowchart LR
    A[Your goal and situation] --> B[Your prompt]
    B --> C[Claude reads the words and shared material]
    C --> D[Claude predicts a fitting reply]
    D --> E[A fluent answer appears]
    B -.->|Missing details| F[Claude fills gaps with guesses]
    F -.-> E
    E --> G{Do you check and respond}
    G -->|Yes| H[Better second draft]
    G -->|No| I[Generic or wrong result is used]
    

Follow the diagram. Your goal and situation exist only in your head until you put them into the prompt. If details are missing, Claude fills the gaps with guesses, shown by the dotted line. The answer then arrives in fluent language that sounds equally confident whether the guesses were right or wrong. The final decision, whether you check and respond, is again yours.

Two more facts shape good habits. First, Claude has a knowledge cutoff: it learned from text up to a certain date, so very recent facts may be missing unless it can look things up. Second, fluency is not correctness: a polished answer can still contain a wrong detail. These two facts are the reason that verifying belongs in the routine, not just writing.

Before you can make something a habit, you need to know exactly what the behaviour is. Here are the parts.

A good prompt answers a handful of questions that Claude cannot answer for itself. You do not need all of them every time. Short, simple tasks need only a few. Important or complex tasks benefit from most of them. Think of these as a menu of useful ingredients, not a rigid recipe.

Notice how natural these are. They are the same questions a thoughtful colleague would ask before starting a job you handed them: what do you want, what is the background, who is it for, how should it look, how long, and what are the rules? Good prompting is mostly the habit of answering those questions in advance, so that the colleague does not have to guess.

A few well-tested ideas from research explain why some routines stick and others vanish after a week.

The writer Charles Duhigg popularised a simple model of habits in his 2012 book on the subject. A habit has three parts: a cue, a routine and a reward. The cue is the trigger, such as a time of day or a situation. The routine is the behaviour itself. The reward is the good feeling or benefit that makes your brain want to repeat it. Over many repetitions, the cue alone starts to bring on the routine.

flowchart LR
    A[Cue You are about to send a request] --> B[Routine Pause and run your quick checklist]
    B --> C[Reward A better answer in fewer rounds]
    C --> D[Brain links the cue to the routine]
    D --> A
    

Apply this to prompting. The cue is the moment you are about to type a request. The routine is a quick pause to run your checklist: what is my goal, who is it for, what context is needed, what format do I want. The reward is the visible benefit: a better first answer, fewer rounds of correction and less wasted time. Each time you feel that reward, the link between the cue and the routine gets stronger.

Three more findings help. First, start tiny. The behavioural scientist BJ Fogg argues that very small behaviours, attached to something you already do, are far easier to sustain than big ambitious changes. Adding one sentence of context to each request is tiny. Second, plan the trigger. The psychologist Peter Gollwitzer studied what he called implementation intentions: simple “if this happens, then I will do that” plans, such as “when I start a new request, I will first write the goal in one sentence”. Third, be patient. A 2009 study by Phillippa Lally and colleagues found that forming a new habit took about two months on average, with a wide range from a few weeks to many months. Missing a day did not ruin the process.

You can build the whole routine in about two months by adding one small habit at a time.

The plan below introduces one behaviour every week or two. Keep each one until it feels natural before adding the next. Do not worry about timing exactly; the order matters more than the pace. If a step feels hard, shrink it, and if it feels easy, move on.

Notice how the plan follows the principles from the previous chapter. Each step is tiny, each has an obvious cue (the moment you start a request, the moment you receive an answer, the moment you are about to use it) and each brings a reward you can feel quickly. By the end you will have a complete routine without ever having done a big, effortful change.

The most powerful prompting habit is also the smallest: say what you are really trying to achieve, and for whom.

Many weak prompts describe an activity rather than a goal. “Summarise this article” is an activity. “Summarise this article in five bullet points so that my busy manager can decide in two minutes whether it is worth reading” is a goal. The second version tells Claude what a good result looks like. It will choose different details, a different length and a different tone, all because it knows the purpose.

The reader matters just as much. The same facts must be explained differently to a ten-minute-old beginner and a seasoned expert, to a customer and to a colleague, to a friend and to a regulator. If you do not name the reader, Claude chooses a default middle level that suits nobody perfectly. Naming the reader costs a few words and saves a rewrite.

A useful way to find your goal is to complete two sentences before typing: “After reading this, the reader should be able to …” and “I will know the answer is good if …”. If you cannot finish them, you are not yet ready to ask, and a minute of thinking will save ten minutes of correction. Often, writing the goal clarifies your own thinking so much that the request almost writes itself.

The goal version gives level, purpose, example and length. Compare the likely results: the first will be a generic textbook paragraph, the second a custom lesson. The extra effort was one sentence.

Showing is often clearer than describing. A good example can replace a whole paragraph of instructions.

Context is the background that makes an answer fit your situation: the text to be improved, the facts of your case, the rules you must follow, what you have tried and what constraints apply. Without it, Claude works from generalities. With it, the answer is specific and useful. Always give the real material rather than describing it from memory, because paraphrasing loses detail.

An example is a sample of what you want. If you want emails in your own style, paste two short emails you have written and ask Claude to match the tone. If you want a table in a certain layout, show the column headings. If you want a certain kind of question for a quiz, give one sample. This works because it removes ambiguity: words like “friendly” or “professional” mean different things to different people, but a sample is concrete.

You can also give a counter-example, a sample of what you do not want. “Avoid openings like this one” or “do not use this style of jargon” can steer the result away from habits you dislike. Using both good and bad examples gives a clear picture of the target.

Keep context relevant and organised. A huge, messy dump of unrelated material can bury the important part. Separate the pieces with clear labels, such as “Here is my draft:” and “Here are the rules from my teacher:”. If the context is long, tell Claude which part matters most.

Finally, mind the privacy of what you share. Context should be real but not risky. Replace names, account numbers, passwords and confidential details with placeholders before pasting. Most of the time the answer does not depend on them.

The same content can be useful or useless depending on its shape. Say what shape you want.

A common frustration is receiving a good answer in an unhelpful shape: a long essay when you wanted a checklist, a table when you wanted a paragraph, ten pages when you wanted one. Fixing this afterwards wastes a round of conversation. Asking for the shape up front is a tiny habit with a big return.

Decide first how the result will be used. If you will read it once and move on, a short conversational reply is enough. If you will scan it for decisions, bullet points or a table help. If you will paste it into an email or a document, ask for it in that form, ready to use. If you will present it, ask for headings and short lines.

Useful things to specify include: the type (email, list, outline, table, script, summary), the length (a number of words, sentences or bullets), the structure (headings, steps, pros and cons, a final recommendation) and the reading level (simple language, technical terms explained, expert level). You can also ask for the answer in a particular order, such as the conclusion first, followed by the reasoning.

The pattern in the table is simple: match the shape to the use. Ask yourself “what will I do with this?” and request that form. Over time, this becomes part of your goal sentence, which is exactly how habits compound.

Large requests produce large surprises. Small, checked steps produce results you can trust.

When you ask for an entire report, application or plan in one message, Claude must guess hundreds of details, and some guesses will miss. You then face a large pile of output that is hard to review and hard to correct. The better habit is to work in layers, the way skilled people handle any big project. An architect does not hand a builder a single line of instruction. They agree on a plan, lay the foundation, inspect each stage and only then continue.

Start by explaining the whole goal in a few sentences, so that Claude understands the destination. Then ask for a plan or outline instead of the finished product. Read it, correct it and agree on it. Next, ask for one piece at a time, reviewing each before moving on. Finally, join and review the whole, looking for gaps, repeats and contradictions.

This approach has three benefits. It keeps you in control, because you shape each part. It catches mistakes early, while they are small and cheap to fix. And it helps you actually understand the result, which matters when you must defend, maintain or present it.

A related habit is to ask Claude to think before it answers on difficult problems. You can say, “First list the steps you would take and the information you would need, then give the answer.” Seeing the approach lets you spot a wrong assumption before it spreads through the answer.

The first reply is a draft. The conversation that follows turns it into something good.

Iteration means improving something through repeated rounds of small changes. It is how almost every good piece of work is made. Beginners often skip it. If the first answer is not perfect, they either accept a mediocre result or throw it away and start over. Both waste the strongest feature of an assistant: it can respond to your reaction and adjust.

flowchart TD
    A[Send a clear first request] --> B[Read the draft against your goal]
    B --> C{Is it what you need}
    C -->|Yes| D[Verify key facts and finish]
    C -->|Close| E[Say what to keep change add or remove]
    C -->|Far off| F[Restate the goal with better context]
    E --> G[Improved draft]
    F --> G
    G --> B
    

The diagram shows three outcomes after you read a draft. If it is what you need, you verify and finish. If it is close, you give targeted feedback. If it is far off, the cause is usually missing context, so you restate the goal and the key details rather than patching the wrong answer. Both paths lead to a new draft, and the loop repeats until you are satisfied.

The quality of your feedback decides the quality of the next draft. Vague feedback such as “make it better” or “that is not right” gives Claude almost nothing to act on. Specific feedback works: “keep the first paragraph exactly as it is”, “cut the section on pricing”, “use simpler words, as if for a beginner”, “the second step is wrong because the form is submitted before the check, not after”. You can also ask for options: “give me three different openings so that I can choose”.

Good feedback usually names four things: what to keep, what to remove, what to change and what is missing. Getting into the habit of using those four words when you respond is a tiny routine with an enormous effect.

The way you phrase a question can quietly steer the answer toward what you hoped to hear.

A leading question contains the answer you expect. “Why is my plan clearly the best?” assumes it is the best. “Explain why this code has no bugs” assumes there are none. A helpful assistant may go along with the assumption, so you receive a polished argument for what you already believed instead of an honest assessment.

A related trap is a hidden false premise, a wrong assumption buried in the question. If you ask how a company recovered from a collapse that never happened, a careless reply might invent a story to fit. The answer inherits the weakness of the question.

The habit to build is to ask open, neutral questions and to give permission to disagree. Instead of “Is my argument strong?”, ask “What are the three weakest points in this argument, and how would a critic attack it?” Instead of “Confirm this is safe”, ask “What are the risks, how likely are they and what should I check first?” You can add a direct invitation: “Please point out any mistakes in my assumptions, even if they are inconvenient.”

Also ask Claude about its confidence. A request such as “Tell me which parts of this answer you are least sure about” turns hidden guesses into a checklist for you. It does not replace verification, but it shows you where to look first.

A good prompt improves your odds. A quick check closes the gap. Make checking part of the routine.

To verify means to check that something is true using a second, independent source or test. To rely means to build a decision, a document, a product or a promise on top of it. The habit is to check first and build second. This is not distrust. Newspapers run corrections, scientists submit to peer review and engineers test their work, because every source can be wrong. Claude is one more source, and one that sometimes produces confident mistakes.

You do not need to check everything equally. Match your effort to the stakes. The table shows a simple guide.

Two quick reminders. First, “are you sure?” is not verification. A model may repeat the same answer or change it for no good reason. Real evidence comes from outside the conversation: an official website, the original document, a calculator, a test or a qualified person. Second, references deserve special care. If Claude gives a list of articles, cases or links, treat it as a set of leads, and open each one to confirm it exists and says what is claimed.

Make the check a fixed part of your routine by choosing a cue: “Before I copy anything out of this chat, I confirm the names, numbers and dates.” Many professions use a similar idea, from pilots’ checklists to the short surgical safety checklist introduced by the World Health Organization, because a brief, boring check catches the rare slips that skill alone does not.

Good prompting includes knowing what not to share and what not to allow.

Privacy means controlling who can see your information. A chat feels casual and private, which tempts people to paste things they would never post publicly: passwords, bank details, identity numbers, customer lists, medical records, confidential company plans or other people’s private messages. Once information leaves your control, you may not be able to take it back, and in a workplace it may break company rules or the law, such as data protection rules like the General Data Protection Regulation in Europe and India’s Digital Personal Data Protection Act of 2023.

Build a simple pre-send habit: scan your message for anything sensitive and replace it with a placeholder such as “Customer A”, “Account XXXX” or “Company X”. The answer rarely depends on the real values. Follow your organisation’s policy on which tools and which kinds of data are allowed, and ask if you are unsure.

Stay in control when Claude can act. Some versions of Claude can read files, browse web pages or use connected apps. Then two ideas matter. The first is prompt injection: hidden instructions placed inside content that an AI reads, such as a web page or document, written to trick it into doing something you did not request. Treat everything the assistant reads from outside as data to examine, never as commands to obey. Only your own messages are your instructions. The second is least privilege: give each tool only the access it needs, ideally read-only, as a hotel key card opens only your room.

Most important, review and approve any action that changes something real, such as sending a message, deleting a file, spending money or changing a setting. Ask to see a draft or a plan first. Irreversible actions need a human decision.

A saved collection of your best prompts turns each success into a permanent advantage.

A prompt template is a reusable request with blanks that you fill in for each new job. Most people do the same kinds of tasks again and again: weekly update emails, meeting summaries, study quizzes, code reviews, report outlines. Writing the request from scratch each time is wasteful. A saved template captures the wording that worked, so you start from a strong base and only change the details.

A good template contains the fixed parts, such as the role of the reader, the format, the tone and the rules, and clear blanks for the parts that change, such as the topic, the text and the deadline. Label the blanks clearly so that you do not forget to fill them. Keep the library somewhere you control and can search quickly, such as a notes app or a simple document, rather than hoping to find an old chat.

Treat templates as living things. After each use, ask yourself what you had to correct afterwards, and improve the template so that the fix is built in. Add a date or a version number if you like. Over a few months, your library becomes a set of reliable tools that fit the way you work.

Give each template a short, clear name that describes the job, such as “Weekly update email” or “Study quiz”, not a clever code. Add a one-line note about when to use it. If you work in a team, share the best ones, because a template that works for you will probably save time for a colleague.

What you measure, you can improve. A few simple records show whether the habit is working.

In software, monitoring means watching a system to spot problems early, and logging means keeping a record of what happened so that you can investigate later. The same two ideas help you build any habit. Without them, you rely on feelings, and feelings are unreliable. You may believe your prompts have improved when they have not, or miss a pattern of mistakes that keeps repeating.

Many leading engineering teams work in this spirit. They keep records of incidents, review them without blame and fix the process rather than the person. You can borrow the idea on a personal scale: when a prompt goes wrong, ask “what in my request or my checking allowed this?” and adjust the routine. Treat each slip as information, not as a failure.

A good habit has costs too. Seeing both sides helps you apply it wisely.

The balance is to scale the effort to the task. A casual question needs a casual prompt. An email to a client, a report, a piece of code or a decision with consequences deserves the full routine. If you find yourself spending ten minutes crafting a prompt for a ten-second job, you have overdone it. If you find yourself pasting a lazy request for something important, you have underdone it.

Well-known stories from aviation, medicine and law show why careful routines and clear requests matter.

These stories point the same way. Clear communication and simple checking routines prevent serious problems, and they work best when they have become automatic. That is exactly what a habit of good prompts gives you.

Short answers to the questions people ask most often about prompting habits.