TL;DR: The gap between people who get good output from AI tools and people who get generic output is mostly not prompt skill. It is standing context. Pew Research Center found in a survey of 5,119 US adults fielded 17-23 February 2026 that 49% of American adults now use AI chatbots, up from 33% in 2024, and that 38% of employed adults use them for tasks at work. Nearly all of those people are starting from zero context every session. The fix is a single document, written once, pasted or loaded into the settings layer of whichever tool you use. The structure is not guesswork: OpenAI’s prompt engineering guide specifies a developer message built from Identity, Instructions, Examples and Context; Google’s official guidance for custom Gems specifies Persona, Task, Context and Format; Anthropic’s Claude Code documentation describes CLAUDE.md as the place to write “what you’d otherwise re-explain” and targets under 200 lines. Three vendors, three product lines, one skeleton. Below: the convergence table, the published size limits, a seven-block Context File with a thirty-minute time budget that sums exactly, where the file goes in each tool, and the four categories you should keep out of it.
There is a specific and slightly annoying experience that almost everyone who uses AI tools seriously has had. A colleague shows you their output. It is sharper than yours. You ask what they typed. They show you the prompt, and it is worse than yours. Shorter, vaguer, less careful.
The prompt was not the variable. What the model already knew about them was.
The missing variable is standing context, not prompt wording
Every conversation with a language model begins from a defined starting state. Whatever the tool has been told about you before your first message is in that state. Whatever it has not been told is absent, and the model fills the absence the only way it can: with the statistical average of everyone.
That is why generic input produces generic output. The model is not being lazy. It is being asked to write for a reader it has never met, in a voice it has never heard, about work it cannot see.
Anthropic’s own prompting documentation puts the situation in a sentence worth keeping: think of the model as a brilliant but new employee who lacks context on your norms and workflows. The same page offers what it calls the golden rule, which is to show your prompt to a colleague with minimal context on the task and ask them to follow it. If they would be confused, the model will be too.
Notice what that test actually implies. It is not a test of your prompt. It is a test of how much shared context you are assuming. A brilliant new employee does not need better instructions on day 30 than on day 1. They need the thirty days.
The Context File is those thirty days, compressed into thirty minutes.
OpenAI’s Model Spec, the published document describing intended model behaviour, contains an unusually clean illustration of the mechanism. In a worked example, a user asks who is on the roster of “the giants.” Without context, the compliant behaviour is to ask which Giants: baseball in San Francisco, football in New York, or the Yomiuri Giants in Japan. With memory context indicating the user is a San Francisco Giants fan, the compliant behaviour is to answer directly. Same question, same model, different starting state, different quality of experience. Multiply that by every ambiguous term in your professional vocabulary and you have the whole argument.
Three vendors independently converged on the same skeleton
Here is the part most discussion of this topic misses. The structure of a good context document is not an open question that each writer has to solve from scratch. Three major vendors publish guidance on it, in three different products, and the guidance overlaps almost completely.
Table 1. Verified vendor guidance on structuring standing context (from official OpenAI, Google and Anthropic documentation, retrieved August 2026)
| Vendor and document | Named structure | Notable stated detail |
|---|---|---|
| OpenAI, Prompt engineering guide, developer message | Identity, Instructions, Examples, Context | Context “is usually best positioned near the end of your prompt”; the instructions parameter takes priority over the user prompt |
| Google, Gemini Apps Help, Tips for creating custom Gems | Persona, Task, Context, Format | “You don’t need to use all four, but using a few will help”; files can be uploaded to give a Gem more context |
| Anthropic, Claude Code documentation, CLAUDE.md | Not a fixed four-part schema; described as the place to record what you would otherwise re-explain | Loaded into context at the start of every session; target under 200 lines; specificity beats vagueness (“Use 2-space indentation” over “Format code properly”) |
Line up the columns and the shared skeleton is obvious. OpenAI’s Identity is Google’s Persona. OpenAI’s Instructions is Google’s Task plus Format. Both name Context as its own block. Anthropic does not impose a schema, but its worked guidance points at the same content: conventions, commands, layout, and always-do-X rules.
That convergence is the useful finding. When three companies with different products, different incentives and different documentation teams arrive at the same four buckets, the buckets are probably not arbitrary.
Table 2. Verified published limits and mechanics for standing-context files (Anthropic, Claude Code documentation, retrieved August 2026)
| Mechanic | Published specification |
|---|---|
| Recommended size of a project instruction file | Under 200 lines; “longer files consume more context and reduce adherence” |
| Hard file size behaviour | A file up to 4 MiB is loaded in full; a larger file is skipped entirely |
| Automatic memory index load | First 200 lines or first 25 KB of the index, whichever comes first |
| Import depth for referenced files | @path imports resolve recursively to a maximum depth of four hops |
| Scope order, broadest to most specific | Managed policy, then user, then project, then local; all concatenated rather than overriding |
| Enforcement status | Instructions are context, not enforced configuration; “there’s no guarantee of strict compliance” |
Two of those specifications are worth pausing on, because they overturn the instinct most people have.
The first is that longer is worse. The documentation is explicit that a longer file reduces adherence. This is not a storage constraint, it is an attention constraint, and it applies to a pasted context block in a chat window just as much as to a file on disk. The temptation, once you accept that context helps, is to write four pages. Four pages will underperform half a page.
The second is that none of this is enforcement. The vendor documentation says so directly: instructions are context, not enforced configuration. A Context File makes good output much more likely. It does not make bad output impossible. That distinction matters for how much you rely on it, which is the subject of trust calibration and when to trust an AI recommendation.
The Context File: seven blocks, thirty minutes
Here is the original framework. It takes the four buckets the vendors agree on, adds the three that professional work needs and consumer chat does not, and assigns each a time budget. The budget is deliberately tight, because the failure mode of this exercise is not writing too little. It is spending an afternoon writing a document you never update.
Table 3. The Context File: seven blocks with time budget and target length (CEOtudent editorial framework)
| # | Block | The question it answers | Minutes | Target length |
|---|---|---|---|---|
| 1 | Identity | Who am I, what is my role, what organisation or practice am I part of? | 4 | 3-5 lines |
| 2 | Audience | Who reads or receives what I produce, and what do they already know? | 4 | 3-5 lines |
| 3 | Standards | What does good output look like, and what patterns are banned? | 6 | 6-10 lines |
| 4 | Current work | What am I working on now, with what priorities and deadlines? | 5 | 4-8 lines |
| 5 | Constraints | What is off-limits: confidential material, tools I cannot use, claims I cannot make? | 4 | 3-6 lines |
| 6 | Vocabulary | Which terms, names and spellings does the model routinely get wrong in my domain? | 4 | 5-10 lines |
| 7 | Examples pointer | Where are two samples of my actual good output? | 3 | 2-3 lines |
| Total | 30 | 26-47 lines |
The total is thirty minutes and the file lands comfortably under the 200-line guidance in Table 2, with room to grow.
A few notes on the blocks that people get wrong.
Block 3, Standards, gets the largest budget for a reason. It is the only block that encodes taste, and taste is the thing a model cannot infer. Write it as concrete rules, following the specificity principle in the vendor guidance: not “write clearly” but “never open with a rhetorical question”, “no bullet lists longer than five items”, “define an acronym on first use and never again.” Every rule should be checkable by someone who has not read your mind.
Block 6, Vocabulary, is the highest-leverage block per minute and almost nobody writes it. Every profession has terms the model will confidently misuse: an internal product name that collides with a common word, a regulatory term that means something different in your jurisdiction, an acronym with three expansions. Listing ten of them with one-line definitions removes an entire category of confident error. This is the block that pays for the other six.
Block 7, Examples pointer, exploits the strongest documented lever. Both OpenAI’s guide and Google’s Gem guidance treat examples as first-class. Two real samples of your own good output will teach voice more efficiently than any amount of adjectives about voice. If your tool lets you attach files, attach them. If not, paste a short excerpt.
Block 4, Current work, is the block with an expiry date. Everything else is stable for months. This one is stale in weeks, which is why it should be short, dated, and the first thing you look at when the output starts feeling off.
Where the file actually goes
The document is portable. The slot it goes into is not.
Table 4. Verified persistence surfaces for standing context (from official vendor documentation, retrieved August 2026)
| Surface | Documented mechanism | Persistence behaviour |
|---|---|---|
| Claude Code | CLAUDE.md at managed, user (~/.claude/CLAUDE.md), project (./CLAUDE.md) or local (./CLAUDE.local.md) scope |
Loaded into context at the start of every session; all discovered files concatenated in scope order |
| Claude, memory feature | Memory launched 11 September 2025 for Team and Enterprise, expanded to Pro and Max on 23 October 2025 | Memory is scoped separately per project; users can view and edit the memory summary in settings; incognito chats are excluded |
| Google Gemini, custom Gems | Gem instructions written at gemini.google.com under Explore Gems, plus uploaded files for additional context | Applies to conversations with that Gem; Google notes the preview window does not save a Gem, you must click Save |
| OpenAI API, developer message | instructions parameter or developer-role message |
Applies to that request; the instructions parameter takes priority over the user prompt |
| Any chat tool without a settings layer | Paste the file as the first message of a working session | Persists for that conversation only |
The last row is the one that matters most for most readers, and it is worth saying plainly: you do not need a tool with a memory feature for this to work. A Context File pasted as the first message of a session captures most of the benefit. The settings layer only saves you the paste.
One further note from the documentation, because it saves duplicated effort: the ecosystem is converging on a shared file. Claude Code reads CLAUDE.md rather than AGENTS.md, but the documentation gives an explicit interoperability recipe, importing AGENTS.md with an @AGENTS.md line or symlinking one to the other, so multiple agents can read one source of truth. Write the file once. Point everything at it.
The four things to leave out
A Context File fails in predictable ways, and three of the four failures are things people put in that should not be there.
Leave out anything confidential you would not want reproduced. This is the hard rule. A standing context file is loaded into every session by design, which means it is available to be quoted back in every output. Client names, unreleased figures, personal data belonging to other people: none of it belongs in a file whose entire purpose is to be repeated. The vendor documentation offers a useful signal here, in that Anthropic ships an incognito mode specifically so sensitive conversations are excluded from memory. If a category of information needs an incognito mode, it does not belong in a permanent file.
Leave out anything the tool can already see. Anthropic’s documentation on automatic memory notes that the system skips anything it can derive from the codebase, such as architecture or file paths. The principle generalises. If the information is in the document you are about to attach, do not restate it in your standing context. You are spending attention budget to tell the model something it is about to read anyway.
Leave out procedures. A Context File is a description of a standing situation, not a workflow. Multi-step procedures that apply to one kind of task belong in a saved prompt, a template, or a tool-specific skill that loads when relevant. Putting them in standing context means paying for them in every unrelated conversation. The vendor guidance makes the same split explicitly: standing facts in the always-loaded file, task-specific procedures elsewhere.
Leave out contradictions. This is the quiet killer. The documentation warns that if two rules contradict each other, the model may pick one arbitrarily. Files accumulate contradictions the way drawers accumulate cables: one rule written in March, an opposite rule written in July, both still present. Rereading the file in full every time you add to it takes two minutes and prevents the most confusing failure mode there is, which is a file that produces inconsistent output for no visible reason.
Maintenance: the two-trigger rule
The failure mode of this artifact is not that it is badly written. It is that it is written once and abandoned while the work moves on.
Anthropic’s documentation offers a maintenance trigger that transfers cleanly out of software: add to the file when the model makes the same mistake a second time, when you type the same correction you typed last session, or when a new colleague would need the same context to be productive.
Compressed to a rule you will actually follow: write it down the second time you say it. The first time you correct the model, it is a one-off. The second time, it is a missing line in your Context File. That single trigger, applied honestly, keeps the file current with no scheduled maintenance at all.
The second trigger is the dated one. Block 4, Current work, expires. Look at it whenever a month turns over, or whenever output starts feeling subtly off-target for reasons you cannot name. Nine times out of ten the file is describing a project you finished.
The CEO and student read
The CEO half of this is straightforward delegation practice. No competent executive briefs a new hire by shouting the task across the room and hoping. They hand over a context pack: who we are, who we serve, what good looks like, what is off-limits, what we are working on. The Context File is the same artifact for a non-human collaborator, and the reason to write it is the same reason to write the human one, which is that the alternative is re-explaining forever.
The student half is less obvious and more valuable. Writing this document forces you to articulate standards you have never stated out loud. Most professionals cannot answer “what does good output look like in your role” in six concrete, checkable lines. Attempting it is a genuine exercise in self-knowledge, and the difficulty of Block 3 is diagnostic: if you struggle to write your own standards, that is not a problem with the exercise.
There is a related discipline worth naming. This document is the smallest possible entry point into what context engineering is and why it is replacing prompt engineering, which covers the broader skill of managing what a model knows. If you want the wider capability map, prompt engineering is not enough and the AI literacy stack sets out where this sits among the other competences. And when you move from single prompts to standing instructions for autonomous work, how to delegate to an AI agent using a briefing framework and agent literacy and the seven concepts to grasp before delegating work to agents are the next two steps.
Frequently asked questions
How long before I see a difference?
Immediately, in the first session after you load it, and most visibly in tasks with a house style: emails, summaries, drafts in your own voice. The effect is largest where the model was previously guessing at audience and tone.
Is one file enough, or do I need one per project?
Start with one. The vendor documentation shows both patterns coexisting: a broad user-scope file plus narrower project-scope files, concatenated rather than overriding. Split only when you notice a rule that is true for one project and false for another.
Does this work on the free tier of these tools?
The file works anywhere you can type. Persistent settings and memory features vary by plan and product, but pasting the Context File as the first message of a session requires no paid feature at all.
Should I let the AI write my Context File?
It can draft the structure. It cannot supply the content, because the content is precisely what it does not know. A practical middle path is to answer the seven questions in rough notes and have the model compress them into the specificity the vendor guidance recommends.
Will a longer file give better results?
No, and this is the most common mistake. The published guidance targets under 200 lines and states directly that longer files reduce adherence. Length is a cost paid in every session.
Is there a risk in keeping a standing file?
Yes, and it is the confidentiality risk covered above. Standing context is designed to be loaded every time, which means it should contain nothing you would not want quoted back to you or reproduced in an output you share.
Sources
OpenAI, Prompt engineering guide, API documentation, retrieved August 2026.
OpenAI, Model Spec, version dated 11 April 2025.
Google, Gemini Apps Help, Tips for creating custom Gems, retrieved August 2026.
Anthropic, Claude Code documentation, How Claude remembers your project, retrieved August 2026.
Anthropic, Prompting best practices, platform documentation, retrieved August 2026.
Anthropic, Memory announcement, 11 September 2025, with update dated 23 October 2025.
Pew Research Center, Americans and AI 2026: chatbots, smart devices and views on impact, published 17 June 2026, survey of 5,119 US adults fielded 17-23 February 2026.
This content was compiled with the support of AI following in-depth research, then written and prepared for publication by the CEOtudent editorial team.
This post is also available in:
