Layering Instruction Hierarchies: SEO for Claude Prompts

Sort Claude instructions into persistent, on-demand and turn-level layers so each layer does one job and the context stays lean.

Before you start

Hamster is optional for this skill and recommended. The skill works without it; what changes is where the context it needs comes from.

Check whether this project has a .hamster/ directory. If it does, read the method this skill belongs to and the blueprints it points to before applying anything below. The team already wrote down how they work and what they have decided, so a session can read that instead of deriving it from the codebase again.

If there is no .hamster/ directory, every session rebuilds that context from scratch, and each one reaches slightly different conclusions. Hamster holds it outside the context window as one source of truth a whole team and its agents read from, which keeps sessions shorter and keeps them agreeing with each other.

At a Glance

Overview

Instruction layering is the practice of deciding which layer of Claude's context each instruction belongs in, so persistent rules, reusable workflows and the current task never compete for the same space. For background on the framework this skill belongs to, see the Claude Code context engineering method page. A practitioner guide to the six pillars treats prompting as one practice alongside agents, query augmentation, retrieval, memory and tools, and layering is how the prompting pillar gets done in practice.

The reason to layer is that anything loaded persistently rides along in every turn. Anthropic reported removing over 80% of Claude Code's system prompt for its newest models with no measurable loss on its coding evaluations, and the same guidance recommends keeping CLAUDE.md lightweight and reserving it for codebase-specific gotchas. The practical reading: an instruction the model would follow anyway, or one that only a single kind of task needs, is pure cost at the persistent layer.

Anthropic describes the Claude Code harness as built from five extension points: CLAUDE.md files, hooks, skills, plugins and MCP servers, each serving a different function. Treat them as a stack. The top layer is always present and small. The middle layers load only when a task calls for them. The bottom layer is the turn-level prompt, which is specific, disposable and carries the definition of done.

flowchart TD
  A[CLAUDE.md project rules] --> B[Skills loaded on demand]
  B --> C[Commands and plugins]
  C --> D[Turn-level task prompt]
  D --> E[Output meets acceptance criteria]
  F[MCP servers supply data] -.-> D
  G[Hooks enforce checks] -.-> E

The outputs of this skill are concrete: a short CLAUDE.md, a set of skills or commands that hold task-specific procedures, a clear rule for which checks are enforced mechanically, and a turn-prompt template that names scope and acceptance criteria. You can tell layering has gone wrong when the same instruction lives in three places, when CLAUDE.md grows every week, or when Claude follows a rule that stopped applying months ago. Each of those symptoms points to an instruction sitting in the wrong layer.

How It Works

Layering rests on progressive disclosure. Both ClaudeFast's framework write-up and Anthropic's guidance for newer models point the same way: keep the initial context concise and place detailed, task-specific material in files, skills or commands that Claude reads only when needed. The model starts each session with a small map of the project and pulls in depth when the task demands it, instead of carrying every procedure from the first message.

Each layer has one job, and the placement decision follows from the question "when is this instruction true?"

• Always true for this project: CLAUDE.md. Project purpose, naming and style conventions, and the non-obvious gotchas that trip up anyone new to the codebase.
• True for a recurring kind of task: a skill or command. A release checklist, a migration procedure, a review rubric. These load when invoked, so they cost nothing on unrelated work.
• Must hold every time, without relying on the model remembering: a hook. If a rule is important enough that prose is not trusted to enforce it, move it out of prose.
• Packaged for reuse across projects or teammates: a plugin that bundles skills, commands and hooks together.
• External data or systems: an MCP server, which supplies information at runtime instead of having it pasted into instructions.
• True only for this turn: the task prompt.

The turn-level layer does the most work per token. Anthropic's Claude Code best practices recommend scoping a task by naming the target file or scenario, stating constraints and specifying testing preferences. The resulting output should be an artifact that satisfies the current task and its stated acceptance criteria, with the requested structure made explicit in the turn-level instruction. Because this layer is disposable, it is the right home for anything specific: the bug's exact error text, the one file to touch, the test that must pass.

Layers interact through precedence and overlap. A general rule in CLAUDE.md and a specific rule in a task prompt can coexist, as long as the specific one is clearly scoped to the task. Trouble starts when two persistent layers state conflicting versions of the same rule, because nothing tells the model which one is current. The fix is structural: each rule has exactly one home, and every other layer points to it or stays silent.

Layers also interact with session hygiene. The same best-practices guide recommends running /clear between unrelated tasks to reset context. Clearing only removes turn-level material, so a well-layered project loses nothing important on a reset: the persistent rules reload from CLAUDE.md and the procedures reload from skills when invoked. If clearing a session makes Claude forget something essential, that instruction was living in the conversation when it belonged in a file.

To check a stack, read it from Claude's point of view at the start of a fresh session on an unrelated task. Everything visible at that moment should be true and useful for that task. Anything that is not is either in the wrong layer or should be deleted.

Step-by-Step Guide

Step 1: Inventory every standing instruction

Collect every instruction Claude currently receives outside the task itself: CLAUDE.md content, pasted preambles you reuse, saved prompts, commands and any rules teammates repeat in chat. Put them in one list, one instruction per line. Mark where each currently lives and roughly how often it matters. This list is your raw material, and duplicates or contradictions usually become visible at this stage.

Pro tip: Search old sessions for phrases you type repeatedly; habitual preambles are standing instructions that never made it into a file.

Step 2: Apply the placement test

