Custom instructions: set up AI once, it applies forever

When you tell AI “shorter,” “in English please,” or “skip the opening paragraph” every single time, say it once, for good. Custom instructions are a few sentences saved in your settings that get added automatically to every new conversation — the model sees them before you type your first word.

Most people either leave them blank or fill them in with one sentence like “I'm a manager, answer concisely.” Both are a missed opportunity, because well-written instructions save you the first two messages of every conversation — and if you open ten conversations a day, that's fifteen minutes a day, and, more importantly, the end of endlessly fixing the same thing. The difference between one sentence and a working set is specificity: the more precisely you describe the behavior, the more reliably you get it.

This guide walks from a blank field to a set you won't have to touch for months. You'll go through what belongs in instructions and what doesn't, where the line sits between instructions, a Project, and a single prompt, get four ready-made sets to copy, and learn how to test them and clean them up once a quarter.

A typical scenario

Martin, a project manager, opens twelve to fifteen conversations a day: for planning, for emails, for quick summaries, for meeting prep. Almost every one starts the same way. The model answers with a long paragraph, opens with “great question,” and offers five options when Martin wanted a recommendation. Martin adds “shorter, in bullet points, no intro,” and only the third message is the one he actually uses. Two wasted messages times fourteen conversations comes out to roughly twenty minutes a day.

After setting up instructions, the first answer lands. The model knows Martin is a project manager at a construction company, that he wants answers in bullet points with the recommendation up front, that he doesn't like pleasantries, and that anything headed to a client should flag the spots the model isn't sure about. Over three months he's tweaked the instructions twice — adding a rule about “for time estimates, state what you're basing them on” and “when you're missing information, ask instead of guessing.”

The difference isn't that AI suddenly got smarter. It's that Martin stopped explaining who he is and what he wants every single day.

Phase 1: three layers of context, and what goes where

The most common mistake isn't a badly written instruction, it's information sitting in the wrong layer. The context a model works with has three floors, and each has a different shelf life.

Layer 1: custom instructions (always apply)

A standing account setting added to every new conversation regardless of topic. Only what's true always and across everything you do with AI belongs here: who you are, how you want answers formatted, in what tone, and what to never do. This should run to tens of lines, not a whole page.

The test for whether something belongs in this layer: would this still be true in a conversation about a completely different topic than the one you're having right now? If you're not sure, it doesn't belong here.

Layer 2: a Project (applies to one area)

A Project is a space with its own instructions and uploaded reference material that only applies to conversations held inside it. This is where everything specific to one area of your work belongs: the tone for a specific client, the report structure leadership wants, samples of your past writing, a product description, a glossary of internal abbreviations.

The difference boils down to one sentence: custom instructions describe you, a Project describes one area of your work. If you write “with client Beta, be formal and use their preferred style” into your custom instructions, you pay for it by having the model be formal in a conversation about your vacation, too. The projects and persistent context tip covers projects in more detail.

Have a Project's instructions written for you directly; they're more specific than personal ones and harder to come up with off the top of your head:

I'm setting up a project for [area — e.g. communication with client
Beta / monthly reports for leadership / writing product copy].

What I do in this area: [two to three sentences].
Who receives the output: [who reads it and what they do with it].
What I haven't liked about past output: [specifically].

Write this project's instructions:
- rules about format and structure that apply specifically here
- tone toward this recipient
- three to five things that must never happen in this area
- what reference material I should upload to the project so these
  rules don't need to be spelled out in words

Don't include anything that applies to my work in general — that's
already in my custom instructions and I don't want to duplicate it.
Keep it under 200 words.

The last paragraph matters: without it, the model repeats your general preferences into the project too, and you end up with the same rule in two places that drift apart over time. Use the point about reference material — a sample of two good outputs replaces half a page of style description.

Layer 3: a single prompt (applies to one task)

This is where everything variable belongs: the actual request, the input text, a deadline, a recipient, a goal. And also one-off exceptions to your instructions — when your instructions say “be concise” and you need a long analysis just this once, you say so in the prompt and the instructions step aside.

Proven prompts belong in a library, not in instructions; the prompt library tip covers how to keep one.

