Claude Code Full Course 2026 | How Senior Engineers Actually Build with AI transcript

This is claude code refusing to read my environment file because I told it that it's never allowed to. This is it laying out its entire database plan and waiting for my approval before it writes a single line of code. And this is it splitting one big investigation across five parallel agents because I asked it to. If your entire cloud code experience so far is typing something like build this feature and then hitting enter, you're using maybe 10% of what this tool allows you to do.

So, let me ask you this. Do you really know when to use skills, sub agents, project rules, plan mode, permissions, and all the other parts of cloud code that decide how your agent actually works? Because if your answer to some of these is no, then yes, there is still quite a lot to learn. And companies are already paying engineers $200 to $300,000 a year to build AI agents, orchestration systems, and production workflows.

Not because these engineers can type build this feature into a prompt any better than you can. Because knowing how to work with an agent while building real software is a completely different skill from just getting one to generate code. And that's the skill this video is about. Hi there and welcome to this Claude code crash course where I'm going to spend the next few hours showing you random commands one after another and expecting you to remember all of them.

Oh, wait, wrong script. Instead, you're going to learn cloud code by actually using it on a real app. Throughout this course, we'll work on an e-commerce app inspired by a real luxury storefront. But here's the important part. Every feature we build exists for one reason. It's the moment a cloud code concept actually becomes useful. A design system when you learn how permissions work. A real Postgress database. When you learn why the plan mode exists.

Reusable workflows. When you notice the same process repeating. Separate agents. When the codebase gets big enough that one context can't carry everything. And if you've been on this channel a while, you know I love a long build. This isn't that. This video is optimized for one thing. that you walk away actually understanding how to work with an AI coding agent in a couple of hours and not a couple of weekends. So along the way, you'll learn how claude works inside your codebase, how to give it persistent project context with Claude and agents MD file, how permissions control what it can access, when plan mode is actually worth it, how skills turn processes you keep repeating into reusable workflows, and how sub agents let Claude hand over focused work to another agent without filling your main context with everything else it had to read along the way.

The goal isn't that you know 50 claw code commands by the end. The goal is that you understand how to work with a coding agent and know exactly when and why to reach for any of these because pretty soon simply saying I use AI to code isn't going to mean very much. Almost everyone will. What will matter is how well you work with it. And to make it even easier, you don't need to memorize anything in this video. I've created a completely free claude code cheat sheet with the commands you'll actually keep coming back to, such as sessions, context management, permissions, models, plan mode, skills, all of it is there.

So, you can just grab it from the link in the description and keep it open beside you instead of trying to remember everything. Oh, and one more thing before we start. Everything in this crash course scales up into a complete engineering workflow that I've built and open source for free. And there's a full agentic engineering course if you ever want to go deeper. We've been testing it with a closed group of engineers who went through the full course and loved it.

And as of today, it is officially public. I'll leave the link down in the description. And with it, you'll also get a discount on top of the current offer. preparing for that course for the past two years built the foundation that I'm going to use right now to teach you the claude code skills in this video. So for now we'll proceed with that. But if at any point in time you want to go deeper, you know where to find it.

But that's all I'll say about it for now. So let's get into cloud code. So what is claude code? You can already open claude, ask it coding questions, give it files, and build things with it. So you might be thinking, why do you need cloud code? Well, cloud code can work directly inside your development environment. You open your project, run cloud code, and it can read files, search through your codebase, edit code, run terminal commands, use git, run tests, and check whether its own changes actually worked.

Imagine you're building the e-commerce app in this course, and customers can add more units to their cart than you actually have in stock. Instead of finding the cart logic yourself, copying it into claude and explaining everything around it, you could simply say customers can add more units to their cart than what we have in stock, find out why, and fix it. Claude can then search for the cart logic, inspect both your product and inventory code, follow the flow, make the necessary change, and then run the tests.

That's what makes Claude code an agentic coding tool. The claude model is still doing the reasoning underneath, but Claude code gives that model the tools, project context, and environment it needs to actually work on your code. That's the important difference. So wait, does it mean that Claude can see my private code? Yes, Cloud Code can read files inside your project you've given it access to. It searches your project locally rather than first uploading and then indexing the entire repository somewhere else.

But when Claude needs the contents of a file to reason about your task, relevant information can still be sent to the Claude model. So Claude code runs locally does not mean that everything always stays on my machine. If you're working with private company code, understand the data policy of the account you're using and follow whatever rules your company has around AI tools. And then there's the obvious next question.

What about thev? Later on in this course, our e-commerce app will contain av files with things like a database URL, a better off secret, or even a stripe secret key. You shouldn't assume that Claude automatically knows those values are sensitive and should never touch them. Claude code has a permission system where you can explicitly control what it can read, edit or execute. You can block files such as thev orenv secrets or any kind of credentials and therefore control which tools claude is allowed to use.

I'll show you how you can set this up properly later in the course and we'll actually test it by blocking an environment file, asking claw to read it and checking whether that access is refused. For now, just remember that sensitive files should be explicitly protected. Okay, now let's talk about how claude code actually works. Now that Claude can work directly inside your project, how does it decide what to do? Most tasks follow a simple loop, gather context, take action, and then verify the result.

So imagine one of your inventory tests starts failing. You ask, find out why the inventory test is failing and fix it. Claude might first run the test, then read the error, then search for the inventory logic, then inspect the relevant files, then make a change, and then run the test again. And if it still fails, Claude gets new information from that result and continues. That's the basic example of an agentic loop. And while this is happening, you'll actually see the tools that Claude is using.

Read when it opens a file. Glob when it's looking for files matching a pattern. Grep when it's searching through the file contents. Edit when it's changing an existing file. Write when it's creating a file. And bash when it's running something in your terminal such as pmppm build test or git status. And if Claude needs information from outside your project, you may see web search and web fetch. Later, for example, Claude might use the web to check the current Drizzle documentation or research a design reference for the storefront.

So, don't only read Claude's final answer. Watch what it's doing. If you see it reading your product schema while debugging stock, you know what it's investigating. And if you see tests running through bash, you know it's verifying its work. And if you see web search, it looks like claw decided it needed information from outside the project. Maybe from Stack Overflow, who knows? And you can totally interrupt Claude while it's working.

If it makes a wrong assumption or starts heading somewhere else you don't want, correct it instead of waiting for the entire task to finish. You can do that by simply pressing the escape key. Now, what can claude code do by default? Before you add any skills, MCP servers, sub aents, or anything more advanced, cloud code can already do a lot. It can read, create and edit files, search through your codebase, run shell commands, start servers, run tests, work with Git, search the web, fetch documentation, and use the supported code intelligence such as errors, definitions, and references.

That's already enough to build a large part of the e-commerce app in this course and you'll learn each of these in more detail as they start helping you build faster. So let's install it. Cloud code is available in several places including the terminals, idees, desktop, and the web. For this course, I'll start mostly from the terminal because it makes it very easy to see what Claude is actually doing. So head over to cloud code website and follow the instructions for your operating system.

Once you install it, you can verify it by running claude- version. And if you'd rather work inside an editor, cloud code is also available through supported IDE integrations such as VS Code and you can use it through compatible editors like cursor as well. Once we check it out in the terminal, I would highly recommend that you also download Claude Code as a VS Code extension and then check it out there. It has a bit of a friendlier UI.

And as I said, there are also web, desktop, and even remote ways to use Cloud Code such as from your phone, but you don't need to learn every option right now. Either way, the core workflow is the same, and we'll use other surfaces later on when they actually become useful. Another important question is how do you access cloud code? Well, the exact plans and usage limits can change over time. So, understand what they offer and see what's enough for you.

You can use cloud code through supported cloud subscription plans. There's even team or organization plans or through API based billing through the cloud console. If you're learning and building normal projects, a subscription will give you predictable usage. So definitely start there. And if you're using cloud code heavily every day on bigger projects or longer sessions, you'll naturally need a higher tier. And API billing charges per token instead of a subscription allowance.

That's usually the right choice for automation and CI pipelines, not for following a course because heavy interactive sessions add up quickly when you're paying per token. And that's really all you need to know for this course. Check out Anthropic's current pricing page whenever you're choosing a plan because details can change. So now let's actually use cloud code. Create an empty folder on your desktop MKDIR and call it Aellier store.

We're going to build an e-commerce store for a luxury brand like Gucci for example. So create it and then cd over into it. Once you do, we can actually open that folder up within VS Code. And we're in. Then we can start Claude Code. I will open up my terminal and expand it. And then within it, simply run Claude. The first time you use it, you'll be asked to sign in. So sign in and then you'll be asked whether you trust this folder.

I'll say yes, we trust it. And then you're in. When you take a first look at it, it seems like there's a lot of stuff happening right here. If this looks daunting, I would highly recommend heading over to extensions and then search for claw code. I can even update it right here. It's a super popular Visual Studio Code extension that you can open up by simply pressing command shiftp and searching for cloud code. It'll open up that same session that we saw right here as part of our UI.

And as you can see, we need to be logged in. So, we can log in either through our subscription or through the Entropic console. In this case, most likely you have an active subscription. So, let's go with that. It'll open up a new browser window. So, simply continue with whichever provider you chose. And then you're in. As you can see here, you can see the model you're using. You can see the permissions and modes such as whether you're in auto, plan, edit automatically and so on.

And you can also upload some files or run some additional commands. Anything that you can do within the terminal, you can also do right here using the cloud code VS Code extension. So from this point onward, whether you're following along through terminal or through the extension, either way works. I might even switch between the two. Now, here it says not logged in, but we just logged in through our extension. So, if I just rerun Claude, it should be able to get access to our account.

And we're in. Here you can see which model we're using and which effort is currently selected. Here you can see some tips on how we can switch the model any time by running the model command and then switching between different models. At the bottom, you can also see which model you're using, how much of the context you have spent, and on which mode you're on. You can hold the shift tab to cycle between different modes.

