A Context Brief Template That Re-Briefs Any AI in One Paste

Most people who complain that an AI forgets context between conversations are not asking for a cleverer model. They are asking not to spend the first ten minutes of every chat explaining who they are, what they are working on and what they have already decided. Search data shows the complaint in many forms: AI forgets context between conversations, AI that forgets conversations, AI forgetting previous solutions. The underlying need is the same in all of them.

The most reliable fix does not depend on any product's memory feature. It is a short document you write once, keep current, and paste at the start of a new conversation. This post gives you a template for that document, explains what each section is for, and shows how to keep it short enough to be useful. It works in ChatGPT, Claude, Gemini, Perplexity or anything else that accepts text.

Why a Brief Beats Built-In Memory for Real Work

Built-in memory features are useful for small, stable facts, and they are improving. They also have limits that matter when you are doing sustained work.

You do not control what is kept. Cross-chat memory is a selection made by the product. Stable facts tend to survive; reasons, rejected options and the state of unfinished work tend not to. Those are precisely the things you need to continue a task.

You cannot always see what is used. Even when a detail has been stored, whether it is brought into a particular answer depends on whether the product judges it relevant to your question.

It does not travel. Memory in one assistant does nothing for a conversation in another. If you use more than one, each starts from what it alone has seen.

It goes stale quietly. Old preferences and finished projects can keep shaping answers long after they stop being true.

A brief you write has none of these problems. It contains exactly what you put in it, the model sees all of it at the start of the conversation, it pastes into any assistant, and it is as current as your last edit. The trade-off is that you maintain it, which takes a few minutes a week. Why assistants lose context in the first place is explained in Why AI Keeps Forgetting You.

The Template

Copy this structure into a plain text file or note. Each heading is a short section; most sections are a handful of lines.

1. Who I am and how I work. Two to four lines. Your role, the field you work in, the tools you use daily, and anything that changes how answers should be pitched, such as your level of expertise.

2. How I want answers. Three to six lines. Length, format, tone, spelling conventions, whether you want options or a single recommendation, whether code should be complete files or minimal diffs.

3. The project. Two or three lines. What you are working on and what success looks like.

4. Decisions already made. One line each. The choices that are settled and should not be reopened.

5. Ruled out, and why. One line each, with the reason in a few words. This section is what stops a new conversation from enthusiastically proposing something you rejected last week.

6. Hard constraints. One line each. The things whose violation makes an answer useless: budget, deadlines, required versions, legal or style rules.

7. Key facts and values. Names, numbers, versions, dates and terms that must be exact. If it matters that it is precisely right, it belongs here.

8. Current state and next step. Two or three lines. Where you stopped, what is half-finished, and what you want to do in this conversation.

9. Opening request. One line telling the assistant what to do first, for example to confirm it has understood the constraints before starting.

That is the whole template. Sections one and two change rarely. Sections three to seven change as the project moves. Section eight changes every session.

What Each Section Prevents

It helps to know what each part is for, because that tells you what to put in it and what to leave out.

Who I am prevents answers pitched at the wrong level. Without it, an assistant either over-explains basics you know or assumes knowledge you lack.

How I want answers prevents the formatting tug-of-war at the start of every chat: the bullet points you did not want, the essay when you asked for a line.

The project gives every later section a frame. A decision or constraint means little without knowing what it is a decision about.

Decisions already made prevents re-litigation. Assistants have no way of knowing a question is closed unless told.

Ruled out, and why is the section people skip and most need. A bare list of rejected ideas is weaker than it looks, because the assistant may suggest a close variant. The reason lets it rule out the variants too: if you rejected a database because it lacked a feature you need, it will not propose a similar one with the same gap.

Hard constraints prevents answers that are good in general but wrong for you.

Key facts and values prevents the subtle errors: the version number that is one off, the name spelled slightly differently, the deadline remembered as the wrong week.

Current state prevents the conversation starting from the beginning of a task you are halfway through.

Opening request turns the brief into an action and gives you an immediate check that it was read properly.

A Short Worked Example

Here is how a filled-in brief might look for someone writing a technical guide. It is invented for illustration.

Who I am: Freelance technical writer. Comfortable with command-line tools and basic scripting; not a professional developer.

How I want answers: British spelling. Plain prose, short paragraphs, no marketing tone. Give one recommendation with a brief reason rather than a menu of options.

Project: A beginner's guide to backing up a home computer, about five thousand words, for a general audience.

Decided: Structure is problem, options, recommended setup, maintenance. Examples use a laptop with one external drive.

Ruled out: Covering network storage in depth, because it doubles the length for a minority of readers. Recommending specific paid services, because prices change and the guide should not date.