A prompt that sorts the layers for you

Once your instructions have gotten longer than they should be, have them sorted for you:

Here's what I currently have written in my custom instructions:

[paste the full instructions text]

This is what my work with AI looks like: [two to three sentences —
what you use it for, which areas, for whom].

Sort every sentence from the instructions into three groups:
1. BELONGS IN INSTRUCTIONS — applies to every one of my
   conversations regardless of topic.
2. BELONGS IN A PROJECT — applies to just one area; say which
   project it should be part of.
3. BELONGS IN A PROMPT — it's variable context or a one-off thing.

For each sentence, write one sentence on why it belongs there.
At the end, return a shortened version of the instructions
containing only group 1 — unchanged wording, just with the rest
dropped.

It returns the sorted instructions and a noticeably shorter version. The last line matters: without it, the model rephrases sentences on its own when “shortening” them and you lose the precision you worked to get. Review the drop suggestions — it occasionally flags as project-specific a rule that genuinely does apply across everything you do.

Phase 2: what belongs in instructions

A working set has four blocks. Keep them in this order, because the model reads top to bottom, and what comes first carries more weight.

Who you are (role and context)

Two to four sentences: profession, field, who you work for, what you typically handle, and your level of knowledge. The point isn't to introduce yourself, it's to give the model a baseline — what level to explain things at, what shorthand it can use without spelling it out, and what's obvious in your field.

The difference shows up immediately. “I'm a manager” does almost nothing. “I lead a team of eight people at a construction company; I handle project budgets, client communication, and capacity planning; I understand the technical side of construction well, not so much accounting” changes answers substantially — the model stops explaining what a schedule is and starts spelling out accounting terms. The role and context tip goes deeper into using role in individual prompts.

How you want answers (format)

The most impactful block, and also the one people write the most vaguely. “Answer concisely” is a weak instruction, because everyone pictures concise differently. A strong instruction describes structure and length in numbers: how many bullets, how long a paragraph, what comes first, when to use a table.

Concrete examples that work: “Start the answer with a recommendation or a direct answer, only then the reasoning.” “Longer answers broken into bullet points, seven maximum.” “When comparing several options, use a table, not paragraphs.” “Code always with a short comment on what it does.” “No summary at the end when the answer is shorter than ten lines.”

What tone (style)

Describe tone through a relationship you know: “write like an experienced colleague who doesn't have time for pleasantries,” “talk to me like a consultant who'll tell me the unpleasant part too.” Add language and level of expertise — whether you want plain English with technical jargon kept as-is, or everything spelled out in plain terms.

This is also where how to handle disagreement belongs. Models tend to agree and soften; if you want pushback, you have to ask for it: “If you think I'm wrong, say so right at the start of the answer, not carefully in the last sentence.” This one rule changes the usefulness of answers more than all the formatting rules combined.

What to never do (bans)

Bans work best of any instruction type, because they're unambiguously checkable. List three to six things that reliably annoy you: opening phrases like “great question,” emoji, offering next steps at the end, apologetic phrasing, repeating the question before answering, explaining things you didn't ask about.

Bans should also include one safety rule worth having in instructions permanently: “When you're not sure of a fact, a number, or a citation, say so explicitly instead of guessing.” Models make things up convincingly, and this sentence won't catch everything, but it surfaces a chunk of what you'd otherwise miss. The fact-checking with AI tip covers systematic verification.

A skeleton to fill in

WHO I AM
[profession, field, who I work for, what I typically handle]
[what I understand well and what I don't — where you should
explain more]

HOW I WANT ANSWERS
- [structure: what comes first, when bullets, when a table]
- [length: how many bullets, how long a paragraph]
- [language and technical terminology]

