How to Use Claude Code Instructions and Memory: The Complete Setup Guide

If you’ve been manually re-explaining your tech stack, code style, and architecture rules to Claude Code every single session, you’re doing it the hard way.

Claude Code has a built-in instructions and memory system designed to eliminate exactly that friction. In this guide, you’ll learn how to configure it from scratch — from a basic CLAUDE.md file all the way to a scalable multi-file rule system for larger teams — so Claude already knows your project deeply before you type a single message.

🚀 Complete JavaScript Guide (Beginner + Advanced)

🚀 NodeJS – The Complete Guide (MVC, REST APIs, GraphQL, Deno)

What Are Claude Code Instructions and Memory?

Claude Code provides two complementary mechanisms for persisting project context:

Instructions are file-based directives stored in your repository. Claude reads them automatically at the start of every session. They are version-controlled, team-shared, and always-on.

Memory is a personal, session-learned layer. Claude stores facts you teach it during conversations and recalls them in future sessions. Memory lives on your local machine and is specific to you — not your team.

Together, they form a complete context system: instructions set the team standard, memory handles your personal preferences.

The Foundation: CLAUDE.md

What Is CLAUDE.md?

CLAUDE.md is a Markdown file placed at the root of your repository. Claude Code reads it automatically every session — no commands, no prompting required.

What to Put In It

Focus on information Claude would otherwise guess wrong:

# Project Instructions

## Tech Stack
- Node.js 22, TypeScript, PostgreSQL
- Use ESM modules, not CommonJS
- Tailwind CSS for all styling

## Code Style
- All functions must have JSDoc comments
- Prefer `const` over `let`
- No `any` types in TypeScript

## Architecture
- Controllers live in /src/controllers
- Services handle all business logic
- Never put database queries in controllers

The Three Levels of CLAUDE.md

Claude Code supports a hierarchy of instruction files:

Level	Location	Scope
Global	`~/.claude/CLAUDE.md`	All projects on your machine
Project	`/your-project/CLAUDE.md`	Entire project
Subdirectory	`/your-project/frontend/CLAUDE.md`	That folder and below

Claude loads all applicable levels and merges them. This makes it possible to have global personal preferences, project-wide standards, and folder-specific overrides — all coexisting cleanly.

Scaling Up: Organizing Instructions Into Multiple Rule Files

The Problem With One Big File

A single CLAUDE.md works well for small projects. As your codebase grows, mixing code style rules, testing conventions, architecture patterns, and security policies into one file becomes unmaintainable and hard to update.

The Multi-File Solution

Claude Code supports importing additional instruction files from your root CLAUDE.md using @import syntax. This lets you organize rules by concern:

my-project/
├── CLAUDE.md                  ← root: imports everything
├── .claude/
│   ├── code-style.md
│   ├── architecture.md
│   ├── testing.md
│   └── security.md
├── frontend/
│   └── CLAUDE.md
└── backend/
    └── CLAUDE.md

Your root CLAUDE.md becomes a clean table of contents:

# Project Instructions

@.claude/code-style.md
@.claude/architecture.md
@.claude/testing.md
@.claude/security.md

Example Rule Files

.claude/testing.md

# Testing Conventions
- Use Vitest, not Jest
- Test files live alongside source as `*.test.ts`
- Every exported function needs at least one unit test
- Mock all external HTTP calls

.claude/security.md

# Security Rules
- Never log sensitive user data
- Always validate and sanitize input before processing
- Use parameterized queries — no SQL string concatenation
- Secrets must come from environment variables only

Why This Matters for Teams

Because these files are committed to Git, every developer who clones the repo inherits the same Claude Code behavior automatically. No onboarding docs. No configuration. No inconsistency between machines.

Best Practices for Rule Files

One concern per file — don’t mix testing and security rules
Use bullet points, not paragraphs — Claude processes concise, imperative rules better
Name files descriptively — testing.md beats rules3.md
Don’t repeat yourself across files — contradictory rules confuse the model
Never store secrets — these are plain text files in your repo

The Memory System: Your Personal AI Layer

How Memory Works

Memory stores personal preferences you want Claude to apply across all future sessions. You can save things explicitly:

> Remember that we use snake_case for all database column names

Or use the /memory command to open, review, and manage everything Claude has stored.

Viewing and Editing Memory

Running /memory in the Claude Code terminal displays all stored memory entries. You can:

Edit existing entries
Delete outdated ones
Add new entries manually

Memory is stored as plain text at ~/.claude/memory, so you can also inspect and edit it directly in any text editor.

Proactive Memory Suggestions

Claude Code will proactively offer to save something to memory when it detects a repeated pattern — for example, if you correct it on the same convention multiple times in a session.

Important: Memory Is Local

Memory is stored on your machine only. It does not sync to teammates, is not committed to Git, and will not transfer if you switch computers. For anything team-relevant, use CLAUDE.md rule files instead.

Real-World Workflow: Putting It All Together

Here’s a complete setup for a mid-sized Express API project:

project/
├── CLAUDE.md                    ← imports all rule files
├── .claude/
│   ├── code-style.md            ← ESM, TypeScript, JSDoc rules
│   ├── architecture.md          ← controller/service separation
│   ├── testing.md               ← Vitest conventions
│   └── security.md              ← input validation, no secret logging
└── tests/
    └── CLAUDE.md                ← test-specific overrides

Personal memory adds:

Preferred commit message style
Personal naming preferences
Workflow shortcuts

Result: Every session, Claude Code loads the full project context automatically. You open the terminal, describe what you want built, and Claude already knows the stack, the patterns, the test framework, and the security constraints — without a single line of prompt engineering.

Key Takeaways

CLAUDE.md is loaded automatically every session — use it for anything Claude would otherwise guess wrong
Use subdirectory CLAUDE.md files for monorepos and large codebases
Organize rules into multiple focused files using @import and store them in .claude/
Commit all rule files to Git so your entire team benefits automatically
/memory handles your personal, persistent preferences — separate from team rules
Keep rule files short, scannable, and imperative — bullet points beat paragraphs
Audit memory periodically and prune stale entries
Never store secrets in any instruction file

Conclusion

The instructions and memory system is one of Claude Code’s most powerful — and most underused — features. A modest upfront investment in a well-organized CLAUDE.md and a set of focused rule files pays compounding dividends: fewer corrections, more consistent output, faster onboarding, and a codebase where your AI conventions are version-controlled right alongside your code.

Set it up once. Watch it pay off every session.

Share this article