Learn 95% Of Claude Code In 30 Minutes transcript

You see people online shipping entire apps with clot code, building milliondoll tools overnight, fixing bugs and code bases they have never even read before. Then you actually use it and it burns through your usage limit in an afternoon. It ignores half the instructions you give it and it confidently breaks the one thing that was already working. That gap is the entire reason this video exists. I have spent months living inside this thing and I'm going to give you 95% of what actually matters.

Not another beginner tour. I'm going to cover the one file that changes everything. How to stop it from quietly burning your money. How to turn it into a super coder and exactly what to do when it goes off the rails. By the end of this video, the tool that you used to fight with will become the best employee you have ever hired. Let's get started. Before you type a single thing, here is the mental model that makes all of this click.

There are three clouds and each one is built for a different job. The first is the Claude app. The normal chat that is for questions. You want to know something, you want a quick lookup, you want it to explain an error or draft an email. You ask, you get an answer, you move on. The second is co-work. That is for getting actual work done on your computer. You can point it at a messy folder and have it sort every file into place.

You can hand it a 100 PDFs and have it pull every invoice total into one clean spreadsheet. It does the boring work you would normally do by hand. And the third is clawed code. This is the one that writes code. It lives inside your project and it builds a full app from scratch, a bug fixed across your entire codebase, a new feature added to something you already shipped. That is the one idea for this whole video. Claude Code does not suggest code.

It does the work in your actual project and then shows you what it did. And it can do that the second you install it. So, let's do that next. Getting it installed takes about 2 minutes. And there are two ways to do it. Pick whichever one sounds less scary for you. The first way is the terminal. You can run one command on there and once you have it installed, all you need to do is type claude, hit enter, and you're in.

But if you'd rather not use the terminal, don't worry because there's a much easier way and it is the one I would point most people to. You can install the claw desktop app onto your computer and find claw code right inside it. Either way, you end up in the same place. The next step to get started would be to point it at a folder on your machine. If you're editing a codebase, then you can point it at your codebases folder.

Or if you're working on a new project, then you can just point it at any new folder. And from that second, cloud code can see everything inside that folder. And that is the whole point. Which is why the first thing to understand is not a feature. It is who is allowed to do what. When clot code is about to change a file or run a command, it can stop and ask you first. That is called permission mode and you can change it in one click.

There are four different permission modes. Auto is the default and it is a fix for the constant asking. A second model checks each action in the background. So it only stops you for what actually matters. Manual is the opposite. It asks before every change, but it is super spammy. Except edit stops asking about file edits and just makes them while you watch. And plan does what it says. It only plans but does not make any changes until you approve its plan.

There's another setting here which is bypass permissions. If you set it to enable, then Claude will never ask for your permission before doing anything ever. I recommend you have it on auto for most of your work. If you're a beginner, start with the bypass permissions disabled, so turned off. But once you know how all of it works, then you can choose to enable that setting and have it work faster since it doesn't have to ask for your permission anymore.

And the reason you can trust it more over time is that you can teach it how your project works permanently with one single file. And that one file is the biggest unlock in this whole tool. If you take one thing from this video, take this section. Claude.m MD is a plain text file you put in your project. Every time cla code starts, it reads that file first. So it is a memory that survives. It is where you write down how your project works.

So you never have to explain it again. Without it, you are retaching the same context every single session. But with it, Claude code walks in already knowing your rules. Now, here is how to make it actually good because there is a trap. The trap is dumping everything inside of that file. The whole file tree, every dependency, a paragraph explaining the architecture. And here's why that hurts you. This file gets loaded into memory on every single session.

So, every line you put it in, you pay for on every single message you send in it. And afterwards, if you stuff it full, then you're burning tokens all day and burying the rules that actually matter. So, it ends up following them less. So, here is the fix. And you write none of it yourself. You get clawed to write its own instructions, and you just tell it what to leave out. You can paste in this prompt that you see on screen right now.

By the way, every prompt I share in this video is available inside the link in the description below, so you can copy paste them easily. Everything is free and you can sign up if you don't want to miss any future drops by inputting your email only if you want to. Anyways, that prompt gives you a tight high signal file in about 30 seconds with none of the bloat. And if your claw.md has already grown into a monster, you do not start over.

You run slashd doctor and it goes through the files, shows you everything Claude can already figure out for itself and trims down the moment you say yes. One honest catch though, this file is guidance. It's not a cage Claude abides by. Claude reads it and almost always follows it, but not always. For something that has to happen every time, like running your tests before you commit, you want a hook, not a line in here.

And even a perfect claw.md gets undone by one thing that quietly fills up in the background while you work. That is context. This is the habit that decides whether clot code stays sharp or slowly falls apart on you halfway through a session. Cloth code has a memory limit for a single conversation. It's called the context window. Everything it has read and done this session sits inside it. And here's the part nobody tells you.