But yeah, let's give Claude the first real task. Let's tell it to set up a new Nex.js ecommerce app in this folder using TypeScript, Tailwind, Better Off, Drizzle OM, and Postgress via Neon. I'll hold the shift key to be able to enter a couple of empty spaces and tell it to only create the initial project structure, dependencies, configuration, envample and minimal integrations. I'll tell it very clearly. Do not build e-commerce features, full O flows, schemas, UI, payments or deployment.

That's going to come in later. So yeah, this is going to be our first prompt. So just press enter and watch what Claude does. You'll probably see a lot of different commands like bash, write, read, and edit as it creates the project, installs packages, and checks its work. This is the agentic loop that you just learned about happening on the actual app you're going to be building throughout this course. If you want to, you can also expand specific pieces.

And you can see that here it used the bash command to run something. Then it's installing O and DB dependencies. So let's give it some time until it finishes running this command. And in less than 2 and 1/2 minutes, it is done. It scaffolded the project, verified it, and gave us info on the text stack it used as well as the files it created. So what you just saw right here was running Claude code interactively. You can stop the current session by pressing Ctrl C two times.

And if you run Claude like we just ran it right now, opens a new session that stays active. You give Claude a task, it works, you respond, and the conversation continues. But you can also start Claude with the first task already included. You can do something like this. Claude, explain how this project is structured. That'll start the session and then automatically prompt the agent to give you the answer. And there you go. the answer is in.

But in this way, the session will remain active. So you can continue speaking with the agent. But if you just want to ask it something and then call it a day, there's also a oneoff mode where Claude performs a task, prints the results, and then exits. You can use it that way by adding the P tag and then asking it a specific question. If you do that, Claude will perform the task, print out the result, and then exit. There you go.

Back in the terminal. But you can even pipe something into it like this. Tail N 200 app logs claude p find anything unusual in these logs. So if there were some logs, it will be able to go through it and share its output directly into the terminal. This becomes very useful later on for automation and CI. For now, just remember that claude keeps the session open and claude-p runs one task and then exits. Then the next major question is which model should you be using?

So if you're within the cloud window and you type forward/model, you can see which models are currently available. The exact model names will change over time, so don't memorize the list from this video. Instead, think about them in terms of the task. Use a faster general purpose model for normal development, small fixes, and everyday coding. Use a stronger reasoning model when you're dealing with things like architecture, difficult debugging, larger refactors, or several systems integrating at once.

For example, changing the layout of a product card probably doesn't need your strongest model. Figuring out how the inventory should behave across the database, storefront, and checkout. Well, that might need a stronger one. So, yeah, whenever you want to switch the model, you can simply use the forward/model command. But yeah, that's enough for now. You'll understand the model choices much better once you actually start working on the harder parts of our e-commerce app.

And other than that, you don't need to know 50 other commands. I will show you some of the more important ones, but don't try to remember all of them. That's exactly why I included that free cheat sheet in the description down below so you can open it up, have it side by side. Whenever you need something, you know where it is. And with time, you'll naturally remember it. So, you can start Claude like this. You can start Claude with a task.

As you know, you can run one task and then exit by using the -ashp command. You can also continue from your most recent session by running claude- c. You can also resume an older session by running claude r and then you can select which session you want to run. You can see which other commands are available by running claude and then within it you can run help. Here you can see all the information and one more which is super important is forward/clear.

But the question is when should you use clear to start a new session with an empty context? Well suppose that later on you spend half an hour debugging some authentication connection. Claude has read your O code, seen several errors and tried a few different approaches. Then you suddenly say redesign the product cards. Claude is still carrying all that authentication conversation in the current session. So that information probably isn't helping with the product card task.

That's when running clear is useful as it gives you a fresh conversation. You don't need to use it after every task. Use it when you're moving onto something genuinely unrelated. You learn more about context, compaction, and sub aents later on. Or if you want to dive deeper, you can check out the agentic engineering course. I believe that under the third module, I'm covering a lot of stuff regarding your agents like what the agent sees, how they read your codebase, context windows, context rod, topic switching, clearing versus compacting, and much more.

But yeah, now that the initial setup is finished, you can simply ask the agent to explain the codebase such as the architecture, technologies, the main folders, and important parts currently connect. Now, if you watch Claude again, you'll probably see it use bash, glop, or grap as it searches through the project and builds an understanding. The point isn't only to read the final explanation. Pay attention to how Claude finds the answer.

That's one of the most useful habits you can build while learning cla code. You should understand what cloud code is doing even when cla is doing most of the actual file and command work for you. But with this, another problem appears immediately as the app grows. You don't want to keep telling Claude some specific rules like use pmppm or we're using drizzle or this is how tests should run or to keep the design consistent.

Claude needs a way to know those project instructions every time you start a new session. And that's exactly where the claude.md or as of super recently agents MD which now claude code is reading as well comes in. So let's cover those in the next lesson. Now that you've got your store project running, what happens when you close cla code and then come back tomorrow? Claude won't automatically remember that you're using pmppm. how you're using Drizzle or RM to define your Postgress schemas or that same mistake that you already corrected twice.

You don't want to keep explaining the same project every time you start a new session. And that's exactly where the Claude MD or the agents MD file comes in. Claude MD is simply a markdown file where you give Claude instructions about your project. Claude loads it automatically when a session starts. So those instructions are already there before you even give it your first task. For example, use pmppm instead of mpm.

Use drizzle for database access or run pmppm type check before finishing larger changes. Instead of repeating those things again and again, you put them in a cloud MD. Then whenever Claude works on this project, it already knows them. And as of recently, it is official. Claude is finally adding support for agents MD to claude code. Starting today in the newest version, if there is no claude MD in a folder, Claude will check for and use the agents MD file.

So whenever I mention anything about the claude MD, the same rules go for the agents MD file. This agents MD file has been the standard for all other coding tools and it looks like claude code is catching up too. But there's one thing you need to understand. Claude MD gives Claude instructions. It doesn't technically block Claude from doing something. So if you write never modify migration files manually, Claude should follow that rule, but it still technically has access to those files.

If something absolutely shouldn't happen, that's where permissions, sandboxing, and hooks come in. and we'll get to those next. But before going further, you should understand the context window. This is basically the information Claude is working with during the current session. That includes your conversation, files that Claude has read, terminal output, tool results, claude MD file, and all the other memory Claude has loaded.

And that context has a limit. So if you keep loading unnecessary information into it, you're using space and attention that Claude could be using on the actual task. And that's also why Claude MD shouldn't become some massive document. As more information enters the context window, Claude has more things competing for its attention. You can think of it like an attention budget. every line inside the Claude or agents MD files is using some of that budget because Claude keeps loading that file while working on your project.

So don't put something there just because Claude might need to use it one day. Put things there because Claude should know them whenever it works on the project. And you'll often see the guidance around keeping Claude MD well under 200 lines. But don't treat 200 lines as a target. If everything useful fits into 30 or 40 lines, that's even better. And talking about the context budget, in one of the lessons in the course, I go over something that even I didn't know before I started working on it.

And that's context rot. I mean, I knew about the concept of context rot. You shouldn't fill up your context window because agents performance dropped significantly, but I didn't know it was this severe. Don't wait until the window is nearly full because a model advertising 200,000 token window can show real measurable degradation starting at 50,000 tokens which is only a quarter in. So the number on the box is the technical ceiling but it is not the point where the quality starts to slip.

So as a rule of thumb context rod isn't something that happens near the edge of a full window. It starts well before that continuously not as a cliff. So whenever you start working on something new, clear the context. Now let's talk about where does the claude MD or agents MD file lives because there isn't only one place you can have it. Claude supports different levels of instructions. You can have personal instructions under the cloud folder and then claude MD file which applies across all your projects.

So if there's something you personally want claw to follow everywhere, you can put it there. Then there are project instructions. Inside your project in the root of the application, you can just put the claude or agent file there. This is usually the one you'll use the most. For our luxury store application, this is where you can keep things like your stack commands, database rules, testing rules, and storefront design rules.

And you can also commit this file to git. So everyone working on the project gives claude the same project instructions. This is something you might not have known about, but there are also local project instructions. You can also have something like a.claude.local.md, which is a file that only applies to you on this specific project. Maybe you use a local test account. Maybe you have your own sandbox URL. things like that can live here and normally stay out of git and claude can then use instructions from all of these levels together.

And if you're working on a much larger codebase or a monor repo, this can go quite a bit further. You can have multiple nested cloudmd files across different parts of the project. So claude only pulls the instructions that are relevant to that area it's actually working on. I don't want to go too deep into that here because this is a crash course, but this is exactly the kind of concept that I cover inside of the agentic engineering course.

And because that course uses that completely free open-source agentic engineering workflow, you get a set of those reusable skills and commands that inspect your codebase and help you set up the right project context automatically. What does that mean? Well, if your project is small, it may create only one claim MD file. But if the codebase is much larger, it can create multiple nested clamd files. So each one is loaded only when Claude starts working on that specific part of the project.

The workflow of course goes beyond context files too, as it's built around helping to develop applications with stronger engineering and system design practices instead of just throwing prompts at an agent randomly. And yeah, you can use the workflow completely on your own since it's free and open- source. But if you want to learn how to use it properly alongside more advanced cloud concepts and the real agentic engineering course workflows, well then check out the agentic engineering course.

But for our Gucci store application, just having one project level cloudmd file is more than enough for now. And you might also think, but wait, doesn't clot already have memory? Well, it does. Cloud code also has automemory, but the difference is simple. Claude MD is what you intentionally tell Claude. Automemory is what Claude learns while working with you. For example, while working on our Gucci store, Claude discovers some weird issue with your local setup.

Or maybe you correct the same project specific behavior a couple of times. Claude can save useful things like that so they can be used again in future sessions. Each project gets its own memory folder with a memory.md as the main file. CLA can also create other memory files for more specific things. To see what is stored, you can just run forward/memory. And you can see that the automemory has been turned on with the project instructions checked in at the cloud MD file.

There are some additional instructions and user instructions. And you can also open up the automemory folder. And then to see what Claude has stored within your current session, you can just run context. This will show you how much of the context has currently been spent and show you the estimated usage by the category. So the main question is what should actually go into a claude or agent MD file? A simple rule is like this.

