- Model guidance has three distinct layers—rules, skills, and prompts—and misfiling content causes either bloated agents or missing behavior when instructions don’t load.
- Rules are always-on identity and constraints, paid for every turn, so they should stay small and cover only things you always want applied.
- Oversized rules files raise per-turn cost and can reduce compliance as the model treats subtle instructions as background noise.
- Skills use progressive disclosure: only their name/description is visible by default, and the full instructions load only when the description matches the user’s request.
- Because the description determines whether a skill opens, it must be specific and guessable, and skills are best for procedures that should load only when needed.
Two support requests landed on my desk in the same week. The first was a developer with a 600 line skill that Claude kept ignoring. I opened the folder and found their cursor rules, copied wholesale into a SKILL.md, with a description that read "coding standards for this project." The second was a team that had installed a skill called security and wanted to know why their agent still tried to run a destructive migration against a shared database.
Both problems have the same root. There are three different layers for telling a model how to behave, and each layer has its own cost model. Put content in the wrong layer and you get one of two failure modes: an agent that feels bloated, dragging irrelevant instructions through every turn, or an agent that feels ignorant, missing instructions that exist but never load.
The three layers are rules, skills, and prompts. Rules are who you are. Skills are what you know how to do. Prompts are what you want right now. Most of the confusion I see in client work comes down to content filed under the wrong one.
Layer one: rules, paid for on every turn
Rules are the always-on layer. CLAUDE.md, AGENTS.md, .cursor/rules, system prompts. They load at the start of every session and they never leave. Identity, constraints, conventions, the tech stack, the things you never do.
The cost model is the important part. A rule is paid for on every single turn of every single session, whether it is relevant or not. My own content workspace CLAUDE.md says things like "no em-dashes, use commas" and "short paragraphs, three to four sentences." Those apply to literally everything I write, so paying for them constantly is correct.
That constant tax is also why rules files should stay small. I try to keep mine around a page. When a CLAUDE.md grows past a few hundred lines, two things happen. The per-turn cost climbs, and the model starts treating the file as background noise, following the loud rules and quietly dropping the subtle ones. A 2,000 line rules file does not give you ten times the control of a 200 line one. Usually it gives you less.
The test for whether something is a rule: would I want this applied in a brand new session tomorrow, regardless of what I ask for? Voice, naming conventions, forbidden patterns, where things live in the repo. Yes to all of those. A twelve-step publishing procedure? No, and that is the next layer.
Layer two: skills, cheap to have and expensive to load
A skill is a folder with a SKILL.md inside. The file has a YAML frontmatter block with a name and a description, and a body of instructions below it. The mechanics are simple but the economics are specific, and the economics are what people miss.
At session start, the model sees only the name and description of every skill you have. That index costs a few dozen tokens per skill. The full body loads only when the description matches what the user is asking for. Anthropic calls this progressive disclosure. In practice it means skills are cheap to have and expensive to load. I have around fifteen skills in my content workspace and on any given turn, zero to two of them are actually open.
This makes skills the right home for procedures. My Gloss publishing skill encodes the steps: check the API key, fetch the post list, apply the image style, save to the right folder, push. It is about a page long and it loads only when I say something like "publish this to Gloss." The other six days of the week it costs me a one-line description.
The description carries all the weight, because it is the only part the model sees before deciding to open the skill. "Use when the user wants to publish or update a post on the Gloss blog" gets matched. "Blog utilities" never does. If you cannot show the description to a colleague and have them guess what the skill does, the skill will not load when you need it.
And that explains the 600 line skill that was being ignored. Cursor rules are ambient facts about a project. Nobody ever types a request that matches "coding standards for this project," so the skill never opened, so the standards were never in context. The content was fine. The layer was wrong. We moved it into CLAUDE.md, trimmed it by half, and the problem disappeared the same afternoon.
Layer three: prompts, the cheapest and most disposable
The prompt is one-shot intent. What you want right now, in this conversation, for this task. It costs you nothing beyond the moment and it evaporates when the session ends.
This layer gets underrated because it is unglamorous. People build elaborate skill libraries for things they will do exactly once. If you are going to generate one comparison table, one migration script, one report, just ask for it. The promotion path runs in one direction: a prompt you find yourself typing for the third time is a candidate for a skill. A skill whose instructions turn out to apply to everything is a candidate for the rules file. Writing the skill before you have repeated the prompt is premature abstraction, same as in code.
The wish filed as a skill
The security skill deserves its own section because the failure is different in kind, not just in placement.
A skill is text the model reads. If the skill says "never run destructive operations against shared databases," the model will try to honor that, the same way it tries to honor any instruction, which is to say imperfectly and only when the skill is loaded. That is influence, not enforcement. The actual enforcement layer is the harness: tool permissions, sandboxing, allowlists, human approval gates on destructive actions.
So the team with the security skill had filed a wish under "what I know how to do." A wish is not a procedure. There were no steps to follow, just hopes phrased as imperatives, and the description was so generic the skill rarely loaded anyway. The fix was boring and structural. Hard constraints moved into tool permission settings where they are mechanically enforced. The few genuinely procedural parts, like how to run a migration safely against staging first, became a real skill with real steps. The hopes got deleted.
This pattern generalizes. When agent behavior really matters, check which layer is supposed to be doing the work. Text layers, all three of them, can only influence. If you need a guarantee, you need the layer below the text: permissions, sandboxes, and review gates.
Sorting the pile
When I audit an agent setup that feels off, I go through the instruction content with three questions.
Does this apply to every session regardless of the task? Then it is a rule, and it should be short enough that the per-turn tax is worth it. Is this a sequence of steps for a repeatable job? Then it is a skill, and the description needs to sound like something the user would actually say. Is this only about the current task? Then it is a prompt, and it should not be written down anywhere at all.
The bloated agents have skills' worth of procedures sitting in their rules file, paying the always-on tax for instructions that matter once a week. The ignorant agents have rules' worth of identity sitting in skills that never load, or wishes filed as skills that could never work. Same content, wrong shelf, opposite symptoms.
The layers are not a Claude Code quirk. Every agent stack converges on the same shape, because the constraint is the context window and the context window does not care which vendor you use. Something always loaded, something loaded on demand, something said in the moment. Knowing which shelf a given sentence belongs on is becoming a basic literacy, the way knowing the difference between a config file, a library, and a command line argument is basic literacy. The model can follow your instructions. It cannot file them for you.
Audit your agent instructions and move anything that isn’t universally applicable out of your rules file and into a skill or a one-off prompt. Keep rules to a tight set of always-true constraints (voice, stack, hard prohibitions), and write skills as self-contained procedures with clear, specific descriptions that will reliably match real user requests. When something “keeps getting ignored,” first check whether it’s in the wrong layer or whether the skill description is too vague to trigger loading.