Big Idea

The argument in one line.

Claude Code has a specific four-layer setup, CLAUDE.md, skills, commands, and hooks, that most developers skip, and skipping it is what limits an LLM's output far more than prompting skill does.

Who This Is For

Read if. Skip if.

READ IF YOU ARE…

You use Claude Code regularly but only have a default or missing CLAUDE.md file.
You keep re-explaining the same project context to your agent every session.
You want a concrete file-and-folder structure for skills, commands, hooks, and subagents rather than a conceptual overview.
You are deciding whether a piece of repeated work belongs in a slash command, a skill, or a subagent.

SKIP IF…

You already have a mature CLAUDE.md, skills library, and hooks setup in place.
You are looking for prompting technique rather than project configuration (the creator says that is the next video in the series).

TL;DR

The full version, fast.

Most Claude Code setups fail not because of bad prompting but because the configuration layer is missing or bloated. The video demonstrates a four-layer system: CLAUDE.md as the always-loaded briefing document, skills as on-demand context loaded when relevant, slash commands as reusable manual prompt templates, and hooks as deterministic code that fires on lifecycle events and cannot hallucinate. It builds each layer live in an example repo, then closes with three failure modes: an oversized CLAUDE.md, missing self-improving instructions in skills and commands, and global hooks silently affecting every project. The actionable conclusion is to keep CLAUDE.md under roughly 200 lines, push detail into imported files, and end every skill and command with an instruction telling the agent to update that file when it hits an uncovered case.

Free for members

Chat with this breakdown — free.

Sign in and you get 23 free chat messages on us — ask for the hook, quote a framework, find the exact transcript moment, generate a markdown action plan. Bring your own key when you want unlimited.

Create a free account →

Chapters

Where the time goes.

00:00 – 00:30

01 · Cold open

The creator states the premise: most developers skip Claude Code's intended setup, which limits output far more than prompting does.

00:30 – 01:00

02 · What CLAUDE.md actually is

CLAUDE.md is the first file Claude Code reads each session, a briefing document so the agent doesn't need re-explaining every time.

01:00 – 01:50

03 · Optimize your CLAUDE.md

Write CLAUDE.md like onboarding a senior developer: skip what a competent hire would already know, include only project-specific context.

01:50 – 04:53

04 · Building a CLAUDE.md example

Live-builds the file section by section in the TriageBoard example repo: Project Identity, Key Commands, Conventions (using an @docs/conventions.md import), Hard Stops, Known Gotchas, and Links.

04:53 – 05:48

05 · The four-layer system

Names the mental model: CLAUDE.md is always loaded, skills load on demand, subagents are isolated instances, hooks fire deterministically on lifecycle events.

05:48 – 08:10

06 · Skills

Creates .claude/skills/<name>/SKILL.md live, explains skills give the agent additional on-topic context and load automatically when relevant, and should end with a self-improving instruction line.

08:10 – 10:30

07 · Commands

Creates .claude/commands/verify.md, contrasts the single-file command structure with skills' per-skill directories, and builds a reusable /verify slash command.

10:30 – 13:02

08 · Hooks

Creates .claude/settings.json defining session-start, pre-tool-use, post-tool-use, stop, and post-compact hooks; stresses hooks are code, not instructions, and global hooks (in ~/.claude) apply to every project.

13:02 – 15:22

09 · Subagents

Creates .claude/agents/codereviewer.md, explains a subagent is an isolated Claude instance with its own system prompt, tool restrictions, and pinned model (Sonnet), distinct from a slash command.

15:22 – 16:42

10 · Common mistakes and sign-off

Three mistakes: CLAUDE.md over ~200 lines, missing self-improving lines on skills/commands, and untested global hooks bleeding across projects. Teases a follow-up video on prompting.

Atomic Insights

Lines worth screenshotting.