If removing this instruction would probably make Claude assume the wrong thing, then keep it. Otherwise ask whether claude really needs it in every session. For example, inside of our Gucci store, we can give it some commands to run like a package manager is pmppm with the start dev server command being pmppmdev. And we can also share the commands to run the tests or run the type check. Later on, once you add the database, we can also give it some information such as use drizzle for all database access.

We can specify where the database schema lives such as in source DB schema. And we can also tell it to never write raw SQL queries unless specifically requested. These are some important pieces of info. And once we set up the storefront design, we can also tell it to keep the customerf facing pages editorial and product focus to reuse the existing design system to avoid the dashboard style UI and to not include any of those purple gradients.

These are useful because they actually change how clot should work. Now compare that with something like write highquality code, follow best practices, make the UI beautiful, or keep everything clean. These sound nice, but they don't really tell Claude anything useful. It's the same with make the landing page premium, but what does that actually mean? Instead, you could say, "Use large product imagery, generous spacing, and restrain controls on storefront pages." That's something Claude can actually follow.

And don't dump your entire project structure or huge API documentation into Claude or agents MD file either. Keep the things Claude should know every time it works on this project. And the wording matters, too. Instead of saying format the code properly, say use two space indentation or instead test your work, say something like run pmpp test before finishing the task. Or instead of keep the API code organized, you can say something like API handlers live in source API handlers.

The more specific you are, the less Claude has to guess what you meant. And if the file starts becoming huge, don't just keep throwing everything at it. Cloud code also supports the claude rules where you can split instructions into separate files. For example, within the cloud folder, you can have the claude MD file and then you can have the additional rules folder within which you can have something like testing.md, database MD, storefront or security MD.

You can even make rules apply only to certain files by giving it a specific path and setting out the rules. Now, Claude only needs those rules when it's working in matching files. That helps you keep the rest of the context clear. And if something isn't really a rule, but rather a process that you keep doing again and again, that usually belongs in a skill. But we'll get to that later. For now, we can create our first Claude MD file by running init.

There's no need to do it from scratch. So, just have your Claude window open and type init. And as you can see, this will initialize a new Claude MD with the codebase documentation. It'll pick up things like the package manager, the framework, the build commands, tests, and other project conventions. And if you already have a cloud MD in it can suggest changes instead of simply replacing it. But don't just accept whatever cla creates read it.

Once it's done, you can either read it right here or you can head over into the cloud MD or the agentd file that it created. We can then preview it either in markdown or with a nice previewer like this which you can install as a VS code extension. Here you can see the commands, the architecture, the nextG 16 notes as well. It is all here. But if Claude added something it can easily figure out from package JSON, ask whether you really need it taking up the context every time.

And if something is wrong, fix it. And then add the things that Claude couldn't know just by reading the code. For example, Claude can see that we are using Tailwind, but it can't automatically know that we're building a Gucci store, which needs to feel editorial and product focus, or that you don't want a simple dashboard style UI. That's the kind of information that belongs here. And how do you know this file is actually getting loaded?

Well, open up claude and run context. If you do it and then check the memory files, you can see the memory right here. And you can run forward/context all to expand it. That way you can see exactly where your context is being spent. And on top of checking the context, you can also check the memory. And here you can see where it's extracting it from. Now another pro tip with the cloud MD file is to not just create it once and then forget about it.

Your project changes, commands change, and the architecture changes too. Maybe your database layer lives in one folder today and later you move it somewhere else. If Claude MD still tells Claude to use the old location, you're now giving it wrong information before it even starts the task. So keep the file updated, remove things that aren't true anymore, and don't keep adding new rules forever either. Sometimes the right change is just deleting an old one.

And in our agentic engineering workflow, we have a skill for that. It's called sync. What it does is it keeps all the context files up to date. It checks your latest git commits, figures out what changed, and updates the information automatically across your cloud MD and agents MD files automatically. So now that we have this cloud MD file, Claude knows how you want this project to work. But the next question is how much freedom should you give it?

When should clot stop and show you a plan first? Or which files should it be allowed to touch? Which commands should it be allowed to run? That's where the plan mode and the additional permissions come in. Thanks to our Claude MD, Claude now knows how we want this project to be structured. So, let's keep building this app while learning more of what Claude Code can do. But before we do that, there's one thing you should check.

Look at the current Claude Code mode you're in. Claude Code can work with different levels of freedom depending on the mode you're using. There's manual, where Claude asks before actions that need your approval. There's the edit automatically where normal file edits can happen without asking you every time. There's plan where Claude can inspect and think through the project without immediately editing your source files.

And there's auto where Claude can approve many actions itself after checking whether they match what you asked it to do. And there are a few other modes for more restricted or isolated workflows, but you don't need them right now. The important thing is to know which mode you're actually using. Because if your Claude code is currently in auto mode, you may see Claude editing files and running things without showing the same permission prompts I'm seeing.

That doesn't mean permissions aren't working. It just means you're giving Claude a different level of freedom. And you can cycle between modes right here if you're using the VS Code extension. Or if you're using it in console, you can just press shift tab to switch between the modes right here. I almost always have it on auto mode on. But for this first feature we'll implement, let's switch it over to manual mode so we can better understand how it's working.

And let's start with our first real feature. Building the UI of our storefront. Instead of randomly designing pages, let's give Claude an actual reference. We'll use Gucci's current website as inspiration, but we're not copying their branding, assets, or content. So, let's tell it something like study the current Gucci website as a visual reference for this ecommerce application. And of course, that website might be completely different depending on when you're watching this video, but that's totally okay.

You might just have a newer design than what I have. And when I'm developing apps myself, I don't typically type. That sounds a bit weird knowing that we all code a lot, but lately I've been more narrating the prompts and the commands for my agent. I used a tool called the whisper flow which you can see here at the bottom. But there's many of these different tools that you can use to speak to your agent. Let me show you how that works.

I'll press the command key on my keyboard and continue telling it the prompt. Analyze its typography, spacing, layout, navigation, product presentation, imagery, buttons, borders, colors, and responsive behavior without copying its text, assets, or branding. Something like this. Feel free to take your time to copy this and then I'll say then implement those principles in our project by setting up the global design system including typography, color tokens, spacing, containers, buttons, links, borders, and reusable responsive primitives in the appropriate Tailwind and CSS files.

And then finally, briefly explain the rules you implemented and the files you changed. Now press enter and watch what happens next. Claude may use web search or web fetch to research that reference and only then it'll start working within your project. Yep, there we go. Fetch. And it's even using a front-end design skill that I have loaded. And because you're in manual mode, you'll start seeing permission prompts whenever Claude wants to make changes or run commands that need your approval.

You might need to approve an edit, then approve another, then Claude might want to do something else, and you need to approve that, too. So, let's give it some time. There we go. Do you want to allow Claude to fetch this content? Yep, we do. Then, again, do you want to proceed with this? Yep. We want to proceed with a web search. And throughout the rest of this task, it might ask us to do this a couple of times. Yep.

Yep. We want to allow claw to fetch more websites to figure out exactly what we want. And after some time, you'll start thinking, do I really have to approve everything every single time? And that's where the permissions become useful because permissions let you decide what Claude can do automatically, what it should ask you about, and what it shouldn't be allowed to do at all. And there are three basic rule types: allow, ask, and deny.

Allow means that Claude can perform that matching action without asking you. Ask means that Claude has to stop and get your approval. And deny means that claude code blocks it. And if several rules match, cloth checks them in order of deny, ask, and allow. So deny wins first. You can inspect the permissions that you have with your current project after it finishes doing its thing and then running permissions. Permissions will show you which permissions you currently have such as which allow, which ask, deny, or whether it is set to the auto mode with soft allow, soft deny, and so on.

So you can check all of those permissions right here. You might have also noticed that when Claude asked us for permissions, it asked whether we want to allow it once or whether we want to allow it from here onward so that we don't have to approve that same or similar action again. That's useful because you probably don't need to approve the pmpm build command for the 15th time. But you also shouldn't click don't ask again on everything without thinking about what you're allowing.

So it looks like our design system is in and we should be able to see it right here within our source app and then globals.css. All of the colors, type fonts and texts and headings and buttons, all of it is right here. We'll take a look at that soon. But now let's set up permissions for our store. What would make sense for this project? Well, Claude will probably run commands like pmppmdev, build, test, or type check every now and then.

These are normal development checks, and you may want claw to run them without stopping you each time. But get push is different. Maybe you always want to see before it happens. And later on, your project will contain things like the database URL or some other environment variables. Claude shouldn't be able to read those. So, you can keep project permission rules inside of thecloud folder. If it doesn't exist already, you can create one by creating a new.claude.

And then within it, you can create a new file called settings.json. For example, inside of there, you can do something like this. Inside of a new JSON object, you can add the permissions and then split them by allow, ask, and deny just as we talked about. Now, under allow, I gave it permission to run PMP build, test, rungit status, and so on. But I wanted to ask before it pushes anything, and I want to explicitly deny that it reads our ENV files.

With that, you've created a much more useful baseline. Claude can run the normal checks you'd expect. It will ask before pushing and your environment files are blocked from its normal access. So this is where the difference from the previous lesson becomes clear. Inside of the claude code file, you could write never read.v and claude should follow that instruction, but it's still guidance you're giving to the model. A permission rule set is different.

When something matches a deny rule, cloud code itself will block that action. So use claude MD for things like, hey, use the existing design system when building the storefront pages. But use permissions for things like Claude, you shouldn't read this file. So, Claude MD simply tells Claude how you want it to work, but permissions decide what Claude code is actually allowed to do. And just like with the code, don't set up permissions and assume everything works.

You may not have a realenv yet. So, create a temporary example file or test that rule later when the database is added. For now, we have this enenv.ample, example, but I'll go ahead and copy it and create a new env. And let's assume that this includes the actual password. Now, we can open up claude and tell it to read the env. Claude code should block the access. First, it'll ask us to run the bash command because we're still in manual or autoaccept edits mode.

