Back to Lab

What Actually Goes Into a Claude Code Setup (And Why Most People Skip It)

The Default Claude Code Experience

Here is how most people use Claude Code.

Open terminal. Type claude. Write a prompt. Get a response. Maybe ask a follow-up. Close the session. Open a new session tomorrow. Start from zero again.

No memory of what happened yesterday. No enforcement of project standards. No shortcuts for repetitive tasks. No context preservation between sessions. Just a blank prompt and whatever you can fit into it.

This works. Technically. The way driving a car in first gear works. You will get where you are going. Eventually. But you are leaving 80% of the capability on the table.

I ran Claude Code like this for about a month before I realized the gap. Then I spent weeks building the layers that turned it from a chatbot into something closer to an operating system for my entire studio.

Here is what those layers are and why most people never build them.

Layer 1: CLAUDE.md (The Brain)

CLAUDE.md is a file in your project root that Claude Code reads automatically at the start of every session. It is the single most impactful thing you can set up, and it takes 30 minutes.

Think of it as permanent instructions. Instead of re-explaining your project, your preferences, and your standards every time you start a session, you write them once and Claude Code loads them every time.

Here is what goes into a good CLAUDE.md:

Project context. What the project is. What stack it uses. What the folder structure looks like. Key file locations. This eliminates the "let me explore the codebase" phase that eats the first 10 minutes of every session.

Rules. Things that must always be true. Your color system. Your spacing scale. Your naming conventions. Your commit message format. Your content voice guidelines. These are not suggestions. They are constraints that every output must respect.

Decision framework. When you encounter X, do Y. Feature work goes through this flow. Content goes through that flow. Bug fixes follow this process. This prevents Claude from inventing a new approach every session.

Tool references. Which scripts exist. Which commands are available. Which APIs to use and which to avoid. This turns Claude from someone who guesses how your project works into someone who knows.

A well-structured CLAUDE.md means your first prompt in any session can be "add a new blog post about X" instead of "this is a Shopify store, the blog is at this URL, the publish script is in scripts/, the author should be RAXXO Studios, use EUR not USD, use first person, and by the way the spacing scale is 0/2/4/6/8/12/16/20/24/32/48/64px and the text color is #F5F5F7 not #fff."

That context loading happens automatically. Every session. Without you typing a word. The 30 minutes you spend writing CLAUDE.md saves you 10 minutes per session. After 3 sessions, it has paid for itself. After 30 sessions, you have saved 5 hours.

Layer 2: Commands (The Shortcuts)

Commands are predefined prompts that you trigger with a slash. Instead of typing a paragraph of instructions, you type /deploy or /audit or /publish and the full workflow kicks off.

This sounds like a small convenience. It is not. It is a fundamental shift in how you interact with Claude Code.

Without commands, every task starts with you formulating instructions. You have to remember the steps, the order, the edge cases. With commands, you encode that knowledge once and recall it instantly.

Here is the difference in practice:

Without commands: "Deploy the project to Vercel dev environment first, verify the build succeeds, check that the preview URL loads, then ask me if I want to deploy to production. Use these environment variables. Make sure the branch is clean first."

With a /deploy command: Type /deploy. Done. The command contains all of those instructions, every time, without you remembering them.

I have about 15 commands in my setup. Each one represents a workflow I used to explain manually. Some are simple (3-4 lines of instructions). Some are complex multi-step processes. All of them save time and eliminate the "did I forget a step" anxiety.

The compound effect matters here. One command saves maybe 2 minutes. 15 commands across a full workday save 30 minutes. Across a month, that is 10+ hours of not repeating yourself.

But the real value is not time. It is consistency. A command runs the same way every time. When I type /publish, the blog post goes through the same validation, the same formatting, the same SEO checks, and the same publishing flow. No steps skipped because I was in a hurry. No quality variance between a Monday morning post and a Friday evening post.

Layer 3: Skills (The Expertise)

Skills are the heavy-duty layer. If commands are shortcuts, skills are entire workflows with domain knowledge baked in.

A command says "do these 5 steps." A skill says "here is everything you need to know about this domain, here are the rules, here are the edge cases, here is how to handle errors, and here is the complete workflow from start to finish."

The difference in output quality is dramatic. Compare:

A command for blog publishing might say: "Run the publish script with these arguments, use RAXXO Studios as author, add tags."

A skill for blog publishing knows: the blog format requirements, the TLDR structure, the word count minimum, the voice guidelines, the SEO validation rules, the affiliate link registry, the value protection checks, the syndication targets after publishing, and the blog index rebuild process.

Skills encode expertise. They are the difference between telling someone what to do and having someone who already knows what to do.

I consolidated my skill library from 51 down to 25 recently. The bloat happened because I was creating a new skill for every small variation. The consolidation happened when I realized that one well-built skill with internal routing beats 5 fragmented ones.

A good skill has:

• **Clear trigger conditions.** When should this skill activate? What keywords or contexts make it relevant?
• **Domain knowledge.** What does Claude need to know about this area to do the work properly?
• **Validation rules.** What must be true for the output to be acceptable?
• **Error handling.** What goes wrong in this workflow and how should it be resolved?
• **Output format.** What does the finished product look like?

Building skills takes more effort than commands. A command is 5 minutes. A skill might take an hour to write properly. But a well-built skill produces output that would take you 30 minutes to create manually, and it does it in 2 minutes. Every time.

Layer 4: Hooks (The Safety Net)

I wrote a whole article about enforcement hooks, so I will keep this brief.

Hooks are automatic checks that run before or after Claude Code operations. They catch mistakes without requiring your attention. PreToolUse hooks block bad output before it touches your files. PostToolUse hooks validate what just happened.