CLAUDE.md should be written like an onboarding document for a senior developer: if a competent hire would already know it, it does not belong in the file.
A CLAUDE.md over roughly 200 lines bloats every single session, because its entire contents load into every prompt.
CLAUDE.md supports @imports, so long style guides or conventions can live in separate files and be referenced rather than pasted inline.
Skills load on demand based on what the agent is doing, while CLAUDE.md content is part of every prompt regardless of relevance.
Hooks are the only layer that cannot hallucinate, because they execute deterministic code around lifecycle events instead of being instructions an agent interprets.
A slash command tells the current Claude session what steps to follow; a subagent spins up a separate, isolated Claude instance with its own system prompt, tool restrictions, and even its own pinned model.
Pinning a subagent to a specific model (for example Sonnet) means it uses that model regardless of what the parent session is running, which is useful for cost control across a multi-agent setup.
Global hooks placed in the user-level Claude directory apply to every project on the machine, not just the one they were written for, so they need testing before being relied on.
The fastest way to create a new reusable command is to do the workflow manually once with Claude, then prompt it to export what it did as a generic command.
Ending every skill and command with an instruction to update the file when an uncovered case is hit turns the setup into something that maintains itself instead of accumulating silent gaps.

Takeaway

Configuration, not prompting, is what most Claude Code setups get wrong

WHAT TO LEARN

An AI coding agent behaves consistently when its project context is structured into the right layer, not when the user writes cleverer prompts.

A standing project-context file should read like onboarding notes for a competent new hire: only include what that hire would not already know.
Any reference document that grows past a couple hundred lines starts costing performance if it is loaded on every single request, so long detail belongs behind an on-demand reference rather than inline.
Deterministic enforcement, code that runs automatically, is more reliable than written instructions for anything that must never be skipped, because instructions can be misread or ignored while code cannot.
Isolating a sub-task in its own context window, with its own permissions and even its own model choice, keeps a specialized job from polluting or being distorted by the main session's history.
Documentation that includes an explicit instruction to update itself when it's found lacking stays accurate over time instead of quietly drifting out of date.
Settings meant to apply narrowly should be scoped and tested deliberately, since anything configured at a global or default level silently applies everywhere unless proven otherwise.

Glossary

Terms worth knowing.

CLAUDE.md: A markdown file at a project's root that Claude Code automatically loads at the start of every session, acting as a standing briefing document about the codebase.
@import: A syntax inside CLAUDE.md that references another markdown file's contents instead of pasting them inline, keeping the main file short while still pulling in detailed guidance when needed.
Skill: A directory under .claude/skills containing a SKILL.md file that Claude loads on demand when it judges the skill relevant to the current task, rather than on every session.
Slash command: A single markdown file under .claude/commands that defines a named, manually invoked sequence of steps the current Claude session should follow when the user types /command-name.
Hook: Deterministic code, configured in a settings.json file, that runs automatically at defined lifecycle events (session start, before/after a tool call, session stop, after context compaction) and cannot be skipped or hallucinated.
Subagent: An isolated Claude instance, defined by a markdown file under .claude/agents, with its own system prompt, tool permissions, and optionally a pinned model, that runs separately from the main session's context.
Self-improving instruction: A closing line added to a skill or command telling the agent to update that file whenever it hits a case the file doesn't cover, so the documentation keeps itself current.

Resources

Things they pointed at.

00:00linkcode.claude.com/docs ↗

00:00linksupport.claude.com ↗

Quotables

Lines you could clip.

15:54

“Hooks can't hallucinate. They just run because it's purely code.”

Sharp one-line distinction between instructions and enforcement→ TikTok hook↗ Tweet quote

01:06

“If a competent developer would already know it, it doesn't go in.”

Compact rule of thumb for what belongs in CLAUDE.md→ IG reel cold open↗ Tweet quote

22:09

“The slash command tells the main Claude instance what steps to follow. But a sub agent spins up in a separate Claude instance with its own context.”

Clarifies a commonly confused distinction→ newsletter pull-quote↗ Tweet quote

The Script

Word for word.

Read-along

Don't just watch it. Burn it in.

See every word as it's spoken — crank it to 2× and still catch all of it. The same dual-channel trick behind Amazon's Kindle + Audible.

metaphor

00:00I've been using Claude code every day for months now. And in the beginning, I was just sending basic prompts and still putting in a lot of manual effort to get the outcome that I wanted. But Claude actually has a specific setup that it's designed for, and most developers skip all of it, which drastically limits the output of your LLM.