But once it reaches that file, it'll say I can't. Reading that file is blocked by this session's permission settings. File is in a directory that is denied by your permission settings. I didn't try to route around it with a cat since the deny rule is clearly aimed at content specifically. And you can always run the permissions command to check which rules are under allow, ask, or deny. Now, let's see what the experience feels like with those permissions set.

Since we already have a full design system put in place right here within the app globals.css, we can ask Claude to build the first homepage. For example, we can tell it to build the first complete homepage for the e-commerce storefront using the design system or the setup in the project. We can then continue telling it to take inspiration from the way premium fashion websites like Gucci use large editorial imagery, featured collections, and product focus sections.

And finally, we can tell it to use simple sample product and collection data where needed with images from Unsplash or other sources. We want to make it responsive and verify the result when it's done and run it. Now, if you watch Claude again, it can make the changes it needs. And when it wants to run one of the commands you've already allowed, it doesn't need to interrupt you every time. But for some things like running bash commands, it might still ask you for permission.

The goal is that you're not trying to remove every permission prompt, but rather you're trying to remove the boring ones that you already understand while keeping control around the things that matter. But to be honest, the auto mode has gotten so advanced that I typically leave it on. And I'm totally happy with the amount of permissions that Claude code has by default. So that's what I'll shift it to by using shift tab.

And let's let it finish running this task. And after some time, it is done. Here it gave us the final explanation of what happened, the files that changed, and so much more. So, what do you say that we run the application for the first time and check it out? I'll open up a secondary terminal and run pmpm dev as that's what we're using to run the application. And then I'll open it up on localhost 3000. You can either open it up within your browser or nowadays even VS Code has its built-in browser.

Since this is a large scale pretty well-designed application, I definitely want to open it up within the browser. So, check it out. Complimentary delivery and returns Attelier. And here we have the long coat as well as some of the additional collections of the printed silk outwear and leather goods. This is looking like a real store. So, just from a single prompt, we were able to get a pretty good output. Of course, the other pages are not going to work right now, like the products page, but that's going to be the next step.

For now, we only have the homepage, and sure, we can play with the hero section to present it a bit better. But now, I want to be able to open up one of these product detail pages. That's going to be under products and then the product name. So, back within the application, open up the terminal, head over to Claude, and let's tell it something along the lines of build the product detail page with large imagery, product information, price, category, and stock state.

Keep it consistent with the homepage, and product listing and run it. I'm running it on auto mode, so now we shouldn't be getting as many permission questions. And a couple of minutes in, the product detail page is built and verified. The build passes and all 13 product pages pre-render as static HTML with lint being clean. You can see all the files that have been changed right here. Information about how the page is structured.

And that is it. And all of this only took 21% of the context window. So, let's quickly check it out by rerunning our application, opening it up on localhost 3000, and then opening a specific product details page, such as this Jouro soft backpack. A nice product page opens. We can see a static product information on the right while the images on the left scroll and then we can see the recommended product section at the bottom.

And all of this really feels like a polished editorial Gucci inspired style website. But with all of this, we're still not setting up the real database. Right now, we're working on the customer experience and making sure that the design components and the page structure feels right. And these are exactly the kind of things where letting Claude edit normally make sense. If the product grid is wrong, you can easily change it. or if you don't like a specific section like this one, you can redesign it.

And if the spacing is off, Claude can fix it on its own. These changes are easy to review and therefore easy to undo as well. And that's how you should approach building with AI in general. Instead of asking it to build the entire store in one prompt and then wondering what it did, you break the work into small features. Let Claude build one, review it, accept it or undo it, and then move on to the next one. That is what agentic engineering is all about.

So, at this point, our atelier is starting to look like an actual e-commerce application. You've got the main project set up, the claude MD file right here up and running, giving Claude instructions, a design system within the globals.css based on a real reference. You also have storefront homepage right here in the page. There's also the product listing pages as well as project permissions that remove unnecessary approvals while protecting more important sections.

And notice how you learned about those permissions. You didn't memorize a settings file and moved on. You saw the problem first. Claude kept asking before it could work. Then you decided which actions were safe enough to allow and which ones should still stay under your control. And that's how most of the rest of this course will work too. So far the features you build are relatively easy to change. If you don't like the homepage, redesign it.

Or if a product card is wrong, just change it. But the next step is different. You need to add the real database layer. That means Postgress, Drizzle, products, categories, inventory, and database migrations. And those decisions are harder to undo casually. And for something like that, you may not want Claude to immediately start writing code the moment you describe the feature. You may want it to inspect the project first and show you exactly what it plans to do.

And that's exactly where the plan mode comes into play. So let's talk about that next. Now let's use the plan mode on the first part of our e-commerce application where the approach actually matters which is the real database. You can either approach it through the VS code extension by selecting the plan mode right here and then tell it what to do or you can do it through the terminal if you start a new session. This would be a great place to clear the context and then you can simply run forward slash plan to enable the plan mode or view the current session plan or you can shift to it naturally by holding the shift key and then tabbing onto plan mode.

Here we can ask it to inspect the current e-commerce project and plan how to replace the current product data with a real Postgress database using Drizzle ORM. We can also continue to say that for now we only need products, categories, and stock. We can then ask it to study how the existing storefront currently uses product data before deciding the schema. And since we're just starting off, we want to keep this first version simple.

Don't add carts, orders, payments, reviews, wish lists, or product variants yet. And most importantly, we want to ask it to show us the database structure, relationships, files that need to change, migration approach, and how the existing storefront will start using the database. Press enter and watch Claude work. In plan mode, Claude can now inspect, search, and research, but normal source edits stay blocked until you approve the plan.

You can see that it started a new agent right here on main as well as it started a sub agent on the explore part where it's exploring how the storefront uses the product data right now. And if you want to see what that sub agent is doing, you can just head over to it, press enter, and then you can see what that agent is doing right here. Or you can go back to the main session. Looks like it already has a clear picture of the current data layer.

So it's going to confirm a few schema decisions. And now Claude got back to us with a couple of questions. How should the stock be represented in the database? Well, it can be quantity plus derived state. Yep, that looks good to me. How should the multiple product images be stored? Well, we can use separate product images table. The homepage collection strip, printed, silk, outwear, leather goods, overlaps with the product categories.

Well, those can just be categories. Uh, the homepage has two hard-coded list. Well, we just want to order it by created ad. I basically accepted all the recommended options because in this case they fit what I was after. So we can submit the answers and let the agent continue planning without these questions. If you just accepted what Claude gave you and you immediately press approve without actually reading the plan, you've gained almost nothing.

The whole point is to catch bad decisions before they become code. For this database, we want to check things like what tables Claude wants to create, how products and categories connect, where the stock is stored and how, how prices are represented, where the drizzle schema will live, which files need to change, and how Claude plans to verify the result. A weak plan might sound something like add database, add products, update storefront, but that doesn't tell you much.

A useful plan should show that Claude understood the current application and can name the actual parts of the codebase that will change. While it's doing its thing, I want to give you an example. So, I'll head over into our readme and I'll just paste something at the top. You can also open it in preview. Just imagine that Claude says something like this. Create separate products, product variants, inventory locations, and more.

You could stop right there and say that's too much for where the application is right now. Keep stock directly on the product and only create what we currently need. That only takes a few seconds. But if you catch the same mistake after Claude has already created the schema, generated migrations, and changed the storefront. Well, then there's much more to undo. And that's one of the biggest reasons to use the plan mode.

The cheapest place to fix a wrong decision is in the plan, not after the code is written. So back in the terminal, it looks like Claude presented us with a plan. The goal is to move the catalog into Postgress. It gave us context on all of that, the database plumbing and even which files to change. You should analyze all of this in detail. It's specifying which column is it going to add, how a database is going to be structured, and more.

And you could even ask it to turn this into a markdown file so you can review it more nicely. If you want to edit the plan directly, you can just press CtrlG to open it up. And once you do that, it'll be opened up in a new markdown window. Here you can even preview it for a bit of a nicer view. And spend some time, maybe even 5 to 10 minutes, going over the plan and noting down or directly changing right here all the things that you think should change.

And only when you're happy with the approach, you can approve it. One important thing to know is that approving the plan exits the plan mode. Claude doesn't stay in the same readonly state afterward. So you can choose how you want to continue and then claude moves into the implementation. In this case, we can say yes, proceed, execute the plan, and use auto mode. And that's exactly what it'll proceed to do. And the one important thing to know is that approving the plan exits the plan mode.

As you can see on my end right here, it finished and we're back in the auto mode. Now, in this plan or the execution of the plan, we set some very important foundations for the rest of the application. And that's something that's not only useful for this one task, but something that Claude should probably remember every time it works on this database. So we can tell Claude to update the claude MD with only the database conventions from this decision that Claude should remember in future sessions.

It'll take a look at what it did and it'll read and then update the claud. We want to keep it short and don't add things that Claude can easily discover from the codebase. It might end up with just as you can see right here an additional seed command as well as some database specific configurations such as where the schemas are stored the catalog and so much more. And that's it. This is exactly how Claude MD should grow.

Not because you want a bigger file, but because the project has now made a real decision that Claude should remember. And if Claude keeps making the same wrong assumption every time you plan something, that's usually a sign that your project instructions are either missing or are wrong. Okay, so as we approve the plan, Claude went into building. We can zoom out a bit because there's a lot of stuff that happened right here and we can read its update.

Claude first configured Drizzle. Then it created three additional tables and schemas for them. It set up a database connection, generated migrations, created seed data so we can seed our database. It updated the product queries and connected the storefront to Postgress. The important part is that Claude isn't inventing the direction anymore. It's implementing the approach that we reviewed. But at some point, you'll need a real Postgress connection string.

So let's create the database using any kind of a provider. In this case, I'll use Neon as it's free and easiest to set up. So, simply create your account. You can use any provider. Then create a new project. Let's call it Attilier Store. You can choose the region that is closest to you and just click create project. The project was created. So, you can head over into it, then click connect. And here you'll be able to connect to your database.