Constraints: No step may require installing developer tools. Every instruction must work without an account on any service.

Key facts: Working title is "Back Up Your Computer in an Afternoon". Draft due on the fifteenth.

Current state: Sections one and two drafted. Starting section three, the recommended setup.

Opening request: Confirm the constraints in one line, then outline section three.

That is under two hundred words, and it gives a new conversation everything it needs to be useful from the first reply.

Keeping It Short

A brief that grows to several pages stops working. Long briefs bury the important lines, use up space the conversation needs, and stop being maintained because editing them is a chore.

Some rules that keep it lean:

• Record conclusions, not history. "We chose X because Y" belongs. The account of how you got there does not.
• One line per item. If a decision needs a paragraph to state, it probably needs to be broken down or simplified.
• Delete what no longer applies. Finished work, superseded decisions and constraints that have been lifted should go, not be crossed out.
• Aim for a page or less. Most work fits in three hundred to five hundred words. If yours is longer, look for history masquerading as context.

If you work on several projects, keep sections one and two as a shared core and write a separate short project brief for each, rather than one large document covering everything. You paste the core plus the relevant project brief. This is the same pattern that works for keeping context consistent across separate workspaces, described in How to Share Context Between Claude Projects.

Using It at the Start of a Chat

The routine is simple.

1. Open a new conversation.
2. Paste the brief as the first message, ending with the opening request.
3. Read the reply. If you asked it to confirm the constraints, check that it did so correctly. If something is wrong or missing, correct it now rather than ten messages later.
4. Work as normal.

Some assistants let you store standing instructions or attach documents to a workspace, such as custom instructions in ChatGPT or project instructions in Claude. Sections one and two are good candidates for those, because they rarely change and you want them applied every time. Keep the project sections in the pasted brief, because they change often and you want to see the current version each time.

Pasting has one practical advantage over stored instructions: you see exactly what the model was given. When an answer goes wrong, you can check the brief rather than wondering what the assistant had access to.

Updating It at the End of a Session

The brief is only as good as its last update. The update takes two or three minutes at the end of a session, and it is the step people skip.

Before you close a conversation that moved the work forward:

• Add any new decisions to section four.
• Add anything you rejected, with the reason, to section five.
• Add or correct any exact values in section seven.
• Rewrite section eight to say where you stopped and what is next.

You can ask the assistant to draft these updates from the conversation. Read them before saving, particularly after a long conversation, where the model may have lost early detail. A wrong entry in the brief is worse than a missing one, because it will be applied confidently in every future chat.

Done consistently, this turns every session into a small improvement to a document that stays current, rather than a long transcript that nobody will reread. Approaches to keeping the transcripts themselves, for the times you do need them, are in How to Back Up AI Conversations.

Common Mistakes

Writing it once and never updating it. A stale brief is a source of confident wrong answers.

Pasting whole documents instead of summarising them. If a long file matters, note the key points in the brief and paste only the section relevant to today's task.

Leaving out the reasons. Decisions without reasons are easy to reopen; rejected options without reasons come back as variants.

Mixing preferences and project facts. Keep how you want answers separate from what the project is, so the first can be reused across everything.

Trusting a draft without reading it. Assistant-written updates are convenient and sometimes wrong.

Where MindLock Fits

Maintaining a brief by hand works well and costs nothing. MindLock is for people who want help building and finding that context from conversations they have already had.

You save conversations you want to keep, by pressing Ctrl or Cmd plus S in ChatGPT, Claude, Gemini or Perplexity and uploading the saved page, or with the one-click Save to Memory button in the Chrome extension, which is loaded unpacked in developer mode rather than installed from a store. Saving is always a manual action. Distillation turns saved conversations into memory documents, a profile memory plus topic memories, which you can read and edit. Semantic search with Ctrl or Cmd plus K finds relevant material across conversations and memories, and context generation packages the relevant memories into a formatted block to paste into a new chat, which is essentially a generated brief. The flow is described in Generating Context.

Memory documents reflect your conversations as of your last distillation and do not update on their own, so the end-of-session habit still matters: save what moved the work forward and re-run distillation. Free-tier distillation runs locally on your GPU through WebGPU and needs a compatible GPU; the Pro tier distils in the cloud. The differences are on the pricing page.

The Short Version

If your AI forgets context between conversations, stop relying on it to remember and give it what it needs at the start. A one-page brief covering who you are, how you want answers, the project, decisions, rejected options with reasons, hard constraints, exact values and current state will re-brief any assistant in a single paste.

Keep it short, record conclusions rather than history, update it at the end of each session, and read any draft an assistant writes for you before saving it. The brief is the part of your AI work that does not reset when the conversation does.