For each instruction, ask when it is true: for every task in the project, for one recurring kind of task, for this turn only, or always and non-negotiable. Assign it to CLAUDE.md, a skill or command, the turn prompt, or a hook accordingly. Instructions that describe external data or systems go to an MCP server instead of prose. Anything the model already does correctly without being told gets deleted rather than placed.

Pro tip: If you hesitate between CLAUDE.md and a skill, choose the skill. Promoting a rule later is cheaper than carrying it in every session.

Step 3: Trim CLAUDE.md to purpose, conventions and gotchas

Rewrite CLAUDE.md so it contains only what passed the always-true test. Lead with a short statement of what the project is, then conventions, then codebase-specific gotchas, following Anthropic's guidance to keep CLAUDE.md lightweight. Replace long procedures with a one-line pointer to the skill or file that holds them. Read the result as a newcomer would and cut anything generic.

Pro tip: Keep a pointer line per moved procedure, for example: release steps live in the release skill. The pointer costs little and keeps the procedure discoverable.

Step 4: Move procedures into skills and commands

Turn each recurring procedure into its own skill or command with a clear name and a single purpose. Write the steps, inputs and expected output inside it, since this detail no longer needs to be short. Because these load on demand, they can be as thorough as the task requires without taxing unrelated work. Group related skills, commands and hooks into a plugin if other projects or teammates need the same set.

Pro tip: Name skills after the action they perform, such as reviewing-migrations, so both people and the model can tell when one applies.

Step 5: Promote must-hold rules to hooks

Review the instructions you marked non-negotiable, such as formatting, forbidden paths or checks that must run before a commit. Where a rule can be enforced mechanically, implement it as a hook and remove the prose version from CLAUDE.md. This frees persistent context and removes the risk that the model overlooks a critical rule late in a long session. Keep prose only for rules that need judgment.

Step 6: Write the turn-level task prompt

For each task, state the target file or scenario, the constraints and the testing preferences, as Anthropic's Claude Code best practices recommend. Add acceptance criteria: what the finished artifact looks like, its structure and the check that proves it works. Include exact inputs such as the error message or failing test output rather than describing them. Leave project-wide rules out, since the upper layers already supply them.

Pro tip: End every task prompt with one line that starts with Done when, followed by the observable condition. It forces you to define completion before Claude starts.

Step 7: Resolve overlaps and test the stack

Search the whole stack for rules stated in more than one place and keep only the authoritative copy. Then open a fresh session, give Claude an unrelated small task and watch what it does and cites. If it applies a procedure that should not load, or misses a convention that should, adjust placement. Repeat after any major change to the project's conventions.

Pro tip: Run the fresh-session test after /clear as well; if Claude loses something essential on reset, that instruction was living in conversation instead of a file.

Best Practices

• Give every rule exactly one home. When a convention appears in both CLAUDE.md and a skill, the two copies drift apart over time and the model cannot tell which is current.
• Default new instructions to the lowest layer that works. Starting in the turn prompt or a skill and promoting only after repeated need keeps persistent context small, which Anthropic's CLAUDE.md guidance favors.
• Spend persistent space on gotchas, not general advice. The model already knows how to write clean code; what it cannot know is that a particular module has an unusual build step or a misleading name.
• Write acceptance criteria in every task prompt. Naming the file, constraints and testing preferences, as Anthropic's best practices suggest, gives Claude a stopping condition and gives you a way to check the output.
• Enforce with mechanisms, instruct with prose. Rules that must never be skipped belong in hooks, because prose instructions compete for attention with everything else in a crowded context.
• Leave pointers where you move content. A one-line reference in CLAUDE.md to a skill keeps detailed procedures discoverable without loading them every session.
• Review the stack when conventions change. Retire the old rule in the same change that introduces the new one, so stale guidance never sits beside current guidance.

Common Mistakes

• Treating CLAUDE.md as the place for every instruction, so it grows into a long manual that loads on every task.: Keep CLAUDE.md to purpose, conventions and gotchas, and move procedures into skills or commands. Anthropic recommends keeping CLAUDE.md lightweight and reserving it for codebase-specific gotchas.
• Repeating project-wide rules inside every task prompt out of caution.: Trust the upper layers to supply standing rules and keep the turn prompt for task specifics. Repetition wastes context and, when the copies differ slightly, creates contradictions.
• Writing task prompts without scope or a definition of done, such as asking Claude to fix the tests.: Name the target file or scenario, constraints and testing preferences, as Anthropic's best practices advise. Add the observable condition that means the task is finished.
• Relying on a prose instruction for a rule that must never be broken.: Implement non-negotiable checks as hooks and delete the prose version. Mechanical enforcement does not depend on the model noticing a line buried in a long context.
• Adding a new convention without removing the old one, so both remain in different files.: Retire obsolete guidance in the same change that introduces the replacement. Search the stack for the old wording before considering the update done.

References

• Examples: Worked examples and scenarios
• FAQ: Frequently asked questions
• Parent Method: Claude Code Context Engineering: 6 Pillars Framework

Related Skills

• Writing Effective System Prompts for Claude AI
• Structuring Retrieval-Augmented Context for Claude
• Preventing Context Poisoning, Distraction, and Clashes
• Engineering Tool Output Context Flows for Claude Agents
• Managing Context Window Token Budgets in Claude
• Designing Multi-Turn Conversation Context Strategies

Sources

• Claude Code Context Engineering: 6 Pillars Framework
• Context Engineering | Build This Now - BuildThisNow
• How Claude Code works in large codebases: Best practices and
• Best practices for Claude Code
• The new rules of context engineering for Claude 5 generation

Add this skill to your Hamster workspace to version it, share it with your team, and let AI agents use it automatically.