Simply copy this connection string. Head back into the application under the env.local because that is the env that we're going to use locally on this device. And then here we can update the database URL with the one we just copied. You don't want to paste the secret into claude. Instead, you want to add it here. And we'll use that to run the application, but we'll never tell it to claude. And now we want to test the whole database end to end such as running migrations right here that were generated and inspected for us.

Claude should have created a command for us in order to be able to do that. I believe the command in question is the one that it added to Claude. So we can even tell it to run the migration and seed now that the database URL is set. And I love how it autorecommended that line for us. It's going to check what's in the database. It'll create a script and very soon it'll run that script. But in the meantime, it says that it can't run it because database URL isn't reaching my shell.

Maybe it is specifically looking forv and notenv.local. So I'll remove that env part and tell it to try again. There we go. It got connected and the database is empty with no o tables. So our first migration applies cleanly. Great. Now it'll verify whether the data landed correctly. But we can also verify on our end by heading over into neon tables. And you can see the account, categories, products, all of the data is actually right here.

We can even verify an image. I believe if we find where the images are stored. There we go. Product images. And here we can see the URLs from Unsplash. So if you were to copy this entire URL, you would be able to see the image, but we'll see it in our application soon. So with that in mind, we can now actually run our application by opening up the terminal and running pmppdev to spin it up on localhost 3000. So back in the browser, heading over to localhost 3000.

If you reload, you should be able to see the application and it looks very similar as it did before, but now it's actually pulling the real data from the database. And that's the beauty of it. So before we proceed, we can now open up Claude and tell it to show me the important changes you made and explain anything that I should review. Or you can run git diff in your terminal. Maybe I can open up another one and this will tell us all the file changes that happened recently.

You can also explore them right here. But yeah, let's see what clot itself thinks that we should review. And there we go. Here's the walk through the important changes. Stock became a number and the states became derived. So here we can see how we are handling the state behavior of how many items do we have in stock available to order. Before sold out was typed by hand per product. Now nothing stores a state two columns do and every badge tone and disabled button follows them.

Two one mapper is the scene between the database and the UI. So in this case we have the price the compare at price the images the badge and the stock and every query returns the product data never a row. And that's why a product card and a detailed page asx are left untouched since nulls and foreign keys stop here. And there's a couple more things that we should review carefully. In this case, plan mode helped us catch the wrong direction early, but it still doesn't replace reviewing what was actually built.

If Claude starts drifting, replan by going back into the plan mode and then update the approach based on the new information. That's better than letting a wrong direction spread across the project and trying to clean it up afterward. But before we keep building, there's one thing I want to talk about. It's security. And this has become a genuinely wild topic recently. In July 2026, OpenAI disclosed that two of its models during an internal cyber security evaluation escaped their sandbox testing environment by exploiting a zeroday vulnerability, reach the internet, and compromised parts of the hugging faces production infrastructure.

And the reason for that, they were trying to find answers so they could cheat on the benchmark they were being evaluated on. Yep, I'm not joking. A week later, Anthropic reviewed its own cyber security evaluations and found incidents where cloud models had gained unauthorized access to the real systems of other organizations. By September, that count was up to four incidents found across a review of roughly 480 million transcripts.

So apparently the AI is not only writing your back end anymore. Sometimes it's also trying to find its way out of the building. Obviously these were very unusual evaluation environments with safety measures reduced for testing, not cloud code randomly attacking websites from someone's laptop. But it does make one thing very clear. As AI starts writing more of your application, security matters even more. And there's another problem.

Claude just helped us plan this database implementation. Claude wrote most of the code. Now technically I could ask Claude to check whether the code that it just wrote is secure and it absolutely can find useful issues. But for important security checks, I don't love the idea of having the same model that made the implementation decisions be the only model judging those same decisions afterward. I want another pair of eyes and that's where I use Code Rabbit.

They've sponsored this segment of the video to show you a feature that's especially useful at this stage and it's called AI Deep Scan. Instead of only reviewing a single change, Deepcan can inspect committed code across the repository and look for security risks across the application. And this is a good time to run it because we've just introduced our first real backend and data layer. To be able to test it, we have to commit our work and push it over to GitHub.

So, head over to github.com/new and create a new repository. I'll call an atelier store and I'll create it under my own profile. Once it is done, we can copy the URL and we can tell Claude to commit and push all the existing code to this GitHub repo. And it should be able to do that nicely for us. But we want to turn on the plan mode when we run that and just switch over to auto mode. And I like how it's going to check whether the env is not included as part of the push.

While that is happening, you can head over to Code Rabbit by clicking the link in the description. You can start using it completely for free, but I've also got a special discount code for you. You can use JSMCR as the discount code and the first 50 new users will get Code Rabbit Pro Plus completely for free which also gives you more Deepcan runs for bigger, more ambitious projects. So grab it while those pots are available.

But for now, let's go ahead and sign in using GitHub. Once you're there, you can connect a repository by adding it right here. In this case, I'm going to give it access to the specific repository, the Atalier store, and I'll click install and authorize. Once it's there, you should be able to see it right here. Now, back on the VS Code side, as you can see, as per our rule, it's asking us whether we want to allow it to push over to GitHub, which I'll say yes.

It pushed over to main. So, if you head over here, you should be able to see all your code right here. You can clean it up a bit by hiding the releases, deployments, and packages, giving it a short description such as a luxury brand store front. We can enter the website. As soon as we deployed, we'll be able to enter the real deployed URL. For now, I'll put the link to jsmastery.com. And here you can put something like Nex.js, claude, or whatever else you want to add.

Then head over to code rabbit. And under security, you can head over to AI deepcan. Currently, we have three deep scans. So, let's scan a repository. In this case, we're going to pick the one that I chose. Some estimated credits are going to be right here. And then we can scan it. The scan has started. And we can see that right here. Now, there's one thing that I want to point out right here. And that is that I'm not going to intentionally introduce a vulnerability just so something dramatic appears on screen.

I want to see what it finds in the application that we've genuinely built using claude. Deepcan will look across the repository rather than only examining one isolated file or diff. So it can reason about how different parts of the application connect and surface security problems that may span several files. Now let's give it some time until it finishes. Now about 10 minutes in, the deep search is now complete. So, let's open it up and take a look at what it found.

If we expand the scan details, we can see three findings. One medium, two low. No secrets were leaked, but under vulnerabilities, we can see three. And what's funny is that earlier I said that I wasn't going to plant a vulnerability just to have something dramatic on the screen, but it turns out I didn't need to. These are real findings in code that we genuinely built in this video. Don't just look at the count and panic and don't automatically tell claw to fix everything.

We want to try first. Let's start with the highest severity. And for each finding, decide, is this real? Is it relevant? And does it need fixing? Now, the first finding is the weak secret. This medium finding right here says that the application accepts any better o secret without checking whether it's actually a strong secret. Now why does that matter? Well, that secret signs authentication tokens. If a deployment ever uses something guessable there, an attacker can forge those tokens and code rabbit even trace the specific path. a forged change email verification token that ends with the attacker owning the victim's account.

Notice what kind of finding this is. There is no bug in our code today. It's a missing guardrail and it becomes a real vulnerability the day someone deploys this with a lazy secret. Exploitability right here is marked difficult, but the impact is account takeover, which is why it's the only medium in this list. And there's a bit of irony right here because our permission rules stopped Claude from ever reading the secret, but nothing in the application ever checked whether the secret is any good.

So let's bring this into claude code. What you can do is just say fix right here. And if you have fixed enabled for this organization, claude code will be able to automatically apply it. Else you can just share this for agents. Head over into clot code by opening the terminal and then pasting it in. It explains what the issue is and specifies how to fix it. You can either pass it in like that or just tell it something like this.

The application accepts any explicitly configured better o secret while the authentication dependency only warns about short or low entropy values. A guessable shared secret allows attackers to forge authentication related tokens. And then we can ask it to investigate whether this is accurate for our own current better o setup and explain the risk in the context of this application first without modifying anything yet.

In your case, it's going to be enough if you just copy this and paste it in. But I want to investigate this first and then get back to you with more information on whether this really is that critical and then if cla confirms it, we can easily fix it. Very quickly, the answer is in. It told me that it traced this through the installed better o source. The report is partly accurate. The mechanism is real, but its premise doesn't match this deployment and it understates one thing while oversaturating another.

The mechanism is real. It found it. It mints a session for the victim and rewrites their email. So, anyone who knows a secret forges that token and takes that account over. One thing that the report gets more right than I'd guessed is that this branch never checks the option user change email enabled as that gate only exists on post change email. But that premise is wrong for us and the reality is worse. The report describes any explicitly configurable guessable secret and we don't have one.

Better odd secret is present but empty. So create context falls through. That's a default secret, an exported constant in the in the published mpm package. It's publicly known. So, this definitely is something to fix. We currently don't have any users, but as soon as we make this application live, this is a real risk. So, let's simply tell it to fix it. And there we go. The vulnerability is now fixed. Now, if the secret is unset, we'll get this result.

If it's the default, we'll say that this is not good. If it's under 32 characters, we'll say must be at least 32. And if it's a repeated filler, well, we can also disqualify it. So, it'll only work if it's an OpenSSL randomized B 64 32 character string. Perfect. So, let's generate one by heading over into a new terminal and run open SSL rand 64. This will give you a string which we can now put into our env secret and it'll work.

So we can consider this one fixed. Now the next finding is low severity and honestly I really like it. The homepage has a newsletter signup form. So when Claude built that page back in the permission lesson, it scaffolded the form with the action hash. Something that looks like this. and it has no method. It's just placeholder code, but HTML has a default. A form without a method submits a get request, which means that every email address typed into that form gets appended to the URL into the address bar, the browser history, and our server logs.

So, think about what just happened. AI generated placeholder code sitting on the homepage quietly leaking subscriber emails. I mean, nothing crashed, per se, but this is exactly the kind of thing that an independent scan catches. And with a click, and if I took a quick glance, I would have missed it. So, I'm going to share this for agent. And then back into the cloud code terminal, we can just paste it. And we'll tell it to fix it.

Fix this. But before I run it, I also want to take a look at the next one. That's going to be the last one right here about information disclosure. And right now, what's happening is that signing up with an email that already has an account returns a specific error while a new email succeeds. So, anyone can probe our signup endpoint and figure out which email addresses have accounts on this store. Is that a real issue?