The critical thing about hooks is that they work when you are not paying attention. Commands require you to remember to use them. Skills require you to trigger them. Hooks run whether you are focused or exhausted or distracted.

This is the layer most people skip entirely. It is also the layer that prevents the most expensive mistakes. A shipped security vulnerability costs more than every other optimization combined.

Even one hook (say, a brand compliance check) fundamentally changes your error rate. But hooks compound when you stack them. Brand compliance plus accessibility plus security plus spacing enforcement creates a quality floor that nothing drops below. Not on your best day. Not on your worst.

Layer 5: The Napkin (The Memory)

The napkin is the layer that almost nobody knows about, and it solves the most frustrating problem with AI tools: context loss between sessions.

Every time you start a new Claude Code session, context resets. CLAUDE.md gives you project knowledge. But it does not tell Claude what you were working on yesterday, what is blocked, what the current priorities are, or what decisions you made in the last session.

The napkin is a markdown file (typically at .claude/napkin.md) that maintains session state. At the end of each session, you update it with:

• What you accomplished
• What is in progress
• What is blocked and why
• Current priorities
• Decisions made and the reasoning behind them
• Things to remember for next session

At the start of the next session, Claude reads the napkin and immediately has context. No "where were we?" No re-explaining the current state of the project. No losing the thread of a multi-day feature build.

This sounds like a note-taking habit. It is. But when the note is automatically loaded into your AI tool at the start of every session, it becomes something more. It becomes persistent memory.

Before the napkin, my sessions had a 10-15 minute warmup where I would re-establish context. Now they start productive. That is 10 minutes saved per session, every session, forever.

The napkin also prevents a subtle but costly problem: contradictory decisions across sessions. Without persistent context, you might decide on approach A on Monday, forget by Wednesday, and decide on approach B. The napkin keeps a record. Consistency across sessions becomes the default instead of an accident.

Why the Layers Compound

Each layer is useful on its own. Together, they multiply.

CLAUDE.md gives Claude project knowledge. Commands give you speed. Skills give you quality. Hooks give you safety. The napkin gives you continuity.

But watch what happens when they interact:

• Commands reference skills ("run the blog-publish skill with these parameters")
• Skills respect CLAUDE.md rules (the brand rules in CLAUDE.md are enforced by the skill's validation)
• Hooks enforce what skills produce (if a skill generates wrong colors, the hook catches it)
• The napkin tracks what commands and skills have been run ("published 3 blog posts this session, one needs syndication tomorrow")

This is not 5 separate improvements. It is a system where each layer reinforces the others. Remove any one layer and the others still work, but the overall capability drops disproportionately.

The progression looks like this:

Zero-config Claude Code: Smart autocomplete. You explain everything, every time.

CLAUDE.md only: Smart autocomplete that knows your project. Better, but still manual.

CLAUDE.md plus commands: Now you have shortcuts. Speed improves. But no quality enforcement.

Add skills: Quality of complex outputs jumps dramatically. But mistakes still ship.

Add hooks: Mistakes stop shipping. But sessions still start cold.

Add napkin: Sessions start warm. Context persists. The system remembers.

Each addition is a step function improvement. Not linear. The jump from "CLAUDE.md only" to "CLAUDE.md plus commands plus skills" is bigger than the jump from "nothing" to "CLAUDE.md."

Why Most People Stop at Layer 1

If these layers are so valuable, why do most people never build them?

Three reasons.

Upfront effort. Setting up all 5 layers takes a day of focused work. Maybe two if you want the hooks to be production-quality. Most people are using Claude Code to get work done today, not to invest in tomorrow's productivity. The payback period is real (usually 1-2 weeks), but the upfront cost feels high.

Invisible ROI. When a hook prevents a mistake, you do not see the mistake. When the napkin saves you 10 minutes of context loading, you do not feel the 10 minutes you did not spend. The improvements are real but invisible. You have to trust the numbers.

Configuration complexity. Where do the files go? What format do skills use? How do hooks wire into the settings? The documentation exists but it is scattered. Getting the first working setup requires reading through docs, looking at examples, and some trial and error.

These are real barriers. I do not dismiss them. I hit all three myself. What got me through was the frustration of explaining the same project context for the 40th time. At some point, the cost of not configuring outweighs the cost of configuring.

The Starting Point

If you are at zero, do not try to build all 5 layers at once. That is overwhelming and you will quit.

Start with CLAUDE.md. Spend 30 minutes writing your project context, your rules, and your key file locations. Use it for a week. Feel the difference.

Then add 3-5 commands for your most common workflows. Use them for a week. Feel the speed.

Then pick one hook. Just one. Whatever your most common mistake is. Set it up. Feel the safety.

Then build your first skill for whatever complex workflow you run most often.

Then start the napkin habit.

Each step builds on the last. Each step is small enough to do in a single session. And each step makes the next one more valuable because the layers compound.

The Shortcut

I just described a 4-6 week progression from zero to fully configured. That is the organic path. Build each layer, learn from using it, refine it, add the next one.

If you want to skip the learning curve, The Claude Blueprint gives you all 5 layers pre-built. A production CLAUDE.md template. 4 ready-to-use commands. 4 skills for common workflows. 3 enforcement hooks. Napkin structure and maintenance guide. Everything wired together and tested across 12 live projects. 33 EUR.

Whether you build it yourself or start from a template, the destination is the same: a Claude Code setup that works like an operating system instead of a chatbot. The difference is not subtle. Once you have it, going back to zero-config feels like switching from a power tool to a hand drill.

Back to all articles