00:18So in this video, I'll explain that exact setup. And by the end, you'll have something that actually remembers your project, follows your conventions, and catches problems before you do. We'll start with the Claude MD file.

00:30This is the first file Claude code reads when it opens a session in your projects. So you can think of it as a briefing document. It's everything Claude needs to know to work in your code base without you having to re explain everything every time.

00:43We're gonna use this example project to demonstrate creating a proper Claude setup. So most Claude MD files that I see are either missing entirely like they are in this example, or there are 300 lines of vague guidelines, which just causes Claude to mostly ignore it.

00:59So the best structure for this file is to treat it like you're onboarding a senior developer to the project. If a competent developer would already know it, it doesn't go in. But if it's context that they would need to know, then make sure you add it into your Cloud MD file.

01:15Now this file lives in the root directory of the project. So we're gonna create it now. You'll just type in Cloud dot MD, very similar to your readme.

01:25Now my typing's really bad and really slow. So I pretyped everything so you don't have to sit through all of it here. I'm just gonna be copying and pasting every section that I prewrote.

01:34So first, we'll start with just the name, and we'll have that section defined. And what I found best for your LLM to be able to properly digest all the information in your Cloud MD file is to separate it into sections. So the first section we're going to have is our project identity.

01:52And I'll copy in the title of that section. And what this is is saying what the repo does in about two sentences, what the stack is and what it's not.

02:03And this is just giving some basic background information for your agent when it's just starting up with the project. So this is what I wrote. Very simple, bare bones project that we have.

02:12So our MD file is going to be pretty short. However, you should remember that we're always optimizing to keep it as lean and short as possible. So remember to be as concise as you can here.

02:25Now the next section we're going to have is the key commands. And this is basically the exact CLI commands that you run more than about once a week on the project. And all I have here is just a bulleted list of all of the commands with a very brief explanation.

02:43You can see short and succinct. That's the best way to write out this file. And then the next section is going to be conventions.

02:52So this is just naming file structure and patterns that this code base actually uses, and you want it to stay consistent throughout all of your code as well as your AI engine's code. Now one more thing to keep this file as lean as possible is ClaudeMD supports imports.

03:12So instead of pasting a long style guideline in line into this file, you can just reference it. So what we're gonna do is create a conventions MD file in our docs.

03:23So here, I'm just adding the at to import our docs convention dot MD. If we go to my docs directory, it's empty.

03:31So all I'm gonna do is create a new file inside it and name it conventions dot m d. Okay.

03:40And in my conventions empty file, it's just going to be explaining all the conventions that I want to stay consistent in this code base.

03:50So, again, very sure all bullet point information. Keep it as succinct as possible when you're writing these files out. Okay.

03:59So back to our CloudMD file. After conventions, we're gonna add in hard stops. So what this section is is just anything that Claude should never do without your explicit yes.

04:12And again, I just have short bullet points, and I'm gonna copy and paste those in here. Okay. The next section, we're gonna have some known gotchas.

04:24This is basically common errors that you run into or other agents have run into, and you just wanna spell them out and spell out the solution. So your agent has that context to solve as fast and efficient as possible. Okay.

04:39And the very last section we're gonna add into this file is links. So this is just gonna be passed to files and docs that matter. And again, just very clear bullet point information.

04:53So now that we finish our CloudMD file, we're gonna talk about the four layer system for your Cloud Code setup. So first is your CloudMD file, which we just went over. It's a file that is always loaded in, and everything in it is part of the context on every single prompt with your agent.

05:10Then you have skills, which load on demand based on the agent's need at a given time. Then there's sub agents, which are isolated cloud instances that have their own context. And then you have hooks that fire automatically at specific events and execute deterministic code.

05:27So each layer does something that others can't. The next layer we're gonna build out is our skills. So your skills live in your dot claw directory in your project.

05:38As you can see, this doesn't exist yet in our template. So we're going to add in a new folder, and it's going to be titled dot claw. And within there, we're going to add another folder that is going to be for our skills.