Yep. Is it critical for us today? Well, that is where you have to think instead of just autofix it. complete fix is requiring email verification so that every signup attempt looks identical from the outside but that needs an email sender which we deliberately kept out of this build for now. If you just add an email service onto this project right now mid lesson just to close a low severity finding well that would be exactly the kind of scope creep that we've been avoiding all this course.

So an honest engineering answer is that not every finding gets fixed the moment it appears. Some get fixed now like the one that I sent over claw to fix the first medium one and the second low severity one. But some will get a note that I will keep either in my mind or on a postit next to me and then later on we can fix it. But what you never want to do is just silently ignore it. Okay. So let's summarize what just happened here.

Code Rabbit found three issues and explained exactly why each one matters. Claude then investigated each one inside the codebase, confirmed them and implemented the fixes and you made the decision in between whether to fix now or document it for later. That's two independent systems and you are in the middle. It's a much healthier setup than just letting one model write the entire application and then asking it is everything good.

So after it implements it, let's just go ahead and tell it to commit and push the changes. This will now be chained. So as soon as it is done, we'll be able to take a look at the code changes on GitHub. And alongside this, Code Rabbit also reviews pull request as code comes in for bigger teams. There's also triage, which surfaces the changes that need attention first. So go ahead and check out all that it does. I personally use Code Rabbit on jsmastery.com.

That's our official platform repo. So, I highly recommend it. The link is going to be in the description. But now, as we're pushing the final changes, I want to quickly continue where we left off. And if I remember correctly, that was the talk about context window and context rot. In this case, we've been speaking with this particular agent for a long time. And sure, we still haven't filled out more than 20% of its context window, but I think it's about time that we reduce the clutter because we are done with fixing these security issues.

So there are two options. You can either use compact which frees up the context by summarizing the conversation so far or you can also run clear which we have seen before. This cloud session did a lot. So let's go ahead and compact it. This will keep the useful parts of the current work while reducing the amount of conversation that Claude is carrying. It'll take some time and then you'll still be able to continue on the same conversation but with less clutter.

To be honest, I don't use compact as often. You only want to use this when you're working on the same work, but you need smaller context. But in most cases, when you fill up the context, you'll already be done with the feature you're implementing. So you can just run clear and start from a new session. And in this lesson, the thing that filled up the context was us using the plan mode to plan our entire database. But while we're compacting the conversation right here, I want to tell you to not use the plan mode for everything.

If the task is something like change the heading or add more spacing here, just do it. Plan mode is useful when the approach itself needs to review. things like the database changes, authentication, migrations, large refactors, or changes across several parts of the system. But if the change is obvious, don't add another step just because the plan mode exists. And for more complex things, there's something on top of plan mode.

Uh, let me explain this in a read me right here. Plan mode works well when you already know what you want and Claude needs to figure out how to implement it. Something like add products, categories, and stock using Postgress and Drizzle. That's clear enough, but something like build proper inventory management is much more vague. Does that mean multiple warehouses, reservations, low stock alerts, inventory history, or more?

Well, that's where I separate the problem further inside of Agentic Engineering Skills. As I told you already, it's an open- source repo. And specifically, the skill in question right here would be the scope skill. So, head over here into scope just to show you. And what the scope skill does is to turn a product idea into a living core scope in the doc scope and keep it current. You can use it for planning a new product or a new slice, which would be a feature.

You can use it to plan one feature specifically or run it with no arguments to reconcile after shipping and cue what is next. So basically it's a seed for what to build. Then there's also the architect skill which works with you through the important technical decisions and then the develop skill that builds. So basically we use the scope skill to challenge the idea before writing any code. Then we use the architect skill, this one right here, to ask what important technical decisions need to be made.

And finally, we can use the plan mode to check how should this specific change be implemented into the current codebase. You don't need all of these at every step for every feature, but once you're working on larger applications, that separation becomes really useful. The workflow itself is completely free and open source. But if you want to learn how to use it with claude code, then you can check out the agentic engineering course.

At this point, all the pieces you've learned are starting to work together. Claude ND keeps the important project rules. Permissions right here control what Claude can or must not do. Plan mode lets you review important changes before implementation. Compact helps when a long task starts filling the context. You can run context to see what is filling the context. And finally, the clear command gives you a fresh start when the new task is unrelated.

That's the pattern you want to build, knowing when each one is useful while you're actually building. At this point, you've already built several parts of our luxury storefront. And you're [clears throat] probably starting to notice something. The features change, but a lot of the process doesn't. When Claude builds another page, you still wanted to inspect what already exists, reuse the design system, search for existing components, keep the page responsive, avoid unrelated changes, and verify what it built.

You could keep writing all of that inside every prompt or you can teach Claude that process once and reuse it. And that's what skills are for. A skill is a reusable procedure or piece of knowledge that Claude can load when it becomes relevant. At its simplest, a skill is a folder containing a skill.md file. Inside of that file, you describe what the skill does and how Claude should handle that kind of work. You can call a skill yourself with a forward slash like build UI or Claude can use it automatically when your request matches what the skill is meant for.

This is different from Claude MD because your Claude or agents MD loads into every conversation for this project. But a skill loads its full instructions only when it's actually needed. So a detailed UI workflow doesn't take up context while you're debugging a database migration. So when should you write something into the cloud MD or when should you invoke a skill? The answer is simple. Just ask yourself is this a project or is it a repeatable process?

Use pmppm, use drizzle, reuse the existing design system. Those are facts and they belong in CloudMD. But inspect the implementation, find reusable components, build the UI, check responsive behavior, run the app, verify, type check, summarize is a process. Claude only needs it when doing that kind of work. That's a skill. So project fact goes into claude MD. Repeatable process is a skill and a one-time task. Well, just ask claude.

Anthropic specifically recommends skills when you keep repeating the same instructions or when something inside Claude MD starts becoming a procedure rather than project context. And this is something that we go into a lot of detail about within the skills module of the course, such as how to understand the skills, read them, build your own, and when you should use MCPs instead of skills as well. But let me tell you a bit about them here as well.

Project skills live inside of thecloud folder and then within the skills folder. So, let me show you how to create a skill. Head over intoclaude. create a new folder called skills and then within skills create another folder called build- ui and then within it you can also create a new file called skill.md just like this the directory name becomes the command build ui because this skill is specific to our store keeping it inside of the project means you can commit it with the code and everyone gets the same workflow A skill for all your projects would live not under this cloud folder but under the cloud folder of your computer.

Now a skill has a YAML formatter and markdown instructions and that looks something like this. You start with three dashes. Then you give it a name such as build UI as well as a description. And here we can say something like build or update customerf facing e-commerce UI using the existing design system components product patterns and responsive conventions. And here you also have to tell it when should it invoke it.

So we can tell it to use it when creating or significantly changing pages, sections or customerf facing components. Then you close this header with three more dashes and you're ready to write the body of a skill. In this case, we can say build or update the following UI. And skills can also accept arguments. You use the dollar sign and then say arguments. So we're asking it to build a UI of whatever we pass into it. So we're telling it to build the UI of whatever they pass here.

Arguments is going to be filled in with whatever you type after the command. So the skill carries over the process and you only describe the feature. And then we can give it some steps such as inspect the current implementation and related components, search for reusable components before creating new ones, reuse the existing design system, and so on. Notice how we're not turning this skillmd into a huge manual. Rather, it is focused.

If it eventually needs large references, materials, or scripts, those can be moved into separate files within the build UI folder. And the part that matters much more than it looks like is the description. The description isn't just documentation for you. It's how Claude decides whether this skill is relevant. Claude reads the names and descriptions of available skills and matches them against your request. If you give it a description of useful UI workflow, well, that basically tells it nothing.

But if you specify it like this, that tells Claude what the skill does and when to use it. So a weak description is going to be the main reason that a skill doesn't trigger when you expect it to. So now instead of that same long checklist, we can just open up claude and tell it forward slashbuild UI which is going to build or update customerf facing e-commerce UI using the existing design system components and so on.

And then we can tell it build a new arrivals page using the latest products from the database. Keep it consistent with the homepage, product listing, and product detail pages already in the application. Perfect. Now that we have the skill, it's much easier as we don't have to have such detailed and accurate prompts. So, let's see how it approaches it. And I'm running it with auto mode on. And there we go. In a couple of minutes, the new arrivals is now live and reachable from Chrome.

It added a new page, server components, breadcrumbs, hairline rule, empty states with no new colors, classes, or components. So, we can explore it on localhost 3000. Back within the browser, we can browse our existing collections or product pages, or you can head over into this new in at the top left and see what seems to be a category page. sorted by the newest pieces right here. It did it incredibly well. And of course, even from here, you can visit a specific product page.

And if you take a closer look at how it did it, Claude simply loaded the skill and inspected the existing implementation. You can see that right here. Skill loaded successfully. And then it searched for one pattern, read three files, listed one directory, and only then did it start with the implementation. So the skill follows the workflow but we only described what we are building and it's completely reusable. You can also tell it to do something else such as build UI add a category collection page and let's see how quickly and how well does it do that.

And just like that again in about 2 minutes it added a new page. So, back in the browser, we can test it out by heading over to a specific collection like going to maybe sunglasses and then right here using breadcrumbs, you can head over to eyewear and you'll see that we have three pieces belonging to eyewear right here. You can also browse other things such as leather goods and I can notice that we still have to connect it from our navigation bar, but right now we can navigate over from the collections part.

So you can see we have leather, we have eyewear, there's jewelry as well. So you can see that now we have full-on product categories. And that was pretty simple to build, right? This was the same process as running the initial prompt just on a different feature. And this is where skills become much more useful than saving prompts somewhere. You're turning the way you work into something reusable. And that's exactly why I've built the agentic engineering workflow I mentioned at the start of the video.

What you just did with the build UI skill is the same idea applied to the entire engineering workflow. Instead of repeatedly telling an AI to inspect the project, decide what should be built, make the technical decisions, develop the features, verify them, test them, check them, review them, and keep the project context updated with sync. Each one of those becomes a reusable skill. Scope is the first one. It figures out what should actually be built.

