跪拜 Guibai
← Back to the summary

Stop Stuffing Rules into AI Memory: Index in Memory, Rules in Skills

Core conclusion: Many people stuff rules, SOPs, and workflows entirely into Memory, but both Claude and Codex Memory have hard limits. CLAUDE.md is recommended to stay under 200 lines; in a 200K context window it eats about 40,000 characters every time. Once rules pile up, the AI reads a whole pile of them on each task, crowding the context and interfering with each other. The correct approach is one sentence: let Memory do the indexing, let Skill store the rules. Memory is only responsible for telling the AI "which Skill this task should read"; the actual rules, SOPs, and operation handbooks all go into Skill, not Memory. This way rules won't get trimmed out, and workflows won't interfere with each other.

Table of Contents

1. Does Memory have a limit at all: putting the numbers on the table

Stop arguing the philosophical question of "does Memory have a limit" and put the official constraint numbers on the table.

Recommended line count for CLAUDE.md: Anthropic officially recommends each CLAUDE.md file stay under 200 lines. Beyond that, the official wording is "consume more context and reduce adherence" — it takes up more context and lowers adherence. This is not an aesthetic suggestion; it's an engineering constraint from real testing.

Characters in the 200K context window: In the default 200K context window, CLAUDE.md has about 40,000 characters of usable space (for models with a 1M context window it's 200,000/150,000 characters). That means if rules are long and dense, a single file can eat up a good fraction of the whole window just by itself.

MEMORY.md loading limit: The auto memory index file MEMORY.md loads only the first 200 lines, or the first 25KB, whichever comes first, at the start of each session. Anything beyond that is simply not read this session — you wrote it, but the AI can't see it.

Skill loading cost: The truly on-demand loaded one is Skill. When a Skill starts, it only loads its name + description (about 100 tokens); the full SKILL.md body (<5k tokens) enters context only when the skill is triggered.

Putting the four numbers together, the conclusion is clear: Memory is "resident memory", Skill is "read on demand". The more resident stuff you have, the more you pay for unrelated rules on every task.

References:

2. Two costs of stuffing all rules into Memory

When rules pile up and all go into Memory, you pay two concrete costs. These costs aren't "a bit worse performance"; they directly make the AI fail at its job.

Cost one: rules get trimmed out (truncated). Memory has a 200-line / 25KB loading threshold. If you write too many rules, the later ones won't load into the session. You think you wrote "must review code before committing", but because it's too long and sits at the end, the AI may not see it this round. The rule hasn't disappeared; it's just "lying in a corner outside the window", and the AI won't go look for it.

Cost two: workflows interfere with each other. When dozens of rules on different topics (database migration, release checklist, code review standards) all sit in the same Memory file, the AI has to read them from start to finish on every task. That produces two kinds of interference: first, unrelated rules steal attention, diluting the rule that should be executed; second, rules may contradict each other, and the AI swings back and forth in the contradiction.

Using an analogy 🎭: Memory is like a computer's resident memory, occupying space as soon as the machine boots; Skill is like software loaded on demand, you open it and it loads. If you make all software launch at startup, the memory soon blows up and they fight for resources — that's the same logic as stuffing all rules into Memory.

References:

3. Core solution: Memory as index, Skill as rule store

Since Memory is a scarce resident resource, the solution is one sentence: Memory only does indexing; all specific rules and SOPs go to Skill.

What Memory is responsible for: only recording "what Skills this project has, what each Skill does, and when to call which Skill". It's an index card that tells the AI "which Skill this task should read". The core is signal-dense — every line has to earn back the context it occupies.

What Skill is responsible for: the specific rules, SOPs, operation handbooks, and checklists. For example, database migration flow, release checklist, code review standards, API usage for a framework. This content only loads when triggered, so it doesn't crowd the resident context.

Why this division works: Skill natively supports progressive disclosure. Skill's name and description stay resident (about 100 tokens), and the body loads on demand. Putting rules in Skill means "the rule that should be read" only enters context when needed, and takes up no space otherwise.

Rule of thumb: if something "the AI must know every round" → put it in Memory; if "only needed for a certain kind of task" → put it in Skill; if it's a "multi-step flow / operation handbook" → definitely put it in Skill.

References:

4. Skill's loading mechanism: why rules won't get trimmed

Someone will ask: "If I move rules into Skill, what if the AI forgets to read it?" The answer is: Skill has an auto-trigger and on-demand loading mechanism; it's not afraid of "being trimmed out" because it occupies a tiny slot in the session.

Skill's three-level loading (progressive disclosure):

Level When loaded token cost Content
Level 1: Metadata At startup about 100 token / each name + description
Level 2: Instructions When Skill is triggered <5k token SKILL.md body
Level 3: Resources When execution needs no limit references / scripts etc.

Why this solves "rules getting trimmed": The Skill body never loads in normal usage, so there's no problem of "written too much and truncated". What actually occupies context is Level 1's name + description (about 100 tokens each), and that part is exactly the leanest index — it only tells you "this skill exists and when to use it".

How to trigger: Skills can be called explicitly by path commands (like /code-review), or auto-matched by task. Once triggered, the AI reads the complete SKILL.md into context and temporarily has all the rules.

References:

5. A runnable decision function: which line goes into Memory or Skill

The code below formalizes the "Memory vs Skill" decision into 4 questions. Running it requires no external dependencies; copy and run:

def classify_rule_entry(
    always_needed: bool,   # whether the AI must know this content every round
    is_workflow: bool,     # whether it belongs to a multi-step process / operation handbook
    task_specific: bool,   # whether it is only needed for a specific task
) -> str:
    """Decide whether a rule should go into Memory (index) or Skill (body).

    Args:
        always_needed: whether the content must be resident every session (e.g., project conventions, naming standards)
        is_workflow: whether it is a multi-step process, SOP, or operation handbook
        task_specific: whether it is only needed in a specific task scenario
    Returns:
        Recommended placement: memory / skill
    """
    # 1) Multi-step process / handbook -> definitely go to Skill, avoid crowding resident context
    if is_workflow:
        return "skill (Skill): process/handbook loads on demand, does not crowd resident context"

    # 2) Must know every round -> go to Memory, as a resident index
    if always_needed:
        return "memory (Memory): resident index, ensures each session loads"

    # 3) Only needed for a specific task -> go to Skill, use description for auto-trigger
    if task_specific:
        return "skill (Skill): loads when task triggers, matched by description"

    # 4) None satisfied -> default to Skill, most conservative
    return "skill (Skill): default on-demand load, avoid redundancy"


# Example: determine where "database migration flow" goes
if __name__ == "__main__":
    print(classify_rule_entry(
        always_needed=False,  # migration flow is not needed every round
        is_workflow=True,     # it is a multi-step manual
        task_specific=False,
    ))
    # Output: skill (Skill): process/handbook loads on demand, does not crowd resident context

The code condenses the judgment logic into one runnable decision path. Core principle: get as much as possible into Skill; only keep the must-resident index in Memory.

6. Comparison table: symptom → cause → solution

Symptom Cause Solution
Wrote many rules, but the AI always misses one when executing The rule sits beyond the Memory 200-line / 25KB threshold and never loaded into the session Move non-core rules into Skill, keep only an index in Memory
AI is slow on every task, token consumption high A lot of unrelated rules are read in every time, filling resident context Trim Memory under 200 lines, have rules loaded on demand by Skill
Several workflow rules contradict each other, AI wavers Different-topic rules all crammed into one Memory file, interfering Split into different Skills by topic, each triggers independently
Want to add a new rule but don't know where it goes No standard for "index vs body" Use the decision function above: multi-step flows go to Skill, resident conventions go to Memory
The project has a pile of Skills, but the AI doesn't remember to use them Skill descriptions written too generically, can't auto-trigger Strengthen Skill descriptions to a "when to use" trigger scene

7. Conclusion: criteria for use / non-use

When to use: if the rule is a "convention the AI must know every round" (naming standards, build commands, basic project structure) → put it in Memory (CLAUDE.md); if the rule is a "multi-step process, SOP, or operation handbook" → put it in Skill (load on demand). The standard is just one — does the AI need to see this rule every round; if yes, go to Memory, if no, go to Skill.

When not to use: don't stuff all rules into Memory, especially don't stuff multi-step processes and long handbooks; don't let Memory exceed 200 lines / 25KB; don't fill the context window with tons of content, because that only lowers adherence to rules. When rules pile up, the move is to split them into Skills, not keep stacking them into Memory.

This column, "AI Agent Tools", moves through tool calling, memory management, Skill routing, and then to rule governance and context limits. Every post comes with runnable code and a comparison table, focusing on real trade-offs in production, updated weekly. To step on fewer traps in Agent engineering, subscribe on the column page.

Comments

Top 2 from juejin.cn, machine-translated. The original thread is authoritative.

pang_claw 1 likes

Stuffing all rules into Memory just takes up more context and makes it even easier to miss execution.

ENCI

When I review AI code, what I fear most isn't syntax errors, but logic that is very 'correct' but isn't what the business actually needs—rule configuration is the same. Rules stuffed into Memory get read every round, appear to all be there but actually conflict with each other. Do you usually write rules into CLAUDE.md or a separate Skill? A: stuff all into Memory, B: strictly separate into Skill—share your configuration in the comments.