Andrej Karpathy once pointed out that the biggest waste of time when using AI coding tools is repeatedly re-explaining project context.

His core idea is simple: one well-written guide can replace hundreds of prompts.

Claude Code gives you three different layers for doing exactly that.

The Three Layers of Persistent AI Context

1. CLAUDE.md — Persistent Project Instructions

If you place a CLAUDE.md file in your project root, Claude Code automatically injects it into the system prompt whenever a session starts in that directory.

That means you stop repeating the same explanations every time.

Best use cases:

• Explaining project architecture and folder structure
• Persistent behavioral rules like “don’t over-comment” or “don’t add extra features”
• Capturing instructions you find yourself repeating often
• Sharing conventions across a team through git

2. Custom Skills — .claude/commands/

Any markdown file inside .claude/commands/ becomes a reusable slash command.

Example:

# .claude/commands/blog.md
Analyze today’s git diff and write a developer blog post.

Structure:
- Overview
- Technical details
- Lessons learned
- 5 tags

Format: Markdown

Once this exists, typing /blog automatically runs that prompt.

Best use cases:

• Repeated workflows like release notes, commit messages, and code reviews
• Tasks with fixed output formats
• Personal workflows that don’t need team-wide sharing

3. MCP Servers — Plugin-Style Integrations

MCP (Model Context Protocol) is a standard for connecting Claude to external tools.

It’s how Claude can interact with systems like Figma, Notion, internal APIs, databases, Slack, or Linear.

Best use cases:

• When Claude needs live external data
• Shared internal tooling across multiple projects
• Accessing context outside the local filesystem

How to Actually Write a Good CLAUDE.md

Trying to design the “perfect” file on day one usually backfires.

Karpathy’s approach is much simpler:

“If you explained something to Claude twice, it belongs in CLAUDE.md.”

Things that genuinely help:

• Architecture facts — build targets, shared files, data flow, module ownership
• Known tooling issues — things like false positives from SourceKit or flaky scripts
• Behavioral rules — “don’t refactor outside scope,” “avoid unnecessary comments,” etc.
• Hard constraints — “never create .strings files,” “always use AppStrings,” and similar rules

Things you should avoid putting in:

• Anything git already tracks
• Anything obvious from reading the code
• Temporary status information that changes frequently

Where Claude Still Struggles — and How to Fix It

Claude is optimized for coding tasks. But for creative work like blog posts, marketing copy, or reflective writing, the output can sometimes feel flat and overly technical.

Common Failure Patterns

• Blog posts read like documentation
• Retrospectives become bullet-point summaries
• The writing tone changes every session

Fix #1 — Bake a Persona Into a Custom Skill

# .claude/commands/blog.md

## Role
You are an indie iOS developer.
Write with technical accuracy,
but explain tradeoffs and decisions honestly.

## Structure
- Why this work mattered
- Technical implementation
- Failed attempts and lessons learned
- 5 tags

## Rules
- Avoid corporate tone
- Don’t just list changes
- Prioritize reasoning over features

Fix #2 — Define Writing Style Inside CLAUDE.md

## Writing Style
- Lead with conclusions
- Explain reasoning after decisions
- Include failed attempts
- Avoid overly formal tone
- Explain technical terms only once

Fix #3 — Separate Creative Work From Coding Sessions

For writing-heavy tasks, using the Claude web app separately from Claude Code can sometimes produce better results.

Claude Code works best when focused on code and file operations. The web version often performs better when the session is purely about writing.

When to Use What

• Starting a new project → create CLAUDE.md first
• You repeated yourself twice → add it to CLAUDE.md immediately
• A workflow becomes repetitive → turn it into a custom Skill
• Claude needs external system access → consider MCP integration
• Writing output feels bland → lock in a persona/style or move writing into the web app