Teaching Claude Who You Are

What You'll Learn

Section 3 taught Claude about your project. This lesson teaches Claude about you. Your name, your tools, your communication style, your coding patterns. These preferences follow you across every project, every session.

Project Memory vs User Memory

Claude loads user memory automatically at the start of every session, before it reads anything project-specific. Think of it as your personal profile that Claude carries with it.

Give Claude Your Business Card

Start by creating an identity file that tells Claude who you are:

mkdir -p ~/.claude

Create ~/.claude/info.md:

# About Me
 
- My name is [Your Name]
- I am a [your role] with expertise in [your domains]
- I do [type of development]
- When referencing my config files, don't mention where you read it. Just talk like you know me

This might feel strange at first. You're introducing yourself to an AI. But it changes how Claude communicates with you. Instead of generic responses, Claude addresses you by name and tailors its suggestions to your experience level and domain.

Notice the last line. That's a meta-preference: it tells Claude how to use the information, not just what the information is. Without it, Claude might say "Based on your preferences file, you prefer bun over npm." With it, Claude just uses bun without narrating its reasoning. Small detail, big difference in how natural the interaction feels.

Add Your Preferences

Create ~/.claude/preferences.md:

# Working Preferences
 
## Tooling
- I use bun, not npm
- I use Biome for linting and formatting, not ESLint/Prettier
 
## Communication
- Be concise. Build first, explain only if I ask
- Don't ask clarifying questions unless genuinely blocked
- When I say "fix it", just fix it. Don't list options
 
## Coding Style
- Functional components with arrow functions
- Early returns over nested conditionals
- Prefer explicit types over inference for function signatures
- TypeScript strict mode always
 
## Principles
- Always find the root cause. Don't add retry logic to mask a slow API. Don't add a cache to hide a bad query. Fix the actual problem
- Explore the code first, then build. Read before you write

These are preferences that are true about you, not about any specific project. They should be things you consistently want across every codebase you work on.

The "Principles" section is where you encode your engineering philosophy. This shapes how Claude approaches problems, not just what syntax it uses.

Wire It Together

Now create your user-level entry point that references both files:

# ~/.claude/CLAUDE.md
 
@~/.claude/info.md
@~/.claude/preferences.md

This is the same @ import pattern from Section 3, but at the user level. Claude loads ~/.claude/CLAUDE.md at session start, which pulls in your identity and preferences automatically.

Your user-level structure now looks like:

What Works Well in User Memory

Here's what I keep in mine:

• My name and how I want to be addressed
• Tools I always reach for (bun, Biome, a specific testing framework)
• Communication preferences (concise vs detailed, when to ask vs when to build)
• Coding patterns I consistently prefer
• Engineering principles that guide how I work

Generally, if something changes between projects, it probably belongs in project memory instead. User memory is for the things that are true about you everywhere.

Key Takeaways

• User memory lives at ~/.claude/CLAUDE.md and loads on every session
• Split your identity (info.md) and preferences (preferences.md) into focused files
• Use @ references to keep your user-level CLAUDE.md clean
• The same task produces noticeably different results with personal preferences set
• Section 3 taught Claude your project. This lesson taught Claude you