05:53Now, this just to find our skills, but each skill is its own directory with a skill dot m d file inside it. And we're going to now create another folder, and that's going to be the name of the skill.

06:06So we're going to create a skill for this project specifically.

06:19And that's the name of the skill. And then within that, we're going to create a new file for our skill dot m d.

06:27Okay. Now Claude automatically loads this file when it's relevant to what you asked, which is why they're all separated into their own directories within the skills folder.

06:39And the purpose of having skills is to give your agent additional context on a specific topic. So here, we're gonna talk about the triage domain for this triage board project. And all I'm going to do is, again, copy and paste what I already wrote.

06:56And here you can see I'm just naming the skill, having a short description, and then adding additional context all separated with additional headers here.

07:06Now, this last line, if you hit a blocker not covered here, solve it and update this file for next time. This is critical because it's adding in a self improving line. So Claude is now continuously updating the commands and you don't have to worry about any maintenance here.

07:22Adding in a self improving line is something that you would have at the end of every single skill that you write out. You can also add in additional context into this directory. So for example, we can add in a reference MD file.

07:36So I'll add in a new file here and add in some reference information too.

07:49So again, all of this is just specific additional context that you want your agent to understand for a specific topic. Now, as you continue to write out skills, they're all going to be their own directories that live within this skills directory in your dot Claude folder within your project.

08:06So you can continue following the same pattern every time you wanna create a new skill for your agent. Now that skills are covered, we're going to move on to building your first command. For this, we're going to build out a verify routine because most likely, you'll be able to use this one often and in other projects, not just this example product that we have.

08:24Now for commands, there's a very similar file structure as there is for skills. So this also lives in the dot claw directory, and we're going to create a new folder in here titled commands.

08:39Okay. So our verify command is going to be a slash command. You'll be able to call it by just typing in forward slash and then the name of the command inside your open Cloud instance.

08:52So unlike skills where you have to create a new directory for every single new skill, for commands, it's just a single markdown file per command. So all we have to do is create a new file in the commands folder, and we're going to name it what we want the command to be.

09:08So we'll name this verify dot m d. Okay.

09:15And I'm just going to copy over again what I have from my verify commands. So it just has the name and the description. And then it has all of the steps that this command needs to execute.

09:28And then at the end, we have the same line for the agent to continuously improve the command itself. So as you can see, commands should also have self improving instructions just like skills do.

09:39Now you can just invoke this by opening up your Claude instance and typing forward slash verify, and then it's going to execute all of these steps in order and complete the command. Now as you wanna continue to create more commands, it's going to follow the same steps, and you'll have multiple MD files in this commands folder.

09:57As you go on to create your own commands, the fastest way to build a new command is to do the workflow manually once with CloudWatching. Then prompt it to export what it just did as a commands. Make it generic, and then make sure that you add in a line defining self improving instructions at the end.

10:15Cloud Code even ships a run skill generator that captures your project's clean environment setup into a reusable per project skill, which is a great head start when you want to set up a dev server. So that covers everything for commands.

10:30And up next is writing hooks. So hooks should be used for all non negotiables. Hooks are the layer that executes deterministic code around life cycle events.

10:41So they're not instructions. They're code. And the reason they matter, unlike everything else in Cloud Code, is that hooks can't hallucinate.

10:49They just run because it's purely code. So let's go through setting up a few hooks. And I'll talk about just some common helpful ones that you'll probably want in your own projects.

10:59Hooks don't have their own folder like commands and skills, but they are still in your dot cloud directory. So I'm going to create a new file in the dot cloud directory, and we're going to name it our settings.

11:13Oops. Sorry. One more time.

11:16And we're going to name it settings dot JSON. Okay. So this JSON file is going to define all of your hooks.

11:26And I'm just going to copy everything that I have here, and then we can read through what's actually happening. So all of these hooks here are life cycle events that you should be able to easily port over to your project. First, we have session start.

11:40And all this does is load context for your agent. The next is your pre tool use, which is used to inspect or block a command before it runs. And then you have your post tool use.

11:52So this is used to auto format after any edits in your code base. And then we have stop that fires at the end of a session to remind you or mechanically enforce that the verification should run on your code base.