As that window fills up, the tool gets worse. It starts forgetting your early instructions. It starts repeating itself and it starts re-breaking things it had already fixed. It is not getting dumber, it's getting full. So now you have the three moves. You can check the fullness with slash context or by looking at that little wheel next to your chat window, which is quicker and easier to keep an eye on. And to declutter, you can either use /compact, which summarizes your session so far, and clears context, so you start fresh again.

You do lose some detail by doing this, but it keeps the general gist of your session. Or you can use slashclear, which clears your context entirely. That is the equivalent of starting a new chat. And I'd recommend you do that when you're done working on whatever you're working on. The honest catch is that slash compact is not free. It squeezes the conversation down and things fall out in that squeeze. So the professional habit is not to compact endlessly.

It is to finish a task then slashcle and start the next one clean with your claw.md carrying the important stuff across. This is what really is happening when it feels like it got dumb halfway through. It did not get dumb. the window just filled up and you did not catch it. So, watch that meter. It is the single most useful habit in this tool. And the reason this matters even more than it sounds is money. Because a full context [snorts] window is not just slower, it is more expensive.

So, let's talk about what this actually costs to run. Let me be straight about cost because it caught me off guard when I started. CL code costs money to run and how much depends almost entirely on two things you control. Number one is which model you use and number two is how full your context gets. Every message you send carries the whole conversation with it. So a long bloated session does not just get forgetful, it gets expensive because you're paying to resend every single message you've sent before every single turn.

Here is the mental model that actually saves you money. The bigger models like Opus and Fable are your senior engineers. They're brilliant, expensive, and a waste of money on small jobs. The faster models, which are Sonnet and Haiku, are your juniors. They're cheap, quick, and perfect for the boring 80% of the things you do. Here's the quick reference for when to use each model. Haiku is the fastest and the cheapest.

Use it for simple mechanical tasks, things that you feel anyone could do when given instructions to follow. Sonnet is the generalist you will live in for routine and well scoped work. Opus is the expert for complex problems that need real judgment. And Fable is the specialist for the genuinely hard stuff, the smaller one keeps failing on. The bigger and more ambiguous the problem, the bigger the model should be. One important thing though on switching models, you can set your model either at the very start of a session or partway through.

I do highly recommend that you set it at the start. And I mean that. Here's why. Every model keeps its own separate cache of your conversation. So the moment you switch models midsession, the new one has none of the conversation's cash and it has to reread your entire conversation from scratch at full price. Clot code will even stop and ask you to confirm the switch because it knows it is about to cost you. So pick your model first and leave it.

So clot code is not expensive if you drive it properly. It is only expensive if you put your senior engineer on every tiny job and never clear the desk. I had a client that texted me last week asking me why his usage limits maxed out. And it turns out he used Fable for every single thing, including renaming files. By the way, if you want to go deeper on why cloth code costs what it does and why those usage limits hit so fast, I made a whole video just on that.

It is linked below. Now, everything so far has been about controlling the tool. The next few are about making it dramatically more powerful. Starting with skills. A skill is a saved procedure. Instead of explaining how to do a repeated task every time, you install or create a skill once and cla code just knows how to do it correctly and forever. Think of it as the difference between telling a new hire how to do something and handing them the company handbook that already has it written down.

And guess what? You already have some skills. Claude code ships with skills built in. You can type /code- review and it goes through your changes hunting for real bugs, not style. Or type /security-review and it looks for holes in what you just wrote. Both are already installed for most of us. So here are three more skills I would install on day one. The first one is Anthropic's own skills repo. One command adds the marketplace.

One more installs the document pack and after that clot code builds real word files, real Excel sheets, real slide decks and PDFs so on and so forth. The second one is superpowers. It stops Claude from writing code the second you ask. It interviews you first. It writes a plan. It builds it test first, then sends sub agents to review its own work. And the third skill is oh my clot code. It routes each job to a different model on its own.

Cheap ones for the small work, expensive ones for the hard work. That is the section you just watched running without you. And installing skills isn't too hard. You can just send the link to these skills to claude code and ask it to install them for you. Like I said before, everything I mentioned is in the first link in the description, so you can fetch everything on there. I also have two videos on skills you could watch to power up your agent.

I'll link both of them down below as well. The honest catch here is that a skill is not just text. It can run shell commands on your machine. So before you ever install the skill, ask Claude to read it and make sure it's safe to install. So skills are how you stop repeating yourself. Set it up well once and it compounds over time instead of resetting every session, but a skill still runs inside one claude. The next feature is how you get several of them working at once, which is where Claude stops feeling like a tool and starts feeling like a team.