Then there's the audit, which studies what already exists. Architect works through the important technical decision. Develop implements the feature. Check simply verifies or reviews the work. Test handles testing. Document updates documentation. sync keeps the project context up to date and debug gives you a proper debugging process instead of letting it randomly change files until something works. The workflow is completely free and open- source and because it's built on skills, it works with cloud code, cursor, codecs, or any other agent.

And on top of it, the agentic engineering course is where I show you how to use all of it properly on larger applications, legacy code bases, and monor repos. Both links are going to be in the description in case you want to check it out. But to get back to skills briefly, I want to tell you that you don't always have to manually type build UI or any other skill name. If you properly wrote the name of the skill and its description, running something like add a new arrivals page using the current design system should be enough because Claude can see the skill description, recognize the match, and load it automatically.

And that's one of the major differences between skills and older custom slash commands. User invoked versus model invoked. But you don't always want both. Imagine you create something like a deploy skill or a commit skill. Those have real side effects and you probably don't want claw designing on its own. Everything looks ready. I'll deploy it. So for workflows like that, you can head over to that specific skill and you can modify its front matter with an additional line disable model invocation set to true.

Now only you can trigger it manually. And another reason why skills scale better than simply stuffing Claude MD is how they load. There are three layers. First, Claude sees the metadata, which is the name and the description. When the skill becomes relevant, it loads the skill MD file. And if the skill has extra references right here in the same folder, for example, scripts or examples, we can load those only when necessary.

So the main skill MD doesn't need the entire design system inside it. It can point Claude to something like references design system MD whenever deeper guidance is needed. Ananthropic calls this progressive disclosure. If you take a look at the skills of the agentic engineering workflow and specifically the scope or architect skills, you can see that alongside the skill MD, there's so much more stuff right here such as the scope template that it can read whenever it needs to.

The modes such as the brownfield project, green field project, plan, replan, and more. three different development approaches, facade, journey, skateboard, and tracer bullet, which are actual software development workflows to follow when building applications, as well as the YAML file right here. All of those are part of a larger skills setup. And in the course, we go a bit deeper into how to build your own skill. Oh, and another pro tip is that you don't have to write every skillmd by hand.

Anthropic has something called a skill creator workflow that builds and improves skills through conversation. And it can even run evaluation cases with and without the skill to check whether it actually improves Claude's behavior. Because a skill that sounds good isn't necessarily a skill that works. So test it. You can run it easily by running the skill creator skill and tell it what skill you want to create. Another pro tip is to not turn this Claude skills folder into a mess.

Every skill adds metadata that Claude has to consider. 10 useful skills are fine, but 100 random ones aren't. There's also a custom skill called skill doctor which can show you which loaded skills are unused and costing context. That way, you can just delete them. And also be careful with the skills you download. They can contain scripts, command executions, and tool access. So, read the skillmd and any scripts before installing.

Whenever you do try to install them, you'll also get some information on whether they might include something sketchy. If we install my own skills right here by exiting the claude and telling it MPX skills latest JS Mastery Pro skills, you'll need to install the skills package. Select which skills to install. You can do them either on a project or a global basis. And you can see that here you'll see that most of them are safe.

And for some reason, if something got changed in the meantime, maybe some are going to be medium or high risk or some are going to be like, please don't install them. But I can assure you that these skills are more than safe. And yeah, the last pro tip would be to try not to design the perfect skill on day one. Rather use it. Watch where Claude still makes mistake and then fix that skill. Add some kind of a missing rule or sharpen the verification step.

Fix a description that triggers it whenever you need it and not at the wrong times. Skills improve from the actual usage. So by this point, you've already moved beyond giving Claude some random individual prompts. Your Claude MD now keeps the rules that should always be available. Permissions control what claude can do. Plan mode reviews the approach before the implementations and skills can give you reusable workflows that load only when needed.

The next step is what happens when one cloud session doesn't need to do every part of the work itself. So let's work on that next. At this point you've learned quite a few cloud code features individually. CloudMD for project context, permissions for control, plan mode for expensive decisions, and your own skills for repeatable processes. And our storefront looks like a real store now, but you still can't actually buy anything.

We're missing authentication, a cart, stock enforcement, checkout, orders, and the customer account. But here's the thing. Building all of that is the exact same loop you've already learned over and over. Describe the feature plan when the decision is expensive and let Claude build, review, and verify it. So, I'm not going to build it at you. This is your assessment. You're going to ship the rest of the store yourself. and I'll give you everything you need, every prompt in order in the free resources linked below.

But before you start, let me show you three things that make this assessment much easier because you don't have to do all of it with plain prompts. First, the UI. You already built the build UI skill in the last lesson. The cart page, the account overview, order history, those are exactly what the skill is for. So you can just use the build UI skill and tell it to build the cart page or build the account overview. It is the same process just a different feature and that's the whole point of encoding your workflow into a skill.

This assessment will reuse it. But second, you're going to have to work on authentication. You could prompt it from scratch, but remember how skills work. They don't have to come from you. Libraries such as Betteroth can publish skills that teach agents how their APIs and workflows are supposed to be used. So Betteroth does exactly that. So we can install their skills. Back within our application, you can open up a new terminal window and run MPX skills add better o skills like this.

It'll then ask you which skills you want to install. You can install some additional ones or just the core o skills, which is what I'll select. I'll select it for my claude code. Press enter a few more times and they're going to get installed immediately. That'll install better odds official skill pack. And you can even see that right here how we have our own skill. We now also have this agents folder. Within it, we have skills.

And then there are two skills. One is called create o and the other one is called better o best practices. Now that you know how to create your own skill, you also should understand how some other people or companies can create their own skills maintained by the developers who build a library and instead of hoping Claude remembers exactly how the latest version works, the maintainers give your agent instructions directly.

And the habit from the last lesson still applies. A skill can contain instructions, scripts, and tools. These come from better off itself, but always look at what you just gave your agent. For example, make sure that the skill will actually get executed based on your prompt. Oh, and one more tip. When you do the off part of the assessment, run it in plan mode first. Authentication touches the database, sessions, protected routes, and customer data, which is exactly what kind of change the plan mode is for.

And I'll leave the exact planning prompt in the resources down below. On top of the skills that we have built and the skills that you can install, there's also a third thing called plugins. In the same way that specific tools can create their own skills, some more well-established tools can publish official Claude plugins. The Stripe plug-in, for example, which we'll have to use for checkout, allows Claude to connect to Stripe's MCP server, enabling AI assisted payment integration development.

As a skill, it provides everything that a skill does, such as best practices, guidance for implementing checkout flows, subscriptions, and more, as well as more on top of it, such as helping you avoid deprecated APIs, and follow Stripe's recommended patterns. So you can very easily install it by copying this installation command. You can do that in the terminal by running claude plug-in install stripe atclaude-plugins-official and just press enter.

It'll ask you whether you want to install the plugin and very soon it'll be installed. So now if you run claude and you run forward slash plugins, you'll be able to see which plugins you might have installed before. I have a couple, but in this case, we are looking for the Stripe plugin, which might already be under installed. There we go. You just need to press enter to authenticate it from Stripe. So, go ahead and press authenticate, and it'll be opened in a new browser window where you'll have to sign into your Stripe account.

Then, you'll have to enable your MCP. I'll do it for the test environment and give it all the necessary permissions and authorize. And that's it. You can now close this tab and return to Quad Code. And just like that, you have successfully authenticated your plug-in. So now you know not only how to create your own skills, but install other people's skills as well as plugins. There's one small distinction between the two.

You can think of a skill as a one reusable process. Whereas a plug-in is a package that can include skills as well as other cloud code capabilities such as MCPS. And you can also browse what's installed with the forward/plugin command. And same rule as always applies. Don't install random plugins. They can contain much more than markdown. So trust where they come from. So now you have everything you need. your build UI skill for the pages, better odd community skills for authentication, and Stripe's official plug-in for the checkout.

The full assessment is in the free resource linked below. It contains a couple of prompts in order from authentication all the way to the customer accounts. So, build it, break it, fix it, use the plan mode where the decision is expensive, and skip it where it isn't. And that's where everything from this course actually becomes yours. If you're just following along, you're not learning as much. But now that you've been watching this video for more than an hour, it's time for you to actually give it a shot.

And when you're done, tell me in the comments how it went. I do read all of the comments. Pause this video, do it, and then let's continue together. So, how did it go? After I ran a couple of these prompts, the last step was to create and hook up my Stripe account. Thankfully, that was easy thanks to the Stripe package and the CLI. So, I was more or less able to do it directly to the terminal, but I simply got the Stripe secret key and added it to the env.

With that in mind, our application now not only looks good, but has a real database and a real checkout where we can actually buy stuff. So, let me add this to a bag. You can see that now we can sign in. So, this is a beautiful looking sign-in page, which looks exactly as I would expected from a luxury storefront. So, let me go ahead and enter my contact information. In this case, of course, we can't sign in because we never created an account, but let's go ahead and create one.

I'll call myself JSMy, and I'll create a new account. There we go. Looks like we are now signed in successfully. So, we can go ahead and add some items to the cart. Let's go ahead and add this uh Bordeaux croc embossed flap bag. Close to 3,000 bucks. As well as let's try to add something else. Maybe these sunglasses right here or this card holder. Let's go with Oh, it's sold out. This is nice. So, the soldout functionality works as well.

And you can see that there's email me when it returns functionality which we can implement later on as well. Let's go with this backpack. Okay, we have added those two to the bag and you can now see how that looks like. We'll need to modify the design slightly so it looks a bit better. But let's try to proceed to the checkout. This actually opens up a complete Stripe checkout in sandbox mode. And oh my god, I would never pay close to 5,000 bucks for a bag and a backpack.

But thankfully, I can use my test card right here by just pressing the letters four and two one after another. And with that, we can now pay. In about a minute, it looks like it succeeded and we can see a thank you page. Of course, the next natural steps would be to take a screenshot of this page right here that says thank you as well as of the other pages that we have seen which don't look as good and then fix the UI of them.

