Power User — Memory, Context & Expert Patterns

🧠 Understanding Claude's Memory System

Claude doesn't have persistent memory by default — each session starts fresh. But you have four layers to inject memory, each with different scope and persistence. Mastering these layers is what separates a power user from a casual one.

The priority order runs bottom-up: inline instructions override session context, which overrides project CLAUDE.md, which overrides global. Use each layer for what it's actually for:

• Global CLAUDE.md: Your identity as an engineer. Stack preferences, languages you know, output format preferences, things Claude should never do.
• Project CLAUDE.md: This project's architecture, stack, design decisions, file roles, known quirks. Updated as the project evolves.
• Session context: Files relevant to today's task. Use @ mentions to pull in exactly what Claude needs, nothing more.
• Inline: One-off overrides. "For this response only, reply in bullet points." or "Ignore the style guide just this once."

📊 Context Mastery — Work Within the Window

Every Claude session has a context window — a finite budget of tokens that covers everything: your instructions, the conversation history, and every file you reference. Hitting the limit degrades quality before it errors. Managing context is a skill.

What's consuming your context right now?

The three context problems and how to fix them

Context hygiene rules

• Start new sessions for new tasks. Don't drag unrelated context from a React debugging session into a Python scripting task.
• /compact before long generation. If you're about to ask Claude to write a large file, compact first so the full context window is available for output.
• Use /clear when pivoting completely. If you change direction mid-session, /clear wipes context and starts fresh — better than confusing Claude with contradictory history.
• Reference only what Claude needs. Mentioning 10 files when only 2 are relevant wastes tokens and dilutes focus.

⚙️ Custom Instructions — Your Global CLAUDE.md

Global instructions live at ~/.claude/CLAUDE.md (on Mac/Linux) or %USERPROFILE%\.claude\CLAUDE.md (Windows). They load for every Claude session, regardless of which project you're in. Think of this as programming Claude's default behavior for you specifically.

What belongs in global instructions

• Your tech identity: Languages you work in, frameworks you prefer, what you never want to use
• Output format preferences: How verbose responses should be, whether to explain your reasoning, preferred code style
• Hard limits: Things Claude should never do without asking — delete files, push to production, send messages
• Your communication style: Terse and direct vs. explanatory, whether you want analogies, how much jargon is OK

# Global Instructions — Rick

## Stack
Python 3.12+ (primary), TypeScript (secondary), vanilla HTML/CSS/JS for UIs.
Prefer: FastAPI, Pydantic, Anthropic SDK. Avoid: Django, jQuery, class components.

## Code style
- Concise over verbose. If it fits in 3 lines, don't write 10.
- Type hints always in Python.
- No docstrings unless the function is genuinely non-obvious.
- Functional patterns preferred over OOP for utilities.

## Response style
- Short answers by default. Expand only when I ask.
- No preamble ("Sure!", "Great question!") — start with the answer.
- When showing code, show only the changed part unless I ask for the full file.
- If something is ambiguous, ask one clarifying question before proceeding.

## Hard limits (always ask first)
- Never push to git remote without confirmation.
- Never send emails, Slack messages, or external API calls in production mode.
- Never delete files — move to .trash/ instead.

## Context
I'm a software developer who knows what I'm doing. Skip the basics.
Assume I understand trade-offs. Just give me the recommendation.

Creating your global CLAUDE.md

# Create the .claude folder if it doesn't exist
mkdir -p ~/.claude

# Open in your editor
code ~/.claude/CLAUDE.md

# Or ask Claude to write it for you
claude "Write a global CLAUDE.md for me. Ask me 5 questions about my stack, style, and preferences first."

🔐 Permission Tuning

Claude Code's permission system controls what Claude can do without asking. The defaults are cautious — Claude will ask before running shell commands, editing files outside your project, or installing packages. You can tune these per project in .claude/settings.json.

Permission levels

settings.json — per-project permission config

{
  "permissions": {
    // Allow read without prompting — safe and fast
    "allow": [
      "Read",
      "Bash(git status)",
      "Bash(git diff*)",
      "Bash(npm run *)"
    ],
    // Always ask before these — high-risk actions
    "deny": [
      "Bash(rm *)",
      "Bash(git push*)",
      "Bash(curl *)"
    ]
  }
}

Hook-based permission patterns

Hooks (from Module 05) are the advanced permission layer. Instead of allow/deny, hooks let you intercept, log, approve, or block actions with custom logic.

{
  "hooks": {
    "PreToolUse": [{
      "matcher": "Bash",
      "hooks": [{
        "type": "command",
        // Log every shell command Claude runs — audit trail
        "command": "echo \"[$(date)] $CLAUDE_TOOL_INPUT\" >> ~/.claude/audit.log"
      }]
    }]
  }
}

🗂 Multi-Project Setup

Once you're working on multiple projects — a SaaS product, a side project, client work — your Claude setup needs to scale with you. The key is a hierarchy where global instructions stay consistent and project-specific context stays isolated.

The expert file hierarchy

Switching between projects

When you cd into a project and run claude, Claude automatically loads:

1. Your global ~/.claude/CLAUDE.md first
2. The project's ./CLAUDE.md second (overrides can be added here)
3. Any .claude/settings.json in the project directory

This means walking into a new project is instant context — Claude knows the stack, the rules, and the history without you re-explaining anything.

⚡ Expert Patterns

These are the prompting and workflow patterns that experienced Claude Code users reach for automatically. Not clever tricks — durable techniques that appear across every project.