This is one of the most powerful things in this whole tool and it is worth setting up properly. A sub agent is a second clot that your main claude can hand the job to. It runs in its own separate context. It does the task and reports back with just the answer, which means the messy tokenheavy work happens off to the side and your main session stays clean. The honest catch is that sub agents cannot talk to each other and each one is its own cost.

So this is not about spawning 10 agents for a thumbnail. It is about pushing the big dirty reading and searching jobs off your main thread so your context stays clean. So if a task would flood your context, ask clot to hand it to a sub agent and keep your own desk clean. That is the move for anything that is large and tedious. And sub aents are one way to extend clot code. The other way is to plug it into the outside world.

And there are two ways to do that. One of which quietly wrecks your context if you pick it wrong. To do real work, cloud code often needs to reach outside your folder, your databases, your GitHub, a browser, or maybe an external service. There are two ways to give it that reach and picking the wrong one can silently bloat every session. The first way is MCP which stands for model context protocol. Think of it as an adapter that plugs a service directly into clot code with permissions and with structure.

The second is just letting clot code use the normal command line tools you already have like the GitHub command line tool. Here's the trade-off that actually matters. MCP is powerful and clean to use, but every connected MCP server loads its instructions into your context whether you use it that session or not. The command line approach is lighter on context, but it can get messier and less controlled. So, the rule I would use here is this.

Connect an MCP server when you will genuinely use it a lot and want it structured and safe. Lean on the command lines for one-off jobs where you do not want that weight. And do not connect an MCP server you never use because you are paying for their instructions in every message. I recommend you regularly go into your MCP connections by clicking on connectors, manage connections, and turning off connectors you haven't used in over a month.

MCP is fantastic when it earns its place and a quiet context tax when it does not. So, be picky about what you plug in. All right. Everything so far has been the big features, the ones you set up once, but there's a layer underneath all of those small commands, most of them one or two characters that decide how fast you actually move. And those we're going to cover next. Everything up to here has been the big features.

These are the small ones. They take seconds to learn. and they are the difference between fighting this thing and flying with it. Hack one, make it interview you before it builds. You can put use ask user question until you reach clarity at the end of your prompt and it will fire multiplechoice questions at you. You can pick with the arrows key or just, you know, click on it with your mouse if you're on the desktop app and then it builds the thing you actually wanted.

I get more wrong builds out of a vague ask than out of hard problem. Hack two, turn the thinking up. There is a dial for how hard it thinks and you set it with /effort or by clicking on your model and picking your effort level from there. The levels are low, medium, high, extra, and max. And if you only want one message to get the deep treatment, then you can put the word ultrathink anywhere in that prompt. It does cost more because it is literally thinking for longer.

So save it for the problems that genuinely deserve it. Hack three, point it at files with the at symbol. You can type at and start typing a file name and it pulls that exact file in. You stop it hunting around your project and you stop it reading the wrong thing. Hack four, never sit and wait. You can type your next prompt or your next instruction while it is still working and it cues up behind the current one. And if you want it to stop, then you can hit escape.

It stops where it is and it keeps the work it already did. Hack five, show it, don't describe it. If something looks wrong on your screen or on your website, paste the screenshot straight into the prompt. Describing a broken layout in words is slow and it loses detail. Let it look. You can even click on the pointer arrow if you're working on a website and click on the exact element you want it to look at and work on.

And hack six, ask side questions with slash by the way or actually slashbtw which stands for by the way. This one is my favorite. It lets you ask a question about your session without adding it to the history. So you get your answer and your context stays clean. I'll give you an extra hack just because I love you and that is one actually worth tens of other hacks. It is slashbatch. It takes one big job, it splits it into as many as 30 separate pieces, runs them all in parallel in their own copies of your project, and it opens the pull request when they're done.

The honest catch is that every one of these is speed, not judgment. Slash batch will happily open 30 poll requests full of the same wrong idea. and ultra think on a vague prompt just buys you a confidently wrong answer. Slower and more expensive. So, the prompt itself still has to be good. If I were picking two of these to start with today, I would take the interview one and slash. By the way, those two changed how my sessions run more than anything else on this list.

And every single one of these makes the tool move faster, which means you reach the moment it goes wrong sooner, not later. Look, things will go wrong. And knowing how to get out is the difference between a bad afternoon and a productive one. So, let me break something on purpose and show you the way back. There are three ways clawed code goes wrong, and each of them has a fix. The first is the loop. It tries a fix, it fails, it tries almost the same fix, it fails again, and it will happily do this forever, burning your tokens.

The second is it can be confidently wrong. It changes something based on a a misunderstanding and now your code is worse. And the third is it simply did too much and you want to go back. So here is your recovery kit. When it loops, do not repeat yourself. Change the instruction entirely. When it is confidently wrong, make it explain before it acts. And when it has made a mess, you can use slashre for the conversation.

