Most people use Claude Code by gradually adding every insight and problem they have ever encountered to a single instruction file. After six months, they have three hundred lines of rules that contradict one another, and the model behaves worse than it did at the beginning. This guide takes a different approach. First, you will separate what should be loaded every time, what should be loaded only in a specific situation, and what should run automatically. Then you will review your existing instructions and discard most of them.
Step 1: Categorize commands by when they run
The difference between an instruction file, a skill, and an automatic trigger lies not in the content but in the timing. Claude reads the instruction file at the beginning of every conversation, even before you type the first word. It works like custom instructions in ChatGPT. You create it with a single initialization command, after which the model writes the first version itself and you then edit it. You can have a personal file as well as one for each project, with both being applied together.
A skill is a saved prompt that you have given a name. You write the procedure only once, and next time, instead of a long text, you use one short command in any conversation and any folder. These skills do not consume unnecessary resources, because only the one you invoke is loaded.
An automatic trigger, or hook, is tied to a specific event. While a rule in an instruction file is merely a request, a hook is a command that runs regardless of the model’s current settings. A useful decision-making rule says that anything you define by saying the model must always do it or, conversely, must never do it belongs in a hook. By contrast, anything that begins by saying that you prefer a specific procedure for a certain type of work belongs in a separate skill.
Step 2: Keep the main file concise
Anthropic has published a recommendation that many users have never heard of. It advises keeping each instruction file under two hundred lines, because longer text consumes more context and the model follows it less consistently. Some people manage with as few as sixty lines.
There is a simple test for every line. If this instruction disappeared, would Claude start making mistakes? If not, remove the line. A file loaded in every conversation should contain only things applicable across all your work, because instructions for one specific database will only distract you when writing text. Also remove code-formatting requirements that a linting tool can handle for you, as well as common language conventions that the model already knows.
Use the imperative, because the model will follow “use this library” better than “we generally prefer this one when possible.” Structure helps the model just as it helps people, so headings and bullet points work better than a dense paragraph. Put anything longer elsewhere. Separate rule files that specify paths in their headers are loaded only when Claude accesses the corresponding files. Without that header, however, they are pulled into every conversation just like the main instructions.
Step 3: Audit what you already have
First, check which model version you are actually using, because generations change, and so do the practices that benefit them. Some versions require concise instructions, others detailed ones, while examples help some and hinder others. Then have the model review your instructions line by line, but with one condition. It must first load Anthropic’s current documentation as well as the page for the specific model you use, and assess the text according to those sources rather than its memorized knowledge. There can be only three verdicts: delete, keep, or rewrite. For every deletion, the model must provide the exact sentence from the documentation that justifies the decision; if it cannot find one, the line remains in the instructions.
You must also remove things that appear useful at first glance. Instructions telling the model to always check its own result force it to do the work twice, which also means you pay twice. Asking it to report only important information then causes you to receive less information than you originally wanted. Prohibitions against lengthy reasoning, in turn, cause internal system tags to leak into the response. If you tell the model at the outset that it is an expert with twenty years of experience and should write accordingly, that usually adds nothing today. Moreover, examples written for an older version teach outdated habits, so one current example can reliably replace ten outdated ones.
However, do not touch one thing. An instruction telling the model to state only what it has verified is not a filter for importance; it prevents facts from being fabricated and must therefore remain under all circumstances.
For skills, look for overlap rather than the total number. Have them grouped according to the activity they perform rather than by name, because two differently named skills often do the same thing. Separately list those you have never used and those that refer to a folder that no longer exists.
Step 4: Build your first hook
The simplest hook looks like this. When I type the word LinkedIn, it creates a post for that network. The word acts as the trigger, while the actual work remains in the skill. Before you begin, determine what you actually repeat. Have Claude review your recent conversations and find things you keep requesting in the same words. Look for situations where you had to tell it something it already knew, or cases where you had to correct it more than once. For each one, you want three pieces of information. Determine which phrase you use, what Claude should read at that point, and whether the word is unusual enough not to be triggered accidentally. The last point is where things most often fail. Phrases such as “show me” appear a hundred times in ordinary conversation, so the hook will run at an unwanted moment.
Technically, a hook receives structured data as input and responds with a return code. Zero means that everything is fine. Two blocks the action and returns an error message to the model. One, the standard Unix failure code, does not block anything at all. Almost everyone gets stuck on this, while hooks intended to prohibit an action must exit with two.
It is also worth remembering that when a conversation starts and after a message is sent, a hook’s plain-text output is inserted directly into the model’s context. Without any complexity, you can therefore add, for example, the last ten code changes to the context.
Once you have multiple hooks, review them and identify those that run with every message. These hooks cost you the most, so they either need to justify their existence or must be removed.
Step 5: Maintain what you have built
The goal is for the main file itself not to contain detailed knowledge. It should only briefly describe your identity and writing style and otherwise merely point to the locations of other files. A word in your message triggers a hook, which retrieves the project file for the relevant task, and that file then points to a specific skill. An eight-hundred-line file about infographics will thus never enter a conversation about text.
This structure will not maintain itself. When two instructions conflict, Claude chooses one and does not tell you which one. Periodically reviewing all instruction files is therefore the only defense. It also helps to add this rule directly to the instructions. If you encounter an incorrect assumption while working, suggest a correction to the rules. And if I ask you for the same thing three times in one conversation, point it out and suggest turning it into a hook.
The rest is conversation hygiene. A new task deserves a new conversation. Condensing the history may maintain momentum at the cost of losing details, but clearing it completely and providing a short new prompt gives you greater control over the information being carried over, even though it requires more work. Before deleting anything, have the entire settings folder backed up, approve the plan, and only then confirm the action.
Sources: claude.com, claude.com, claude.com and claude.com