TONE
- [how to talk to me — a relationship, not adjectives]
- [how to act when you think I'm wrong]

WHAT TO NEVER DO
- [three to six specific bans]
- When you're not sure of a fact, a number, or a citation, say so
  instead of guessing.

WHEN YOU'RE MISSING INFORMATION
- [ask / make an assumption and flag it]

The last block is the most forgotten one, and it's what decides answer quality on harder requests. Without it, the model fills missing context with a guess and you only find out from the result.

Phase 3: what doesn't belong in instructions

Instructions mostly go stale because people put things into them that change. Then they stop being true, the model keeps working from them anyway, and you can't figure out why the answers are off.

Variable context. The project you're currently working on, the client you're dealing with right now, a submission deadline, last quarter's numbers. All of this is true today and false in two months — and the worst part is the model doesn't know about the change and will keep assuming it.

Sensitive data. Colleagues' names, client names, health information, financial details, login credentials. Instructions get sent with every conversation, so whatever you put in them leaves your computer even on the most trivial question. Sensitive information belongs only on a paid account with contractual data protection, and even there, only in anonymized form.

Long reference material. A two-page product description, your company's tone of voice, a price list, a list of internal abbreviations. It's not that it wouldn't work — it's that it eats up the model's attention in every conversation, even when you're asking about the weather. Reference material belongs in a Project's knowledge base.

Rules for a single area. “Always include a chart with reports for leadership” is a rule for a Project, not for instructions. You can spot it by the condition at the start: when an instruction starts with “for,” “when,” or “in the case of,” it almost always belongs a layer down.

Contradictory rules. “Be concise” and, at the same time, “always list every alternative and reasoning” cancel each other out. The model picks one depending on the situation, and you won't know why. When you hit a conflict, commit to one and ask for the other via a prompt on the occasions you actually need it.

Things you can't check. “Be creative,” “think deeper,” “try harder” don't do anything measurable. Replace them with a description of behavior: instead of “be creative,” write “also offer an option outside the usual approach, and flag it as riskier.”

Run a check in one pass:

Go through these custom instructions of mine:

[paste the instructions]

List every sentence with one of these problems in a table:
finding | type | what to replace it with

Look for these types:
- VARIABLE — information that won't be true a few months from now
  (current project, client, deadline, numbers)
- SENSITIVE — a name, contact, amount, anything personal
- UNCHECKABLE — an instruction you can't tell whether was followed
- BELONGS ELSEWHERE — a rule that only applies to one area of work

Don't rewrite anything outside the “what to replace it with” column.
If a sentence is fine, don't list it.

The replacement column is what makes the prompt worth running — for uncheckable instructions, you get a concrete phrasing instead of vagueness. For sensitive findings, don't rely on the model alone — you know best what's actually sensitive.

Phase 4: ready-made sets to copy

The following four sets are a working baseline, not a finished shape. Copy the closest one, rewrite the first block for yourself, and over the course of a month add whatever you find yourself correcting most often.

Manager

WHO I AM
I lead a team of [number] people in [field]. I handle planning,
budgets, client communication, and decisions that affect deadlines.
I understand [areas I'm strong in]; explain [area] to me in more
detail.

HOW I WANT ANSWERS
- Recommendation or direct answer first, reasoning only after.
- Broken into bullet points, seven maximum.
- When comparing options, give a table with criteria, not
  paragraphs.
- For every recommendation, give one main reason and one main risk.
- Time and cost estimates always come with what they're based on.

TONE
- Talk like an experienced colleague, not like an assistant. No
  polite opening lines.
- If you think my intent is wrong, say so in the first sentence.
- Keep it in plain English; leave technical terms in their usual
  form when that's standard in the field.

WHAT TO NEVER DO
- Don't open the answer by praising my question.
- Don't offer further steps at the end that I didn't ask for.
- Don't add a summary for answers shorter than ten lines.
- Don't use emoji.
- When you're not sure of a fact or a number, say so instead of
  guessing.

WHEN YOU'RE MISSING INFORMATION
Ask about the single most important thing you're missing, rather
than writing an answer with five assumptions baked in. For small
things, make an assumption but flag it at the start of the answer.

The rule about leading with a recommendation does the most work in this set — without it, you get an analysis you have to extract a conclusion from yourself. The rule about estimates is a safeguard: the model produces estimates readily and without backing, and “what you're basing it on” surfaces them.

Student

WHO I AM
I'm studying [field] at [type of school], in [year]. I mainly use
you to understand material, prepare for exams, and work through
technical texts.

HOW I WANT ANSWERS
- Explain from the ground up, but without needlessly repeating
  what I've already said I understand.
- For a new concept: a one-sentence definition first, then an
  example, then a common misconception.
- Answers broken up, with key terms bolded.
- When material is sequential, give it as steps, not continuous
  text.

TONE
- Write like a tutor who doesn't go easy on me. If I get something
  wrong, say so directly and explain why.
- Don't approve of my phrasing just because it's mine.

WHAT TO NEVER DO
- Don't write whole assignments, papers, or answers for me to turn
  in. If I ask for that, give me an outline and questions to answer
  myself instead of the text.
- Don't make up citations, authors, or dates. If you're not sure,
  say so.
- Don't use phrases like “that's a great question.”

HOW TO TEACH ME
After a longer explanation, ask me two to three check questions
and wait for my answer before continuing.

The “don't write assignments for me” block is deliberately there as a ban aimed at myself — a safeguard against the easiest thing to slip into, and it also makes the model a better teacher. The last block pays off more than you'd expect: active recall is the most effective way to learn, and this forces it automatically.

Freelancer

WHO I AM
I'm a freelance [profession]. I have [number] active clients and
handle proposals, invoicing, communication, and my own marketing
myself. Time is my only raw material.

HOW I WANT ANSWERS
- Short and usable. For written content, a ready-to-use draft
  right away, not a description of how I should write it.
- For email or message drafts: just the text, no commentary around
  it.
- When it's a decision, give two options and recommend one.

TONE
- Businesslike, no corporate phrases and no superlatives.
- Client communication: polite, but no groveling and no apologizing
  for things that aren't on me.

WHAT TO NEVER DO
- Don't write promises, deadlines, or prices into client texts that
  I didn't give you.
- Don't send anything on my behalf and don't mark anything as final
  — always just prepare a draft, I send it myself.
- Don't use emoji in client communication.
- When you're not sure of a fact or a number, say so instead of
  guessing.

WHEN YOU'RE MISSING INFORMATION
For client-facing text, ask, don't guess. For internal notes, make
an assumption and flag it in square brackets.

The rule about promises and prices is the key one. The model tends to add an accommodating line to an email like “of course we'll have it done by end of week” that you never said — and once it's sent, it's a commitment. And a rule that sits above every instruction applies here too: AI proposes, a person approves. Sending, confirming an order, or invoicing stays with you.

Developer

WHO I AM
I develop in [languages/stack]. I work on [type of project].
Experience level: [junior / senior] — [what I understand well,
what's new to me].

HOW I WANT ANSWERS
- Solution first, explanation after. Not the other way around.
- Code as a whole block, not in fragments I have to assemble
  myself.
- For changes to existing code, show only the affected parts and
  say where they go.
- A short comment only where the WHY isn't obvious; don't comment
  on what's visible from the code itself.
- If a simpler solution exists without adding a dependency,
  suggest it.

TONE
- Direct, technical, no hedging.
- If my approach is wrong, say so right away and explain why.

WHAT TO NEVER DO
- Don't make up functions, parameters, or libraries. If you're not
  sure an API exists in that exact form, say so.
- Don't apologize and don't mention that you're a language model.
- Don't rewrite code I didn't ask you to touch, and don't change
  formatting style.
- Don't suggest commands that delete data or rewrite history
  without explicitly warning me what they'll do.

WHEN YOU'RE MISSING INFORMATION
Ask about the language version, framework, or project structure
instead of assuming. For small things, state the assumption up
front.

The ban on inventing APIs is the single most important line here: the model fills in functions and parameters with complete confidence, and you only find out when you run it. The rule about deleting data follows the same logic as everywhere else on this site — a destructive step needs approval from a person who knows what they're doing. Don't put rules specific to one repo or one team's conventions into your personal instructions; those belong to a project, not to you.

Phase 5: how to test instructions

Written instructions aren't the same as working instructions. Models hold onto some rules reliably and ignore others, and you won't know which is which without testing — you'll just have a vague feeling that “something's not working.”

Testing with the same request

The simplest test takes five minutes. Take three typical requests from your work and run them in a new conversation. Track one thing only: how many corrections you had to add. Zero to one means the instructions fit. Three or more means whatever you're correcting is missing from the instructions, or written so vaguely it can't be followed.

Then run the same three again in a month. If the corrections come back, something changed — either your work shifted, or the model's version did.

A more precise version has the answer checked rule by rule:

Here are my custom instructions:

[paste the instructions]

Here's an answer I got for the request “[brief description of the
request]”:

[paste the answer]

Go through the instructions rule by rule and, for each, write:
FOLLOWED / VIOLATED / DIDN'T APPLY — and for violated ones, cite
the specific place in the answer where it happened.

Then answer two questions:
1. Which rule couldn't apply to this answer because it's written
   for a situation that didn't come up here?
2. If everything had to be followed at once, would any two rules
   contradict each other? Which ones?

Don't judge the quality of the answer, just how well it matches
the instructions.

It returns a table that, for the first time, shows which rules actually work. A typical finding: half the rules come back “didn't apply,” because they're written for situations that almost never come up — and those belong elsewhere, or gone, or in a Project. The last line is there so the model doesn't drift into praising the output instead of checking it.

Diagnosing why a rule isn't sticking

When you get the sense the model is ignoring a rule, ask about it directly in the conversation where it happened:

Here's what I have in my custom instructions:

[paste the instructions]

In this conversation you [describe what you did differently — e.g.
wrote a long paragraph instead of bullets, opened with a pleasantry].

Answer me honestly and without apologizing:
1. Which rule from the instructions did this violate — quote it
   exactly.
2. Why do you think it happened: is the rule ambiguous, does it
   conflict with another one, or did something in my request
   conflict with it?
3. How could that rule be rewritten to be unambiguously
   followable — give a concrete replacement phrasing.
4. Is there another pair of rules in my instructions that
   contradicts each other? List them.

Don't rewrite the whole set of instructions, just the affected
rules.

Point 2 often surfaces a conflict you didn't know you had — typically “be concise” versus “always explain why you're recommending it.” Treat the answer as a hypothesis, not a diagnosis: the model doesn't actually know why it made the choice it made, and its explanation is a reconstruction. Point 3, the concrete rephrasing, is the genuinely useful part.

Building instructions from what you correct

The best source material for instructions isn't templates from the internet, it's your own corrections. Collect a week's worth of every follow-up message you used to fix an answer, and have them turned into rules:

These are corrections I had to write over the past week after AI
answers. I collected them across different conversations:

[paste the list — e.g. “shorter,” “no intro,” “put it in a table,”
“I don't want options, I want a recommendation,” “explain it more
simply”]

My work: [two sentences on what you do and what you use AI for].

Turn this into custom instructions:
1. Group corrections that say the same thing, and turn each group
   into one rule — specific and checkable, not general.
2. Sort the rules into blocks: who I am, format, tone, bans, what
   to do when information is missing.
3. Drop anything that only showed up once and doesn't look like a
   pattern.
4. Flag rules that might collide with each other.
5. Keep it under 250 words. If it doesn't fit, tell me what you cut
   and why.

Write the rules as commands, not descriptions.

It returns a set that, unlike a template, is actually yours. The word limit in point 5 is deliberate: instructions have a tendency to grow into a full page, and long rules get followed less reliably than short ones. Read point 5's answer carefully — it occasionally drops a rule that only showed up once but mattered.

Trimming when it's gotten too long

These are my custom instructions, which have grown too long:

[paste the instructions]

Cut them in half by these priorities:
1. Keep all the bans — they work best.
2. Keep the format rules I can describe with numbers.
3. Drop general phrases that can't be checked (“be helpful,” “try
   to understand context”).
4. Merge rules that say the same thing in different words.
5. Cut the role description to three sentences, but keep whatever
   affects the level of explanation.

Don't change the wording you keep — only cut and merge.
At the end, list what you cut, so I can confirm I don't miss it.

The last two lines are the whole trick. Without a ban on rephrasing, you get a more elegant but weaker text; without a list of what got cut, you won't notice a rule disappeared that once took you three tries to figure out.

Phase 6: quarterly maintenance

Instructions aren't a setting, they're a living document. Your work changes, model versions change — and a rule that was necessary a year ago might be pointless today, because the behavior it was aimed at doesn't show up anymore.

The routine takes twenty minutes, four times a year. Put it on your calendar as a recurring event, or you'll never do it.

Go through four questions. What did I correct most often over the last quarter? That goes in. Which rule is sitting there, and I can't remember the last time it changed anything? That goes out. Did my work change? A new role, a new type of output, a new field means rewriting the first block. Did anything move to a Project? Rules specific to one area belong a layer down.

These are my custom instructions, which I've been using for
[how long]:

[paste the instructions]

Here's what's changed in my work over the last quarter:
[what's new — role, type of tasks, tools, areas]

And here's what I've had to repeatedly correct in answers:
[list of corrections]

Do a review:
1. Which rules no longer match what I actually do today.
2. What's missing from my instructions, based on my corrections —
   suggest a specific phrasing to add.
3. Which rules are written so vaguely they can't be followed, and
   how to rewrite them.
4. What should move to a Project instead of staying in
   instructions.
5. Return the final version of the instructions, no longer than
   the original.

For point 5, highlight what changed compared to my version.

The length limit in point 5 is there because a review should keep instructions in balance, not inflate them. Don't save the result blindly — read the changes and drop anything you don't understand. Instructions you don't understand are worse than none, because you don't know what's shaping the answers.

One more thing for your calendar: after a major model update, rerun your three-request test. Behavior shifts with new versions, and some old rules turn out unnecessary because the model now does the right thing on its own.

Common mistakes

• Writing too generally. “Answer concisely and well” does almost nothing. A specific rule (“seven bullets maximum, recommendation first”) can actually be followed and checked.
• Putting variable context into instructions. Current project, client, deadline — two months later it's a falsehood the model keeps assuming, and you won't know why.
• Bloating instructions into a full page. The longer the set, the weaker each individual rule. Stay around two to three hundred words and move the rest to a Project.
• Having contradictory rules in instructions. “Be concise” and “always list every alternative” cancel out; the model picks one and you won't know why.
• Writing them once and never revisiting. Work changes and so do models. Without a quarterly review, a year from now you have a set shaping answers based on who you used to be.
• Storing sensitive data. Instructions go out with every conversation, including the most trivial one. Client names, numbers, and personal data don't belong in them.

The best tools

• Custom instructions in account settings (ChatGPT, Claude, Gemini) — the one place applied to every new conversation; role, format, tone, and bans belong here.
• Projects — the second layer, for rules and reference material that only apply to one area of work, one client, or one type of output.
• A prompt library — the third layer, for requests that recur; instructions describe you, a prompt describes the task.
• A recurring calendar event — twenty minutes, four times a year, for a review; maintenance doesn't happen without a reminder.
• Separate profiles or accounts for work and personal use — when your two worlds differ a lot, two clean sets of instructions beat one compromise set.

What you get out of it

• Time: for someone who opens ten or more conversations a day, expect roughly ten to twenty minutes a day saved on fixing the first answer.
• Money: a shorter path to a usable output means fewer attempts; on paid accounts that also shows up in usage against your limits.
• Peace of mind: you don't have to re-explain who you are and what you want every time — and, above all, you don't have to read answers written in a style that doesn't fit you.
• Quality: the rule about uncertainty and missing information surfaces spots where the model would otherwise quietly guess; that's the difference between an answer you can trust and one that just looks good.

Pro tip

An advanced trick: write your instructions in two layers — a fixed core and an experimental addendum. The core is what's proven itself and you leave alone. The addendum is two or three rules you're currently trying out, separated by a line and dated. If a month later the addendum hasn't changed anything, delete it without a second thought; if it works, fold it into the core. Without this separation, instructions only ever grow and nobody ever trims them.

And one closing rule: instructions change the form of an answer, not who's responsible for it. No matter how good your setup, sending the email, approving the proposal, confirming the payment, and deleting anything remains a person's job. Good instructions save you the first two messages — keep the last click for yourself.