Knowing these tips doesn't mean you're never going to hit failures or that you're going to fail less often than anyone else. It just means that you're going to have an escape hatch ready before you start. And that same mindset, uh, safety net before you need it matters even more for this next part because it is about the code you never actually looked at. Now, the part that can actually hurt you. Clawed code will build a working app for you and you can ship it without ever opening a file it wrote.

But running and safe are not the same thing. So, instead of a checklist you will not follow, here's the simple thing that does it for you. It is an official plugin by Anthropic called Security Guidance. If you are in the terminal, you can run the install command on the screen right now. Or if you're in the desktop app, you can hit the plus button next to the prompt. Go to plugins, then add plugin. Either way, you install it once, and after that, there's nothing to run and no command to remember.

It reviews Claude's code while Claude is writing it on three levels. Every file that gets written is pattern matched for the dangerous stuff. And that layer is free because there's no model behind it. At the end of every turn, it diffs what changed and sends it to a security review in the background. And on every commit, it runs a deeper review that reads the surrounding code first. And it is not the same cloud creating its own homework.

That review is a separate call with a fresh context and one instruction which is to find problems. And if you just want one pass on demand, you can run /security-review and that covers your current batch. The honest catch is that none of this blocks anything. It does not stop the write. It does not stop the commit and the review can still miss things. And this whole plug-in is built out of hooks, which is the next thing because hooks are how you make clot code.

Do this for anything you want. Let's talk about hooks and remote control. Those two things are how cloth code stops being something you babysit and becomes something that runs on its own. Hooks are automatic rules that fire on their own. In other words, every time a trigger happens, the hook activates. For example, every time it finishes editing a file, I can set a hook for it to run specific tests. You set a hook once and it happens forever without you having to ask.

Hooks live in a settings file, either inside your project folder or in your home folder. But you do not write that file yourself. You can tell claw code in plain English, add a hook that runs my tests every time I edit a file. It writes the rule, it saves it, and it goes live straight away without restarting everything. Then you can type /hooks to see every rule you have running and where each one came from. Remote control is one of my all-time favorite features.

On your computer, you can type / remote-control. Then you open the clawed app on your phone, go to code, pair it, and from that moment onwards, your session is sitting there waiting and you can start editing your codebase from anywhere in the world from your phone. The work is still running on your computer with your files, your project, and your tools. Your phone is only becoming the steering wheel. So you can approve a permission prompt from the sofa, send it a new instruction and watch that output land.

Put those two hacks together and you can see where this goes. It tests itself as it works and you steer it from your pocket. The honest catch is that remote control needs your computer to be awake and that session still running. If you close the laptop, then it stops. And on hooks, automation multiplies mistakes as fast as it multiplies work. A hook that runs the wrong command runs it every single time it will fire. Which raises the honest question, when should you not use this thing at all?

Look, I'm not going to pretend cloth code is the answer to everything, and neither should you, because that is how people waste hours. Claw code is the wrong tool when the job is tiny and you already know the answer for it. If you need a fast question answered that has nothing to do with a codebase. Just ask claude chat. The honest catch on this whole video is that clawed code makes a mediocre engineer faster and a careless engineer dangerous.

It amplifies whoever is driving it. It does not replace the judgment. It scales it in both directions. So, I do not reach for it for everything and I would tell you not to either. The trick is knowing the three or four things it is genuinely great at and using something simpler for the rest. So, let me leave you with exactly how to actually start without drowning yourself. Here is the thing I wish someone had told me at the start.

You do not need to master everything in this video today. So, here is a 7day path instead. And each day removes the reason you could not go further the day before. Day one, install it, point it at a folder, and make one small change in plan mode. Day two, write your claw.md with the prompt I gave you. Every session after this one, start smarter. So, this is the day that pays you back the longest. Day three, learn the meter.

Watch your context fill up and clear between tasks instead of compacting forever. That is the habit that keeps not just claw sharp but that allows you to understand what burns your context, what saves you money. Day four, pick your model and your effort on purpose instead of leaving it on its default setting. That will also help you understand what it costs so you can afford to use it more. Day five, install the security plugin and one skill.

Now your claude will be safer and easier and more capable to use. And neither of those took you any work. Day six, break something on purpose and get yourself out with slashre. This is the day you stop being scared of it. And day seven, hand it a real job, something you have been putting off to the side. Then turn on remote control and walk away and watch it from your phone. Do that for one week and it stops feeling like a fight and starts feeling like a superpower.

The hard part was never the tool. It was starting on the right step. That is how you learn 95% of claw code, not by memorizing commands, but by driving it a little every day and turning the parts that repeat into a claw.md file and a skill. And if you enjoyed this video, then leave a like. Or if this was useful, then subscribe because I have a ton more content like it coming your way. Oh, and would you look at that? The algorithm gods have decided you're going to enjoy this next video as well.

So maybe I'll see you there.