Ben asked his AI assistant to correct "She don't like cold coffee." While checking the session, he found his long project handbook among the loaded documents. It included code-testing advice and rules for checking company figures in investment questions. Those were his own instructions, written after earlier answers annoyed him. He opened the instruction list again. Why had a grammar correction loaded the investment rules?
The file had started with ordinary preferences. Use simple English and keep a correction close to the original meaning. Then a code change made his script crash on an empty list, so Ben added a check for that. An investment answer called a company's sales its profit. For an afternoon plan, he had walked to a museum that was closed. Each note seemed easier than explaining the same mistake again, so he kept adding them.
He was learning about AI with the same tools he used for programming, including assistants that could read local files. He had an AGENTS.md in one setup and used CLAUDE.md with Claude Code. He had learned the file names while reading about giving an assistant project instructions. In his own entry file, he found a direction to read the handbook before every task. He had been wondering why the assistant carried those notes around when he had told it to do exactly that.
Ben opened the loading documentation beside that line. A tool could load instructions when a session started, then keep that text available as the conversation continued. It did not have to reopen every file from disk for the text to remain part of later model input. The loading details depended on the tool. He checked its context, the text available to the model. Counting file reads would not tell him the full size of that context.
He looked at the cost explanation too. Tokens were the pieces of text a model processed, and a longer instruction pack could add input tokens. Providers could charge less for reused, cached input. A subscription could have its own usage rules. Generating the answer also used tokens, so a raw input count would not give him an exact bill. Ben put the pricing page aside and kept working on the text he could control.
As a programmer, he reached for an if statement. Above the grammar section he wrote that the rules applied only to writing tasks. Above the code section he wrote that they applied only to code changes. He added an instruction to skip everything else. It looked sensible enough that he almost closed the file and went back to work.
Then he read his own proposed fix. All the detailed rules were still underneath those conditions, inside the same loaded document. The assistant had to receive the text before it could decide which part applied. A sentence saying "skip this section" did not pull that section out of the input. Ben highlighted the condition and the pages below it. They would all be sent together.
He searched for how people handled this and found the term progressive disclosure. It meant showing the small amount needed to choose a task, then providing the details when they were needed. OpenAI's guidance on instruction files and skills described this kind of selective reading. Ben recognized the idea from programs that loaded a module when they needed it. He created a folder beside the handbook.
Grammar and word choice went into rules/writing.md. Code changes went into rules/code.md, and the everyday planning notes moved to rules/everyday.md. He put the guidance for investment questions, including how to check company figures, in rules/investing.md. He could finally find the writing instructions without scrolling past the code checks.
The short entry file told the assistant which file to read. For writing or grammar, read the writing file before answering. For code changes, read the code file. It also named the everyday and investment files and said when to use them. These were ordinary file paths, with no command to read the whole folder first. If the task needed nothing special, the assistant could answer using the basic rules.
When setting up the Claude Code version, Ben began adding @ before the paths in CLAUDE.md. He stopped at the import documentation. These imports would load their contents with the entry file. He removed the marks and kept the paths as ordinary references, with a direction to read the matching file before doing the task.
A few rules stayed in the entry file. Private information should stay out of shared examples. The assistant should not claim to have run a check it had not run. Those applied across his tasks, so he kept them where the assistant would receive them at the start.
Ben started a fresh session and repeated the grammar request. This time the file-read record showed the writing file, with none of the other topic files opened. The reply was "She doesn't like cold coffee." He checked that it had corrected the verb without inventing anything about the coffee. He had a useful result to keep, but wanted a way to compare the amount of text without guessing at a bill.
Ben's next request combined two tasks. He used a practice sentence, "The company's revenue are higher, so its profit must be higher too," and asked for grammar and fact checking. The assistant changed "are" to "is" but left the profit claim in place. It had read only the writing file. Ben went back to his entry instructions. His categories had looked separate on disk, and he had written the decision as though every task must belong to one of them.
He changed that direction to allow every relevant topic file and repeated the request with both paths named. The writing file covered the wording, while the investment file kept revenue separate from profit. Higher sales alone would not prove higher profit without knowing the costs. He still needed the original company report to check any actual figures. Ben saved the mixed request beside the grammar request so he could try both after changing his entry file.
He also added a case that just said "Check this report." That could mean proofreading, checking the figures or both. If the difference affected the answer, the assistant needed a short clarification. The missed topic had given Ben a reason to inspect file reads as well as the final wording. For a task he cared about, he could state the required paths himself.
Ben considered making his writing routine a skill. The assistant could first see its short name and description, then load the detailed instructions when it used the skill. He would still need to check that its description led to the right tasks. With the ordinary reference files already open on his screen, he chose to keep testing those before changing the setup again.
Later, Ben switched from writing to a code question in the same conversation. The writing rules had already entered its context. Changing the subject did not itself remove that text. A fresh conversation or the tool's context-management features could change what remained, with their own limits. For the code task, he started a fresh session with a short description of the bug.
Ben copied "She doesn't like cold coffee" into his draft. He deleted the older version of the sentence and went back to the rest of the paragraph. The mixed request stayed in his checklist for the next time he changed the rules.
The downloadable rule-file example follows the layout in this fictional story. It contains the entry file and topic rules, plus a script to compare their text sizes. Its checklist has expected topic choices we wrote ourselves, for readers to try with their own tools.
Using the cl100k_base tokenizer, the script counts 772 tokens for the sample with every topic file and 331 with only the writing file. The same request and entry text are included in both, giving a difference of 441 tokens. These local counts exclude tool overhead, conversation history and replies. The script makes no model calls. It compares the saved text sizes and does not measure a Claude bill or how well an assistant follows instructions.