Claude Code

The Right Layer
Where Knowledge Lives in Claude Code

A decision framework for structuring Claude Code's context layers. When to create what, and why.

Mar 7, 202610 min readView as Markdown

The Problem

Claude Code has five distinct context layers: CLAUDE.md, Rules, Skills, Agents, and Hooks. Each answers a different question. Put knowledge in the wrong layer and it either bloats every session, gets ignored, or fails to trigger when needed.

This compass gives you a mental model for deciding where to put what and why that layer is the right fit.

Architecture Map

Follow a real prompt through all five layers. We'll use ShopFlow, a fictional e-commerce store, to show what each layer looks like in practice.

Advisory
Enforced
CLAUDE.md

"Who is this project?"

AdvisoryAlways
Rules

"What structural guidance does Claude need?"

AdvisoryAlways / path-match
Skills

"What does Claude need to know about X?"

AdvisoryOn-demand
Agents

"Who should handle this type of work?"

EnforcedWhen delegated
Hooks

"What must happen every time, no exceptions?"

EnforcedOn lifecycle event

A developer asks Claude to add a Stripe checkout page...

Step 1 of 6
Click any layer to explore

Decision Tree

Click through to find the right layer for your knowledge.

I have knowledge or guidance I want Claude to use. What kind is it?

The 5 Layers

Each layer has a purpose, a litmus test, and anti-patterns. Expand any layer to see the details.

When

Always. First thing you create.

What

Project identity in <200 lines. Tech stack, build commands, file structure, conventions that can't be inferred from code.

Why

Sets the baseline context for every session. It's the README for Claude.

Litmus tests
?"Would a new team member need this on day 1?"
?"Can Claude figure this out by reading the code?"
Anti-patterns
×Putting detailed technology guidance here (that's a skill)
×Exceeding 200 lines (split into rules)
×Describing every file in the codebase
Memory & CLAUDE.md docs →
When

You need to encode layout patterns, architecture references, project-specific tool preferences (e.g., migration tools, testing patterns), or pointers to central documentation, especially in large, complex projects.

What

Modular .md files in .claude/rules/. Can be path-scoped with paths: frontmatter. Can reference external architecture docs, ADRs, wiki pages, or tool-specific conventions chosen for this project.

Why

Rules bridge Claude to your wider knowledge base. They encode project-specific structural decisions: how code is organized, which patterns and tools are preferred here, where to find authoritative references. All without bloating every session.

Litmus tests
?"Is this about how code should be structured or laid out?"
?"Does this encode a project-specific tool or pattern choice?"
?"Does this reference architecture decisions or central documentation?"
?"Should this guidance only apply when touching specific files?"
Anti-patterns
×Treating rules as CLAUDE.md overflow (they serve a different purpose)
×Putting reusable tech knowledge here (that's a skill)
×Rules are structural guidance, not general expertise
Rules docs →
When

You have deep knowledge about a technology, workflow, or domain that Claude should reference when relevant.

What

SKILL.md files with frontmatter. Auto-invoked by description matching, or manually via /skill-name.

Why

Loaded on-demand, not every session. Keeps base context clean while making deep expertise available.

Litmus tests
?"Would this be useful across multiple projects?"
?"Is this tech knowledge or a repeatable process?"
Anti-patterns
×Putting project-specific conventions in a portable skill
×Skills are project-agnostic; rules handle project specifics
Skills docs →
When

A recurring task benefits from a specialized persona with restricted tools and preloaded skills.

What

Agent .md files defining role, allowed tools, preloaded skills, and behavioral instructions.

Why

Isolation. A code-reviewer doesn't need Write access. A researcher doesn't need Edit. Agents scope context and permissions to a role.

Litmus tests
?"Does this task need a different tool set or mindset than general coding?"
?"Do I keep giving Claude the same role instructions?"
Anti-patterns
×Creating agents that are just skills with no tool/permission differences
×If it's just knowledge, it's a skill
Subagents docs →
When

You need guaranteed, deterministic execution, not advisory guidance.

What

Shell commands triggered on lifecycle events (PreToolUse, PostToolUse, SessionStart, etc.).

Why

Rules and CLAUDE.md are advisory. Claude might skip them. Hooks are code that runs.

Litmus tests
?"Would it be a problem if Claude occasionally forgot to do this?"
?"Is this a shell command, not judgment?"
Anti-patterns
×Using hooks for things that require reasoning (that's a rule or skill)
×Hooks are mechanical, not advisory
Hooks docs →

Comparison Matrix

Side-by-side comparison of all five layers.

CLAUDE.mdAdvisory
Scope

Project

Loads

Always, every session

Contains

Identity, conventions

RulesAdvisory
Scope

Project / User

Loads

Always or path-match

Contains

Structure, architecture refs

SkillsAdvisory
Scope

Marketplace

Loads

On-demand / auto-match

Contains

Tech knowledge, workflows

AgentsEnforced
Scope

Marketplace

Loads

When delegated to

Contains

Role, tool restrictions

HooksEnforced
Scope

Project / User

Loads

On lifecycle event

Contains

Shell commands

Advisory vs Enforced

Advisory

Claude should

Claude reads these and follows them, most of the time. But it can choose to deviate if it judges something else is better.

CLAUDE.mdRulesSkills

Enforced

Claude must

These execute mechanically. Hooks run as shell commands. Agent tool restrictions are hard boundaries. No discretion involved.

Hooks (shell commands)Agent tool restrictions

Scope Hierarchy

Click a scope to see what lives there. Higher scopes override lower ones.

Higher scopes override lower ones ↓

Skill vs Agent

Skill = the WHAT

Technology knowledge. How does Playwright work? What are the best practices for Vite config? How do we structure GitLab CI pipelines?

Example

playwright skill: knows about locators, fixtures, Page Object Model, parallel execution patterns.

Agent = the WHO

A specialist who uses that knowledge. Has a persona, restricted tools, and a specific mindset. The agent preloads skills it needs.

Example

test-writer agent: preloads playwright skill + has Write access to test files only + thinks about edge cases and isolation.

If it's just knowledge with no permission difference → Skill

Quick Decision Cheat Sheet

"Would a new team member need this on day 1?"
CLAUDE.md
"Is this about layout, structure, or architecture references?"
Rule
"Should guidance only load when touching specific files?"
Rule (with paths:)
"Is this reusable tech knowledge or a repeatable process?"
Skill
"Does this need different tools or a different persona?"
Agent
"Would it be a problem if Claude forgot to do this?"
Hook
"Is it just knowledge with no permission difference?"
Skill, not Agent

Official Documentation