But that will be super simple like I can remain on this page right now, head over to the code and then simply drag and drop the photo while holding the shift key and then tell it the design seems off. improve the UI of the thank you page. And we can say use front- end skills. This should take about a minute. And then without reloading, we should be able to see this page get to its proper look to match the rest of this beautiful design.

And it looks like it found it pretty quickly. It'll load the design skill before reworking the page and fix it. And in about a minute, this is much much better. Or should I say much worse because now I can more clearly see this huge amount that was spent well thankfully on my testing account. But yeah, as you can see, with the right tools and the right process, I didn't even have to tell you how to fix this because I've taught you the process of developing on your own.

And believe it or not, this is it. We have successfully implemented the full functionality for logging in for adding the items to the cart as well as purchasing the items for our account through our Atilier store. Wonderful. And these items are also getting updated. So you can see since we added this backpack, maybe this one has more items in stock. But if we take a look at this one, this one only has three left. So yeah, the store is officially done.

You can go ahead and play with the design a bit more. Fix a couple of those pages that didn't look as good or modify this hero section or center the items in the navigation bar. At least that's something that I would do if I was continuing to develop this application further. But now that we have a fully functional e-commerce store, somebody still has to run it. There's no place to create products, to update the inventory, or manage orders.

We need an admin side. So, in this video, I'll teach you how to do that, too. And keep in mind that that admin side touches almost everything. It touches the database, which we haven't opened in some time. So, now would be a good time if you head over into tables, you can see the exact number of items that we have for each specific product. You can see that these two are low in stock. And for now, we can update the stock manually like this.

But we don't really want to do that. We want to do that through an admin system that touches the database, authentication, products, inventory, orders, and all of that. Now, Claude could investigate all of that inside of our main conversation, but it would fill the same context that we need to use for building. And that's where the sub aents come in. So, let me teach you a bit about them in the next lesson. The customer side of our store is now a pretty good place.

A customer can browse products, search, create an account, add products to cart, check out, place an order, or see their order history, but somebody still has to actually run the store. We need an admin side where someone can create and edit products, manage categories, update the inventory, see the orders or update the order status. And this is where our application has finally become large enough that another cloud code feature becomes genuinely useful because before Claude builds the admin side, it needs to understand quite a few different areas of the application. authentication, products, database, schema, inventory, orders, existing UI patterns.

Claude could research all of that inside of the main conversation. But then all of those file reads, searches, and intermediate findings would fill the same context we're about to use to actually build the feature. And that's where the sub aents come in. A sub agent is another claude agent that receives a focused task and works on it inside of its own context. The main claude delegates the task. The sub agent investigates it and then reports the important result back.

So instead of your main conversation carrying every file and every search the sub agent needed, you mainly get back the useful findings. That's the real value. Sub aents give you context isolation. They're not magically smarter versions of claude. They're only useful because some work can happen separately. And don't think of them as AI employees. Because this is where sub agents sometimes get over complicated. People create things like senior staff backend engineer or elite security architect, worldclass React expert.

But Claude doesn't suddenly gain new knowledge because you gave the context window a fancy job title. The better question is what work can happen separately that my main conversation doesn't need to carry for our admin application. That's pretty obvious. Before implementing anything, we need several independent investigations. So let's delegate them. Now tell the main claude something like this. Before building the admin side of our project, investigate the existing application using separate focused sub aents.

Have them independently inspect the products categories and the current Drizzle data model, stock and inventory behavior, authentication and safest minimal way to add admin access orders and the current order life cycle existing UI pattern. So we can reuse each sub agent should return the current behavior, relevant files, important constraints, and a recommended approach. Do not implement anything yet. Combine their findings into one concise summary when they're done.

Run it. And now watch Claude do its work. It'll dispatch five focused investigators in parallel. This is a good example of a parallel fan out. None of these agents need an answer from another agent before beginning their investigation. Rather, they can independently explore the parts of the codebase and then report back. One is investigating the data model. Another is investigating the stock behavior and another investigating off and admin access and another investigating order life cycle and the last one is investigating the UI patterns.

The main model is not doing anything. It is waiting for all the findings to come back and then it'll combine their findings into one summary and then you can do something with it. a beautiful example of a parallel fan out. So, let's give it some time to run. You can see for how long each one of these has been running and how many tokens is it spending. Even though it might seem like it's a lot of tokens, you would spend more tokens and more time if you just let one agent do the thing.

This way, the work is being done five times as fast. one already finished after a minute and 20 seconds and we're waiting for the four other ones to finish as well. You can switch to another model to see what it is doing at any time or simply get back to the main four in one to go. The UI patterns agent is still working and that one reported too. All five investigations are complete and here are the combined findings.

We can see everything we need to know about our data model about the stock how there are four states the constraints about it as well the o and the admin access the recommendation on how to approach authentication for the admin panel and then there's orders how we can keep track of them or increase the number of items and then there are UI patterns that follow this editorial luxury system entirely stored in globals.css CSS.

There's some crosscutting themes and an important decision to consider before proceeding. That's it. This took 3 minutes exactly, but it did more than 15 minutes of work. So, why didn't we just let the main claude read everything? Just imagine the product investigation reads 10 files, o reads another eight, and orders reads another 12, and then UI exploration reads another 10. The main claude may only need a few important conclusions from each investigation before it can build a feature.

Sub agents let all that exploration happen somewhere else. The main conversation gets the useful result without carrying the entire journey. And that's the whole point. And you may have already seen claude delegate work automatically. I mean claude code includes built-in agents for different kinds of jobs. For example, explore, plan, or general purpose. Explore is useful for readonly codebased investigation. Plan helps with research during planning and general purpose can handle well, as it says, general purpose tasks.

But you don't always need to wait for Claude to decide. You can simply say use an explore sub agent to inspect how admin authorization should fit into the current better o implementation or something like delegate the order life cycle investigation to a separate sub agent and return the important findings underneath this. The current claude code tool is called agent. You usually don't need to call the internal tool yourself.

You can just tell Claude what should be delegated and let it handle the mechanics. So once the research comes back, don't immediately say build an admin dashboard. First decide what this first admin version actually needs for our store. Keep it focused. We need admin only access, basic dashboard overview, product category and order management as well as inventory updates. We don't need multiple admin permission levels, warehouse management, advanced analytics, staff invitations, refunds, or complicated fulfillment systems.

At least not yet. Now, even without our admin panel, but just with the full logic of the databases, authentication, and more, our application has changed massively since we ran that first deep scan. Our application now holds authentication sessions, customer data, payment logic, orders, and very soon an entire admin side with its own authorization. So before we begin working on the admin platform of the application, we want to commit and push everything that we've done so far because there's a lot of work that was done.

So I'll tell it commit and push all the work done so far. And as soon as the changes are in, we can run the second code rabbit AI deep scan. Let's let it look across of it all to see just how well have you done your assessment or how well Claude has developed it. You can also connect Slack to be updated when the deep scan is done or you can just head over here where you can see them estimating and then running. The deep scan report will likely be different for you than what it is for me.

But thankfully, the process of resolving some of these vulnerabilities is the same as what I've shown you before. So, feel free to take a coffee until the deep scan is back. Resolve the vulnerabilities which you believe need fixing and then let's continue. And here's the thing. From this point on, building the admin side is nothing you haven't done before. You'd take all of these sub agent findings into plan mode and plan the admin experience.

You'd read that plan carefully, especially around one thing, authorization has to live on the server because hiding the admin link isn't authorization. And then a normal customer should never be able to open an admin URL or call an admin action directly. But that's exactly the kind of decision that you catch in the plan, not after the code is written. And then you'd build it feature by feature. Admin access first, then product management, then inventory, and then orders.

The same loop you've used throughout the rest of the course, describe the feature, plan when the decision is expensive, let Claude build, review, and verify. So the admin side is part two of your assessment. Every prompt in order is going to be in the free resource down below in case you want to follow along. But go ahead and give it a shot. Try to build it yourself or take a look at a couple of hints in that document that I've shared.

So, pause the video and go ahead and do it right now and let me know in the comments how it went. Were you able to successfully add the admin side to this luxury and overly expensive e-commerce store? Hopefully, the answer is yes. But even if you've built it properly, check whether the claw MD or agents MD file that you had from the beginning properly describes the application that you have right now, not the one from five lessons ago.

Because if that is the case, every future cloud session will start with stale information that has no idea about the admin interface or some of the features you developed within it. So update it either manually or through the conversation with Claude to analyze the codebase and update the necessary parts and then review it. Or you can use a skill that I built specifically for that purpose. In this case, the skill is part of the agentic engineering workflow and it is the sync skill.

You can check it out right here. Its goal is to run it after a specific feature or an application is complete to keep the durable knowledge current. Simply put, it keeps your project context in sync with the codebase by checking your latest git commits, updates the relevant parts of clawed and HSMD files, and flags anything that no longer matches how the project actually works. And you can use sync completely on your own.

You don't need the entire workflow as it's free and open source. So maybe this is the right chance to give it a shot if you haven't already. But now just take a look at how your usage of Claude code grew as you kept using the app. You started this course with Claude in an empty folder. Then you added the permissions so you controlled what it could do. You used plan mode when decisions became expensive. You also used a couple of skills, one of which you created yourself, as well as external skills and plugins when you needed them. when libraries themselves provided the guidance and you also used sub agents when the codebase got big enough that investigation didn't belong in the main context and that's the progression to remember.

Don't start every project by enabling every claude code feature you know. Instead let the problem you have create the reason to use that feature. Is that everything you need to know about claude code? Well, definitely not. You just learned how sub agents let Claude split the work into separate contexts so different parts of a problem can be investigated independently. But you can take that same idea much further. What if those agents don't just investigate different parts of the application?

But what if they start building different features at the same time? Well, Cloud Code has a solution for that, too. You can combine agents with isolated Git workre. So each agent can work on its own copy of the repository while building features in parallel. And that's where you start getting into the more advanced side of cloud code. parallel feature development, git workshrees, MCP