Getting Good Work from Claude: Instructions for Claude, Task Briefs and Verification Habits

Version note: This post covers the personalization settings in the Claude apps and how to brief a task, as of 15 November 2026; menu paths and features were checked the same day in the Claude Help Center (support.claude.com). This post is based on the official documentation. The prompts in this post are given as examples; Claude's answer varies by model, settings and account.

Guess First

Selin, the Product Owner of Bookstore, the online bookstore used as the shared example across this site's series, is preparing the e-mail for the November campaign. She writes Claude one sentence: "Write a campaign e-mail." The text that comes back is tidy but unusable: which books, which discount, who it goes to, how long it should be, none of it matches what Selin has in mind. On top of that, Selin has two instructions she wrote in Settings years ago: "Always write briefly" and "Always explain the topic in detail."

What is your guess? Is the problem the model, Selin's one sentence, or those two conflicting instructions? And what is the minimum information the brief needs to make the same e-mail usable in one go? By the end of this post we will have the five parts of a good brief and three questions to ask before using Claude's answer.

The Layers of Personalizing Claude

There are several ways to tell Claude "get to know me", and what you write where decides whether you repeat the same thing in every conversation. The Help Center article "Understanding Claude's personalization features" (https://support.claude.com/en/articles/10185728, 15 November 2026) describes three layers; the fourth is the memory Claude keeps itself:

In accounts that have moved to the unified experience, the old Cowork "Global instructions" field was also folded into Instructions for Claude; the Help Center recommends checking after the move that this field still says what you want. Tone and format used to be handled by the "styles" feature; the current personalization article does not mention styles and points to skills for tone, format and repeatable behaviors. We cover skills in detail in the ninth post, projects in the fourth and memory in the fifth. This post focuses on the first layer and on the task brief in individual conversations.

What to Write in Instructions for Claude

Everything you write in this field is added to every conversation. So only things that are true in every conversation should go here. A sensible start for a backend developer working on Bookstore:

About me: backend developer on Bookstore (.NET 10, ASP.NET Core, SQL Server, Angular).
Language: answer in Turkish; keep code, identifiers and technical terms in English.
Code: C# 14, file-scoped namespaces, async/await everywhere, no .Result or .Wait().
When a request is ambiguous, ask one question before you start.
Say clearly when you are not sure, and label assumptions as assumptions.
Keep answers short unless I ask for detail.

You can write the instructions in Turkish too; the models overview page says all current models are multilingual. What matters is the content. Each of these six lines fixes one decision: who you are and which technologies you work with, the language of the answer and how terms are written, your code preferences, what to do when something is ambiguous, and the default length of the answer. Notice that none of them is about a specific job. A sentence like "this sprint we are working on the returns flow" belongs in the instructions of the relevant project or in that day's conversation, not here; otherwise two months later Claude will try to keep the returns flow in mind even for an unrelated question.

Back to the conflict in Guess First. "Always write briefly" and "always explain in detail" cannot both be true at the same time; when Claude tries to satisfy both, the result is neither short nor detailed. Write such rules with a condition: "Write briefly by default; when I say 'in detail', explain step by step." Reading the instruction list once a month and deleting lines that no longer apply is also a good habit.

The Parts of a Good Task Brief

The provider-neutral basics of writing prompts were covered in the LLM Fundamentals posts "Writing Prompts for LLMs (1): Clear Instructions, Delimiters and Few-shot" and "Writing Prompts for LLMs (2): Step-by-Step Thinking and Reasoning Models"; we will not repeat them here. When you hand Claude a task in daily work, these five parts are usually enough:

• Goal: what you will have when the job is done, who the output goes to, what will be decided with it.
• Context: information Claude does not have and that the job needs; attach the relevant file or data to the same message.
• Constraints: length, tone, rules that must not change, sources that must not be used.
• Output format: a table, an e-mail or an Excel file; headings, sections, language.
• Ambiguity rule: if information is missing, ask it to ask or to label its assumption instead of guessing.

The Help Center's usage limit page gives advice in the same direction: combine related questions into one message, be specific and concise, include the context needed; for writing send the complete text, for research send the question and all the data in one organized message. A good brief means not only a better answer but fewer turns and less usage.

One more step helps on long jobs: asking for a plan first. Saying "list the steps first, start when I approve" keeps a misunderstood task from being noticed half an hour later. The Help Center notes that Claude Docs also asks clarifying questions before it starts writing; you can ask for the same behavior in any job through your brief. After the draft arrives you do not have to regenerate it either: since June 2026 you can select part of the draft and type the change directly to have it edited in place.

What Is Specific to Claude: It Picks Its Own Tools

In the unified Claude experience many decisions are now Claude's rather than yours. There is no switch for web search; Claude searches when it helps. If a file needs to be created or code needs to run, it starts that too; if a skill would help, it loads it on its own by looking at the skill's description. It is a comfortable way to work, but it means saying some things explicitly in the brief:

If you want to limit the sources, say so. A sentence like "use only the files I attached, do not search the web", or the opposite, "use only official documentation sites as sources", decides what the answer rests on. If you want broad, sourced research, start it with /deep-research or with "Research" in the "+" menu; we cover it in the seventh post.

Say when it should stop and ask. When the permission setting in the message box is "Auto", Claude does many steps without waiting for approval; on Enterprise the default is "Manual". For steps that are hard to undo, such as deleting files or writing outward through a connector, adding "ask me before this step" to the brief works whatever the setting. We cover the permission settings of agentic tasks in the tenth post.

Give the file or data with the message. Instead of saying "the report we discussed last week", attaching the file or putting it in a project keeps Claude from recalling the wrong one. Chat search and memory can find earlier conversations, but that does not replace giving the right context explicitly.

Bookstore: The Campaign E-mail, a Bad Brief and a Good One

Selin's first try:

Write a campaign e-mail.

With this brief Claude has no goal, audience, offer, length or tone; it fills every gap with its own guesses. With such a brief, Selin can get close to the text she wants only through correction messages, and the five correction messages that follow use more than a single brief written well from the start. The second try:

Goal: an e-mail for Bookstore's November campaign. It should bring back
customers who bought science fiction in the last 6 months.

Audience: only customers who gave consent for marketing e-mails.
Offer: 15% off the Dune series until 30 November, code DUNE15.
Tone: friendly, not pushy. Plain Turkish, no slang.
Length: subject line, preview text and a body of at most 120 words.
Must include: a one-line unsubscribe sentence at the end.
Must not include: any customer data except a {FirstName} placeholder.

Output: two versions, A and B, that differ in one thing only
(the subject line and the first sentence). After them, a table
that shows what differs and which customer reaction each version tests.

If anything needed for the e-mail is missing, ask before you write.

All five parts are here: the goal in the first line, the context in the audience and the offer, the constraints in tone, length and the required lines, the output format in the two versions and the table, the ambiguity rule in the last line. Two constraints deserve extra attention. The sentence "only customers who gave consent for marketing e-mails" carries the team's rule on KVKK, Turkey's personal data protection law, and on consent for commercial messages into the brief; Claude does not send the e-mail, so this line makes the text fit that audience, while applying the rule is the job of the team that sends it. The {FirstName} placeholder makes sure real customer data never enters the prompt.

The answer expected for this brief: two subject lines and preview texts, two bodies of no more than 120 words, an unsubscribe line at the end and a short table showing the differences. If it notices missing information (for example whether the campaign covers e-books), it should ask before writing. Comparing the answer with each line of the brief takes a few minutes and catches a mistake before it reaches a customer.

Verification Habits

However fluent Claude's answer is, it is a draft to check before you use it. The LLM Fundamentals post "LLM Hallucination and Reliability: Cite, Verify, Measure" explained why models can produce wrong information with confidence. In daily use this comes down to three habits: making assumptions visible, tracing numbers and dates back to their source, and having uncertain parts marked. Asking this in the same conversation before using a draft covers all three:

Before I use this draft:
1. List every assumption you made that is not in my brief.
2. List every number, date and name in the text and where it came from:
   my brief, an attached file, a web source (with the link) or your own knowledge.
3. Mark anything you are not sure about.

The answer to these questions is also model output; but a number marked "my own knowledge" points straight at the place you need to check. In the campaign e-mail, this means seeing that "15 percent" and "30 November" came from the brief and that no other number entered the text. For information from the web, you need to open the source link and see whether it really says that; we look at this in detail with sourced research in the seventh post. On models with high effort, the "Thinking" summary above the answer is also useful to see which way Claude went, but it does not replace verification.

In Production

When working as a team, put the shared rules into project instructions instead of having each person write them into their personal instructions. Instructions for Claude is personal; five different "keep terms in English" sentences from five people on the same team drift apart over time. Project instructions, on the other hand, can be updated by anyone with permission to edit the project.

Do not write secrets into instructions. An API key, a password, a customer name or an internal system address should not go into a field that is added to every conversation. We talk about privacy settings and what goes where in the last post of the series.

Do not expect instructions to solve everything. A very long instruction list also increases usage, because it adds the same content to the start of every conversation. If a rule is needed only for certain jobs, its place is a project or a skill.

Common Pitfalls

Writing rules that conflict. When rules like "write briefly" and "explain in detail" sit side by side without conditions, Claude applies both halfway. Write the rule with its condition.

Pasting the same long context into every conversation. The place for repeated context is a project; there it is managed in one place and counts as less usage because it is cached.

One-sentence requests like "write something". Claude fills the gaps with guesses; the correction turns that follow cost more than a brief written well from the start.

Writing temporary information into permanent instructions. This sprint's job, this month's campaign or a customer's name gets carried into every conversation for months.

Taking a fluent answer for a correct one. Before using any answer with numbers, dates, names and links, ask for its assumptions and sources.

A Small Experiment

★☆☆ Open the Instructions field under Settings > Your Claude. For each line ask "is this true in every conversation?"; delete the ones that are not or move them to the relevant project. If you find two conflicting rules, rewrite them with a condition.

★★☆ Pick three tasks you gave Claude this week and rewrite each according to the five parts (goal, context, constraints, output format, ambiguity rule). Run the same job with both briefs in separate conversations and count how many turns it took to reach an acceptable result.

★★★ Write a shared project instructions text for your team: the language and terms rule, code preferences, the ban on secrets, the rule to ask when something is ambiguous. Have three teammates do the same task inside and outside this project, compare the answers and correct the text.

A good brief and the right instructions keep Claude from starting from zero in every conversation, but they are not enough for documents you use again and again. In the fourth post we look at Claude Projects, project knowledge, project instructions and the RAG that kicks in when knowledge outgrows the context window, using Bookstore's technical documentation project.