The 3 Files That Turn Claude Code Into Your Dev Partner
2026-03-11 · Jazz Lien
Updated June 2026: the full system is now open-sourced and re-verified against the current Claude Code — the repo. For what three months of a fast-moving CLI changed, see What 3 Months Did to My Claude Code Workflow.
In Part 1, we set up three files that make Claude Code remember your project: what to build, how to build it, and how to hand off between sessions.
But Claude still doesn't know you. It doesn't know you prefer direct feedback over diplomatic hedging, that you'll pick Tailwind over CSS-in-JS every time, or that "make it good" means production-grade, not prototype.
These three files fix that.
The two layers
Project layer: SPEC.md → CLAUDE.md → HANDOVER.md
Personal layer: soul.md → hooks → MEMORY.md
- soul.md -- "Here's who I am." Your background, style, and values.
- Hooks -- "Here's how I want you to behave." Guardrails and automation.
- MEMORY.md -- "Here's what you've learned about me." Cross-project, long-term memory.
Part 1 makes Claude remember the project. Part 2 makes Claude remember you.
File 4: soul.md -- teach Claude who you are
The problem it solves
Every Claude Code session starts with the same default personality: helpful, thorough, diplomatic. That's fine for a first interaction. By session 50, you want direct, not diplomatic. Concise answers, not thorough explanations. You want Claude to know you're a senior engineer who doesn't need hand-holding, or a self-taught builder who learns by doing.
Without soul.md, Claude treats you the same as every other developer. With it, Claude adapts to how you work.
What goes in it
This isn't a config file. It's a letter to your AI collaborator. Mine includes:
Background. My career path, technical skills, what I'm strong at, what I'm growing into. Not a resume dump, just enough that Claude calibrates its explanations.
Communication style. "Direct and concise. Skip pleasantries. Challenge bad ideas." Claude actually follows this.
Values. What I prioritize when there's a tradeoff. For me: user experience > developer convenience. Ship > perfect. Quality > speed.
What to avoid. Over-engineering, adding features I didn't ask for, sugarcoating problems, long explanations when a short one works.
The result? Claude pushes back when I'm wrong. It keeps responses short. It doesn't pad answers with "Great question!" It knows I'd rather hear "that approach won't scale" than "that's an interesting idea, but you might want to consider..."
Where it lives
In your .claude/ directory. Claude reads it alongside CLAUDE.md at the start of every session.
Two ways to create it
Option A: The interview. Let Claude ask you questions. This works well if you're not sure what to include -- Claude will draw it out of you.
Option B: The resume drop. Share your resume, portfolio, or LinkedIn and let Claude extract the relevant context. Then edit the output -- remove anything too personal, add your communication preferences.
The prompt (interview mode)
I want to create a soul.md file that teaches you who I am as a developer.
Interview me about:
1. My technical background and career path
2. My strongest skills and what I'm actively learning
3. My communication preferences (how direct, how concise, how formal)
4. My values when making tradeoffs (speed vs quality, UX vs DX, etc.)
5. What behaviors annoy me in AI assistants
Ask me 3-5 questions at a time. After the interview, generate a soul.md
file I can place in my .claude/ directory.
The prompt (resume mode)
I'm dropping my resume below. Read it and generate a soul.md file for
my .claude/ directory. Extract:
1. My background and technical skills
2. My career trajectory and what I'm building toward
3. Reasonable inferences about my working style
Then ask me 3-5 follow-up questions about communication preferences
and values that a resume can't capture.
[paste resume or provide file path]
File 5: Hooks -- the guardrails that enforce your rules automatically
The problem it solves
You've told Claude the rules (CLAUDE.md) and who you are (soul.md). But Claude still occasionally commits to main, skips linting, or writes code that doesn't type-check. You catch it in review, but why should you have to?
Claude Code has a hook system: shell scripts that run automatically at key moments. Before Claude acts, after you prompt, after Claude writes code. You describe what you want, Claude generates the scripts and wiring, and the guardrails enforce themselves.
The before/after
Without hooks:
Me: "Add a login form component"
Claude: *writes component*
Me: *runs type-check manually* → 2 type errors
Me: "Fix the type errors"
Claude: *fixes them*
Me: *runs lint* → missing import
Me: "Fix the lint error too"
Three round trips. I'm doing QA by hand.
With hooks:
Me: "Add a login form component"
Claude: *writes component*
Hook: *auto-runs type-check and eslint*
Hook: *finds type error, shows Claude the output*
Claude: *fixes it in the same turn*
One round trip. I never ran a command.
Three hooks, three moments
PreToolUse -- runs before Claude acts:
{
"hooks": {
"PreToolUse": [
{
"matcher": "Edit|Write",
"hooks": [
{
"type": "command",
"command": "bash .claude/hooks/branch-guard.sh"
}
]
}
]
}
}
This one checks if you're on main and warns Claude to create a feature branch first. The hook script receives context (tool name, file path, etc.) via stdin as JSON. Parse it with jq and you can build any check you want.
PostToolUse -- runs after Claude writes code:
{
"hooks": {
"PostToolUse": [
{
"matcher": "Write|Edit",
"hooks": [
{
"type": "command",
"command": "bash .claude/hooks/auto-lint.sh"
}
]
}
]
}
}
The script receives the file path via stdin JSON (tool_input.file_path), then runs type-check and linting on it. Results go back to Claude, who fixes issues immediately. No human in the loop.
UserPromptSubmit -- runs after you type a prompt:
This one's optional but powerful. It can analyze your prompt and suggest relevant context or skills before Claude starts working. Unlike the other two, it doesn't use a matcher. It runs on every prompt.
How to set it up
You don't write the JSON by hand. You describe what you want and Claude generates everything: the shell scripts, the settings.json config, and documentation.
The prompt
I want to set up hooks for my Claude Code project. Help me create:
1. A PreToolUse hook that warns when editing files on main/master
and suggests creating a feature branch first
2. A PostToolUse hook that auto-runs type-check and linting after
Claude writes TypeScript/JavaScript files
3. A PostToolUse hook that auto-runs tests after Claude writes
test files
Generate for each hook:
- The shell script
- The settings.json configuration to wire it up
Hooks should be non-blocking -- show results to Claude, don't halt work.
File 6: MEMORY.md -- the long-term brain
The problem it solves
CLAUDE.md is per-project. soul.md is per-workspace. But some knowledge spans everything: patterns you've confirmed across multiple projects, tools you always reach for, mistakes you've corrected enough times that they should be permanent.
MEMORY.md is Claude Code's built-in long-term memory. It lives at ~/.claude/projects/<your-repo>/memory/MEMORY.md, one per project, derived from your git repository path. Only the first 200 lines load at session start, so it stays concise by design. Unlike the other files, you don't write this one directly. Claude manages it, saving insights as they come up naturally.
How it actually works
Claude saves to memory when:
- You explicitly say "remember this across sessions"
- A pattern is confirmed across multiple interactions
- You correct a recurring mistake
Claude does NOT save:
- Session-specific tasks or temporary state
- Unverified conclusions from reading a single file
- Anything that duplicates CLAUDE.md
What accumulates over time
After a few weeks of active use, my memory file includes things like:
- "User prefers Tailwind + Lucide stack across all frontend projects"
- "Always use conventional commits format"
- "When deploying to Cloudflare, check edge runtime compatibility first"
- "User's communication style: direct, no fluff, challenge bad ideas"
These aren't things I sat down and wrote. They emerged from sessions. That's the difference between memory and the other files. It's organic.
Seeding it (optional but recommended)
You can jumpstart memory instead of waiting for it to accumulate naturally. The interview and resume prompts from soul.md work here too. Claude will save relevant insights to both soul.md and memory.
Or you can be explicit:
The prompt
Remember these preferences across all my projects:
- I always use [framework/tool] for [purpose]
- My commit style is [conventional commits / etc.]
- When I say "make it production-ready" I mean [your definition]
- Never [thing you've corrected multiple times]
Save these to your memory so they persist across sessions.
The full picture
Project layer: SPEC.md → CLAUDE.md → HANDOVER.md
Personal layer: soul.md → hooks → MEMORY.md
The project layer handles context. The personal layer handles identity. Set up both and Claude Code knows your project, your preferences, and where you left off.
Six files. Zero repeated explanations.