12:08And then the last one is your post compact, and that is to reinject critical instructions after the context gets compressed. So these are all pretty helpful hooks that are kind of generic that you can pretty easily with a few edits transfer over to your own code base.

12:27And one other thing to point out with hooks is all of these hooks that we just created live inside our triage board directory. So these are specific to a project. If you want to create global hooks, you can create them in your Tilde Cloud directory and do the same setup with your settings dot JSON file.

12:47But these hooks are going to be applied to every single Cloud session that you have with any project on your computer, where the hooks that are specified within a product directory only apply to that specific project. That's everything with hooks.

13:02And the last piece that we'll go over is going to be sub agents. So we're going to create a new directory in our Cloud folder, and that is going to be titled agents.

13:14And in here, this is where all of your sub agents will live. And this setup is similar to commands where each sub agent has its own MD file. So what we're going to be creating is a code review agent.

13:27So we'll do codereviewer.md. Now what this does is it's using the sub agents feature in Claude. So every agent here, when it's called, is going to create an isolated Claude instance with its own system prompt, tool restrictions, and model selection.

13:43And also, it's going to run separate from the main Claude code session. So this is everything that we have for our Code Reviewer agent.

13:52The name field specifies the command that you're gonna use to call the agent. So forward slash Code Reviewer is what's going to spin up and start the agent. And it runs code as its own Claude instance.

14:04And we also specified the model here. It's going to run with its own Claude instance. And because the model is specified here, it's going to use that model.

14:14So here, we specified Sonnet. No matter what any other AI agent is using throughout this code base, this sub agent is always going to be using Sonnet.

14:24Now remember this feature because this is going to be helpful in the future when we talk about the adviser strategy later on in the series, which saves you a lot of money on tokens. So keep a note of that. So it also has its own tool set, which is defined here.

14:38You can see it has no right access, and it has a focus preloaded system prompt that focuses on this agent's priorities. Now, this feature seems very similar to the verify slash command that we created earlier, but it's actually pretty different.

14:54The slash command tells the main Claude instance what steps to follow. But a sub agent spins up in a separate Claude instance with its own context and its own instructions, and it's isolated from the parent session's conversation history.

15:08So in practice, you'd invoke this sub agent with forward slash code reviewer, and it reviews the changes without the review logic polluting your main session context. Now that covers pretty much everything for an optimized setup.

15:22Lastly, I'm gonna go over three common mistakes just to make sure that you have all the information that you need to set up your own project. So the first mistake is having a Claude MD file that's just too long. If it's over about 200 lines, then you're bloating every session.

15:38So cut the content drastically and then import any additional information that you think is still necessary. Also, when you're reviewing your Claude MD file, remove all procedural information And instead, put that into either a command or a skill.

15:53Now, the second common mistake is having commands and skills without a self improving line. So make sure that you add it to everything you write so you don't have to worry about the maintenance piece. And lastly, the third common mistake is forgetting that hooks in the global setting apply across every single project.

16:11So make sure you test them before you rely on them. If you've been using Claude code without any of this setup, everything in this series will make a lot more sense once you implement everything we just talked about. I'll link the starter template that we just used in today's video in the description.

16:27And the next video in this series covers prompting. So we'll discuss why most prompts break in production and the pattern that actually fixes them. If you have any questions, leave them in the comments below, and I'll be sure to help out where I can.

16:40See you in the next one.

The Hook

The bait, then the rug-pull.

Most Claude Code tutorials stop at installation. This one starts from an empty repo and builds the four-layer configuration system, CLAUDE.md, skills, commands, and hooks, that actually determines whether an agent understands a codebase or has to be re-briefed every session.

Frameworks

Named ideas worth stealing.

04:53model

The four-layer Claude Code system

CLAUDE.md (always loaded)
Skills (load on demand)
Subagents (isolated context)
Hooks (deterministic, event-driven)

A mental model for which configuration layer to reach for: CLAUDE.md for standing project context, skills for on-demand topic knowledge, subagents for isolated multi-step work, hooks for anything that must never be skipped.

Steal forStructuring any Claude Code project's .claude directory instead of dumping everything into one CLAUDE.md

02:19list