How to use Claude Code better than 99% of People

I think there's a lot of people using cloud code wrong, and they're using cloud code wrong because it is one of the most powerful pieces of technology that have ever existed. And there's a way to use cloud code that spin up actual AI employees. But the thing is, you have to set it up in a certain way. And today I'm going to show you what that certain way is. I'm going to show you the nine different areas that you need to master in order to spin up these AI employees. And this episode might feel a little boring at times because I'm going through a setup. I'm teaching you how to actually do it. But I think that the people that actually stick to the end, the people that actually get their hands dirty, that copy what I do, and I'm going to give away all the prompts and all the sauce in this episode, are going to be able to outperform people, are going to be able to build products that work 24x7. are going to build AI native companies, AI native companies that just are able to crush. And I'm so excited to put this together for a free course for how to master cloud code like no one ever before with AI agents that run 24x7 that act like AI employees. Enjoy the episode. Shout out to Anthropic for supporting the channel and sponsoring today's episode. The way I think about an AI employee and setting it up is actually pretty simple. If you want to, if you want cloud code to act more like an employee, you need to give it the same basic things you would give a person joining your company. It only makes sense, right? First, it needs a workspace. In this case, the workspace is called a repo. And that's where the product actually lives. That's where. That's where the files live. And that's where cloud can actually go and do the work. Second thing it needs is memory. Memory is basically the context that you put into the project. So cloud understands what you're building, who the customer is, what matters right now, what good work looks like. And we'll get into that later. And what you've already learned. So it doesn't repeat mistakes. Then it needs a brief. Before cloud is like changing things. Things all around. You want it to understand the assignment. So that's where this thing called plan mode is super, super useful. You're basically saying, look around, read the context, think through the job and tell me how you'd approach it before you touch anything. And for something like that, you might want to use like a fable over an opus. We'll talk more about that. Then it needs a clear ticket, basically an assignment. You know, a real employee does better with an assignment. Why wouldn't an AI employee? Cloud is the exact same. The mistake a lot of people make is they'll say, make the app better. Make this pop. These very vague prompts that are assigned to it. The better way to do it is to be extremely specific. So if you're, you know, if you're creating a landing page and you want to create a waitlist form, you'd say add a waitlist form to the landing page with a success state and check it in desktop preview. That's going to work just a lot better. The next thing it needs is eyes. You know, and you can finally do this in cloud code and it's so, so exciting. So you can do it in the desktop app, which is what I primarily use. You could just say, Claude, open the app, look at the page, click through the flow, inspect what is confusing and tell me like what a customer would actually experience by going through this. That's obviously very, very different level of usefulness than only editing files. Then it needs review. So review is just going to look at the before and after changes. So Claude can help review the work too, but you want a system where changes get actually checked against your standards before anything important ships. Then it needs a schedule. So this is when a lot of people start having that aha moment where it's an actual 24-7 employee. You can basically give Claude. Recurring work like a morning brief, weekly issue review, pull request reviews. Claude calls this routines and we'll get into that in this episode. And the last thing it needs is permissions. So a good employee knows what it can do on its own or when it should ask you for permission. Claude is the exact same way. So it can read files. It can inspect the repo. It could run tests. It can work on small branches. But before touching things like dependencies. Before touching migrations. Before touching payments. These like bigger things. You basically want to make sure that the human owns those trust decisions. And that's basically the map. So the map is basically workspace, memory, ticket, eyes, reviews, schedule, and permissions. And if you're able to do that, that's what I mean by an AI employee. It's basically this working system. You give Claude a place to work. Context to understand the business. You give it a clear way. You give it a clear way to work. You give it a clear way to plan. A way to execute. A way to check the product. A way to review things. A few recurring responsibilities that happen every single day. And then you give boundaries so it doesn't do something super risky. And once you set it up this way, Claude Code starts to feel less of like a one-off chat thing. And really more of like an operating layer for your company. So let's talk about how you can actually set up the first step, which is creating a workspace. So in Claude Desktop. You're going to want to hit the Claude Code section. I prefer using it in the desktop app. It's a lot less overwhelming than in the terminal. So we're going to use that today. You're going to want to go and select your project folder where Claude actually goes and runs. And just for the sake of this demo, we're going to talk about an idea that I found on ideabrowser.com, which is basically a mislead responder for med spas. So basically someone fills out a form. DMs the business, calls after hours, asks about pricing, but the business responds too late. There's an opportunity to create a cash flowing software business there. So we're going to talk about how we'd actually set up this repo, what the structure would be, and what I would want to do if I'm creating an app, if I'm creating a software, I want basically slash app, slash context, slash customers, slash specs, slash demos, slash routines. I'm going to want three. I'm going to want three MD files, and I'm going to talk about what all that means. So slash app is the product. Slash context is the business brain. Slash customers is where the sales calls, the support notes, any objections, customer language, you put that there. Slash demos is where you're going to want to put the demo flows, loom scripts, screenshots, things like that. Routines is where you're going to want to put those recurring prompts, like we talked about these recurring tasks that are going to happen. That'll be in the routines. And then the three root files that you're going to want to have that are MD files that are basically like this operating manual for you are going to be clod.md, which tells you how clod to work. You're going to want a roadmap.md file. That's going to tell clod what matters right now. And you're going to want a review.md file, which is going to tell clod how to judge the work before it chips. So the first, the takeaway I want you to have is clod gets just way more useful when the project explains itself. So how do you actually go and set this thing, things up? What are, what are, what's like the, the best way to do it? This, this is what you should do. So here's the prompt. Help me set up this repo as an AI employee workspace. And then you just say creator update clod.md roadmap review slash context slash context. Customer slash spec slash demo slash routines. And then you say, use this business context. So you can say product mislead responsive for med spa. So you're just basically saying what it is. The buyer, you want to explain who the buyer is. So in this case, it's a med spa owner and operator, the pain that they go through. So the inbound leads are going cold when the team replies too late. The promise, which is respond to every mislead before they book some somewhere else. So you've got a promise. You've identified, you know, what success looks like here. And then the goal, the current goal, build a simple landing page and demo flow. And then this is very helpful to write this before writing, ask me for any missing context that would materially change the setup and keep the first version simple. That's all you need to set up your workspace. While, while, you know, you can do it manually, but the best way to do it is just have this all set up. You can see here, it's going to say, I'll ask you a few high leverage questions. First, the answers change how I structure the demo flow and the customer spec folder. Everything else I'll fill with sensible defaults and keep V1. So it's going to go and ask me a bunch of questions. You know, I'm going to go and answer it really quickly. And based on that, it's going to set up my entire workspace. So it's optimized. So, you know, it's, it's the way I see it is like you're setting yourself up for success. If you don't have all. the optimized MD files and the optimized places and folders, then your cloud code is going to trip here and there. So we're going to go ahead and allow here, and it goes and creates the setup. Okay, so now we've got all the files and folders created. You can see here you've got the cloud MD file, the AI employee operating manual, business in one line. We've got the roadmap.md. We've got the review.md. We've got the folders there, but we need to optimize it more. So I've got this prompt ready. How do you optimize a cloud MD file so it actually feels more like an AI employee? You have to give it a working style, right? If you hired a junior employee, any employee, you would want to be like, this is how I would like you to work. So you give it the work style. You say, I want small, reviewable changes. I want you to explain the plan before. I want you to explain the plan before editing when the task affects product behavior. I want to keep the changes focused. I want you to use the existing code style. I want you to run relevant checks after changes. And I want you to summarize what's changed, what you tested, and what needs human review. You want it to have business context too, right? So you create a business context section. You say, the product helps med spas respond to missed inbounds leads faster. So you're reminding it, what are we doing here? Here's who the buyer is. It's an owner and operator. And you give it the promise again. You tell it what the quality bar is as well. You say, the landing page should be clear in five seconds. The demo flow should work on desktop and mobile. You use specific customer language. All this stuff, you're putting in your cloud.md file because you want it to know how you work, what does success look like to you, and just you're guiding. You're guiding. You're mentoring. You're mentoring it. So we've now gone and optimized the cloud.md file. Really, really helpful to do. All right, so it's updated my cloud.md. It's actually updated my review.md, but I'm going to talk about how we can give it even more feedback on review.md. The next step I want to do is basically tell cloud what it needs to focus on this week. So we're going to talk about how you can optimize the roadmap.md file, which is basically, what is your goal this week? So I say the current goal is to build a simple demo that shows how a med spa can recover misleads. And this week I want you to focus on a landing page, a waitlist form, a demo flow, and then sending looms to 10 med spa owners. An important thing to do is what here is out of scope. So I'm including that payments are out of scope, CRM integration, admin dashboards, multi-user permissions, and the reason I'm doing this is I want it to basically cook on the MVP. I want it to be like exceed my expectations. So that's what I'm going to do to optimize the roadmap.md file. Now, how can you optimize the review.md file? This is the file that knows your standards. What, you know, what UD looks like to you, what is acceptable and not acceptable. So I've got a prompt here for that. Here's my review.md file. Here's my review checklist. So I say before shipping, I want you to, does change match the current roadmap? Is the change small enough to review? Does the main user flow still work? Are there mobile layout issues? Are form errors handled correctly? Are there off payment or production data risks? Did we add unnecessary complexity? And because we're building a landing page, we want to say, can a first time visitor understand the offer in five seconds? Is the CTA visible? Is the copy specific to the buyer? And does the page use the word? Would customers would actually use? So this is specific to my MedSpa idea, but you can imagine how you can use this for whatever idea you're looking at. And you're basically just, you're letting Claude know that, hey, you can't just ship garbage. You know, we can't ship AI slop. And the beauty about, you know, Opus 4.8 or Fable 5, you know, with the right MD files and the right structure and the right brain, it does such a good job, but it does need this, these guardrails. So it says the review.md is now complete. The workspace scaffolding is essentially done. Claude.md, roadmap, review, and all five folders are populated and consistent with each other. We just need to name the product and confirm the demo is simulated on screen. And then we can go ahead and make progress on this business idea. Okay, so we've got the workspace set up. The next step is the brief. So this is the piece that feels really small, but it does change the whole way you're going to use Claude code. When you give a real person an important task, you don't just throw the task over the wall and just hope that they understand it, right? You talk through it first. You explain what you're trying to accomplish, what matters, what the constraints are, and what would make the work good and not a waste of time. That's how I want you to think about plan mode. Plan mode. Plan mode is basically the moment where Claude looks around the project, reads the contacts, and thinks through the job. And it shows you the approach before it starts changing files. So for this demo, I just want to use something that's simple and concrete. I'm just going to ask Claude to add a waitlist form to the landing page. But instead of just saying add a waitlist form, I'm going to give it a real brief. So I'm going to show how you'd use plan mode here. So I say use plan mode. I want to add a waitlist form to the landing page. First, inspect the current app, the ClaudeMD, the roadmap.md, and review.md. Important that you ask it to do that, by the way. Then you say, then give me, well it's important, I'll explain why, because it's gathering the context. It's important to gather the context to get the best quality output. Then you say, then give me the files that need to change, the smallest clean implementation, the user experience, the risks, how we will verify it, and what you are intentionally leaving out. And then you say, wait for my approval before editing. As it's cooking right now, the important thing here is you're now going to have something to react to. It might not be perfect, but you can say, good, just keep the front end only because this is just a demo maybe. Or actually connect this to Supabase because I want real submissions. Or the form isn't simple enough, just give me name, email, company. You can say, thank you. Thank you. You can say things like, don't touch auth and payments or the database yet. So it doesn't need to be perfect, but you're basically starting with something that is well thought through. So now you can see Claude proposed a plan. Here's the context. It gives me the files that need to change. It tells me the smallest clean implementation with the tech stack. It says Next.js with TypeScript. It tells me the user experience. It explains what it looks like. The one line. I promise. So I can go and review all these things. It shows me my risks, like spam and abuse. And just gives me this whole plan. And I then can go and say, accept. If I like it or I can give it, I can reject it or revise it based on my feedback to it. So I'll go ahead and accept it. The way to think about plan mode in general is that anytime you're doing meaningful product work, you're probably going to want to do planning or meaningful work in general, actually. You're going to want to do some planning. It's worth it. The way I think about it is it's like, you know, the quote, measure twice, cut once. That's what you're doing here. The next big piece to understand is the ticket. And this is where a lot of people accidentally make Claude worse than it needs to be. So Claude Code is very good at doing the work, but it needs to know what done looks like. And that's basically what a ticket is. A ticket is a small, clear assignment, with a visible finish line. If you were managing a person, you probably wouldn't say, hey, go and improve the product, right? You would say, do a specific task, like add a wait list form to the landing page. It should collect a name and an email and a company. And after someone submits, show a simple success message. And by the way, keep it consistent with our current brand identity. That is a good ticket. If it gives Claude the job, the scope, the expected user experience, and the boundary. So I'll give you a few examples of tickets that I would give to Claude. Create a pricing page using the existing design system and keep it consistent with the homepage. Or fix the onboarding redirect bug after the email verification. Turn these five customer objections into a short message. To a sharper landing page section. These are small enough that Claude can understand the finish line and just get to work. And you can review the work afterwards. There are a bunch of tickets that do go sideways, but they're mostly the vague ones, right? Make the app better, make this more viral, add AI, build the whole thing. And the problem with those prompts is Claude has to guess what matters. And once it starts, guessing, you're no longer managing the work. You're cleaning up the work. I will say Fable 5 has done an amazing job at actually guessing what matters, but I still believe that this is an important part of the whole process to get the most out of it. So after I've approved the plan, I want to give Claude a prompt that keeps it really focused. So I say, implement the improved plans as one focused change. Keep the change small enough that I review it in the diff view. I'll explain what diffs are in a second. After editing, run the relevant checks, open up the app in the desktop preview, summarize what's changed, tell me what you tested, and tell me what still needs human review. The translation, like what is a diff? The quick translation is it tells you the before and after. So if Claude is going to go and edit, copy, adding files, removing files, the diff is going to show you exactly what has changed. And what's cool is in the Claude desktop app, it's pretty visual. You can click into the change files, you can review edits, you can leave comments, and you can ask Claude to revise anything that feels off. And that's really why ticket size matters so much. Because if it's a small ticket, you can manage it. But if the ticket is massive, you end up with a giant pile of changes that might look impressive, but it's hard to really trust it. So the rule here is pretty simple. Give Claude one clear ticket. One ticket at a time, which is one task, one finish line, and one reviewable change. So here's the output. You can see here visually, it shows here's the file, here's what it does. Here, I'll make this a little bigger. It's just giving me, you know, it's changed this shell. It's done this headline. It's made mobile. It's made mobile first styles. It shows me what has been tested. It shows me what it couldn't do and why it couldn't do it. And it tells me what actually needs human review. What actually needs human review. And then we can go from there. So super helpful. So the fourth piece to understand is what I call the eyes. So this is where Claude Code really starts to feel like an operator of some sort. When I say eyes, by the way, I don't necessarily just mean the visual preview. I mean, Claude needs a way to inspect work after it builds it, right? If you think about a good employee, they do the task, and then they check the task. They open the product. They click the flow. They run the test. They look for errors. They check the console. Maybe there's some weird edge case that they're going to check. They ask, would this actually work for the customer? And that's the loop that I want with Claude Code. You know, you build the thing. You run the thing. You use the thing. You test the thing. You improve the thing. The desktop preview is a really big part of that because product work especially is visual. A lot of work is visual, but product work especially. A landing page can load and still feel really confusing. A form could submit and then still kind of be awkward. A button can be on the page, but still be hard to notice. A headline can explain the product, but still miss the buyer's pain. So the eyes are bigger than the browser preview. It's a bigger. It's a bigger idea. You know, Claude can do things like run the test suite. It can check console logs. It can check network errors. It could check if the form actually fills the submission. So it could do really anything. And after Claude builds the waitlist form, I actually want Claude to inspect the whole thing from the customer's point of view and the product operator's point of view. So we're going to go ahead and check that and see how that works. So here's. Here's my problem. Start the app and inspect the waitlist flow. Open the landing page and desktop preview. Check the experience from the point perspective of a med spa owner. Seeing this for the first time, then verify the implementation. And then here you say, tell me what what the buyer understands in the first five seconds. What feels confusing or low trust? Whether the waitlist form works, what happens after submission? So asking it a bunch of just questions and then say, make one. Focus path to improve the highest impact issue again. This is what a good employee does, and we're just making a part of our process so you can see the website has been created and it's checking to see if it's rendering correctly. It says now testing the flows as a first time visitor empty submit first click join the waitlist with nothing filled. So then it says the empty state works. It's used for tools for that. Look, you can see it went in. It found read the page and used a computer. I mean, this is absolutely insane that it can actually do this. And that's why this is important to do. You can see the success state has rendered. It's verifying the back end that it wrote the record. It's checking the console and network for errors. Look at this. It says the highest impact issue. The page asks a cold med spa owner to hand over their email. No reassurance about what the waitlist is or whether they'll get. Spam. This is the single biggest friction point on the action. The page asked for my focus pass at expectation setting. Micro copy, micro copy at the CTA. Again, this is really good employee doing, doing stuff, right? This is what you want out of a good employee. So it's really cool that cloud code has eyes, right? And it's amazing how few people actually use the eyes. So when you, when you make it a part of your process, you're going to have better QA. You're going to have just better. You know, better product in the end because you're testing it to make sure, you know, it could work. It could do things. It's how you want it. So the eyes underrated. The next piece we're going to cover is called review. So this is the part of the whole AI employee setup that actually makes it usable because once Claude can build things click quickly, as you can see, it's really easy. As you see the bottom, the bottleneck moves to the judgment. So did it solve the right problems? Did it change the right files? Did it create this like weird edge case? Um, did it make the product clear for the customer? Um, that's why the review matters so much, because if you're going to let Claude do a lot more of your work, you need a way to inspect that work without turning every task into this like hours of code review and stuff like that. So I would think about review in layers. The first layer is your own read. So you open the diff view in Claude desktop. Um, like we talked about a diff is shows you a before and after of what's changed and look at the files that Claude has touched. Click through the changes. You can ask yourself a few questions like, does this match the ticket ticket? Does this match the plan? Is there something surprising in here? Um, and surprising. Um, and surprising changes is usually where the risk is. So it's an important question to ask if Claude was supposed to add a waitlist form, for example, and suddenly it changed off and routing and databases and stuff like that. And I would want to know that immediately. The second layer is Claude is reviewing against your standard. So you remember we created the review dot MD file earlier. Well, you're asking Claude to review the work against what this project actually cares about. So how do we prompt Claude code to, to go deeper on this? So I'm going to say use review dot MD as the standard review, the current changes for the production issues, broken edge cases, and confusing user flows, and then separate issues into must fix should fix and okay to ship focus on bugs, user confusion, security risks, and unnecessary complexity files, files change outside the scope of the ticket and anything that violates the roadmap. Okay. So all that good work that we did with the review dot MD upfront is going to pay dividends. Um, and let's see what it, let's see what comes, let's see, let's see what they say. So you can see here, it's separated into must fix should fix and okay to ship. And you know, it asked me if I want to fix one and two now, good to know, right? If I'm actually creating an app and putting into production, you know, it's helpful to know this sort of stuff. And I just find this format. Must should and okay to be super, super helpful. So you can do slash review, um, if you want to just review your, your code, but if you're doing really risky stuff, you might want to do slash ultra review. So if you see here, it says launch a remote, remote ultra view session for this repository. And that's going to be, you know, before, before you're actually posting a production, if it's like a big feature, maybe it's authentication. Then payments, that sort of thing. You're going to want to do something like an ultra review. So a little tip, little tip there as well. The sixth piece is the schedule. Um, this is basically this idea that the AI employee is working proactively for you. So up until now, we've mostly been talking about Claude helping you while you're sitting there with it and you've got to prompt it and review. You give a context, you know, you give it a plan. you give it a ticket, you have it billed, inspect review the work i mean that's really cool but an employee is a bit more valuable in the sense that they've got this repeating responsibility um that they go and do tasks so you know every business has work like this right like someone has to look at customer notes or someone has to notice which issues are coming up someone has to review open tasks and say hey there's a thing on this list that i gotta go do um that kind of work is you know quote unquote boring not glamorous but it's the exactly it's it's exactly the type of work that keeps a company moving that keeps them progressing and that keeps them adding value to customers so i would start right there um i wouldn't start by asking claude to ship production code while i'm asleep um i would start by just giving it a recurring operator task eventually you can get to more cool glamorous tasks but i would just start by you know create a morning brief for me and this is using a tool on cloud code called routines so here's a sample routine prompt i say every weekday morning at 7 a.m read slash customer slash contacts open github issues if it's connected and then create or update slash contacts morning brief md with the top customer pain point from the latest notes one product risk one recommended build task for today and one question i should ask you is ask customers today don't edit production code don't open a pull request and keep it under 500 words now this is something that you can do no matter what you're building right and thank god we got that repo right slash customer slash context um and and now you're still you're probably starting to see like how this all kind of comes together so let's set up this task and see how it works cool so that's all done i like this task as your first task because it's it's useful and controlled it's not like changing the product it's not touching production or anything like that it's not building random features just reading the business looking at the current work and giving you a sharper standing point for the day so this is really cool um and took like a few seconds to uh to set up but what if you want to take that to the next level i would add something like a weekly ops review so let me paste in the prompt so i would say every friday at 3 p.m review open issues and recent customer notes group related issues or identify duplicates suggest the single highest leverage fix for the week and post the summary to slash context slash weekly ops md do not edit code done so the second scheduled agent is live and what i think is so awesome about this is you know you're not going to have issues just piling up claude is going to help you see these patterns and maybe there were customer complaints that you didn't see um maybe people had the same onboarding problem and it's going to help you like prioritize your week and and it's it's it's almost like a chief of staff that helps you do that so now i have two routines running you can see it here the morning brief and then the weekly ops review so the last thing i would add here and i encourage you to do the same thing is to create a loop how am i going to create a loop i'm going to post this uh poll request so i'm going to say when a poll request opens review it using review.md leave comments only on issues that could create bugs broken user flows security problems or confusing behavior and then post a short summary with what looks good what needs attention and whether this is ready for human review um so you know once this is done you're going to have every morning claude code telling you what matters it's going to be telling you the patterns um and then every poll request claude is going to check that work against your standards because it's looking at the review dot md and that's this whole concept of like the night shift right like people talk about you know claude code working 24 7 that's what they mean they mean that the work is going to continually get organized the feedback's getting summarized over time as it comes in risks for the business are getting surfaced and then what you should be working on the next set of tasks are getting clearer and clearer the next big piece to understand is how you can have parallel agents parallel work being done at the same time obviously you don't want to have to you know do one thing at a time the dream is to have multiple agents you know doing multiple things at the same time um so it's not really one employee right you're you're you're duplicating five ten fifteen twenty employees is that possible yes and i'll explain you how that works because if your work is scoped well claude could actually move forward a few things at the same time in claude desktop basically the code tab can run separate sessions so each session could have its own context and its own set of changes and and with work tree isolation those changes can stay separate instead of all getting mixed together so the simple way to think about it is this each session should feel like you're handed one clear assignment to one person so imagine you know you sit and sit down in the morning and you want three things to be moved forward the first thing is technical so maybe the onboarding redirect is broken after email verification and you need someone to figure out figure it out and just fix it the second thing is product clarity the landing page hero is maybe too vague um and you want the medspot medspot owner to understand the value in the first five seconds and the last thing is sales um maybe you've got a bunch of customer notes and you want to turn them into a sharper demo script um those are all really different jobs right um one is debugging one is product and copy one is sales and the enablement um in the old workflow i would probably do those one after the other um in the ai employee workflow i can give each one its own clod session and with the same product context and a very clear output so the bug session uh fix should come back with the root cause the files that change the checks it ran and what i should look for in the diff the landing page session well that should come back with a before and after hero the customer language that you use and then the landing page session well that should come back with a before and what changed in the preview and why the new version is clearer and the demo session um well that should have pulled the customer notes the objection it was trying to handle and what i should review before recording so the unlock here is this you don't want to dial a giant pile of ai work at the end of the day that you have to untangle because that's not fun you basically want you know little packets of work that the human being could you can inspect accept revise or reject so okay let's let's what does this mean in practice how can we actually do this i would use a prompt like this so i would say work on the onboarding redirect bug after email verification use the project context files before you propose a fix start by explaining what you think is causing the bug and which files you need to inspect after i prove the plan implement the smallest clean fix and when you're done give me the root cause and then when you're done give me the root cause and then when you're done give me the root cause the files you changed the checks or tests you ran what you should review in the diff and anything anything that feels uncertain now for the landing page uh hero you can do a similar format of the prompt and you can just say improve the landing page hero so a med spot owner understands the value in five seconds use claude.md roadmap md review.md and the latest customer notes important to include that there keep the change focus on the hero section unless a small supporting change is necessary and when you're done give me the before and after etc etc and lastly for the sales bit i would say a similar type prompt i'd say read the latest customer notes and turn them into a short demo script for the mislead responder use the customer's actual language where possible the demo should show pain the product moment and the payoff and when you're done give me the demo script etc etc so what have i done here i gave each session a clear job the same project context and a specific handoff the point is not to have ai spray work in every direction the point is you wake up you pick the three most useful work strong work streams you have claude move each one forward in a way that you can actually review the eighth piece is permission we've got one more piece after this so permissions are really important because this is risky business i think about permissions the same way i think about delegation there's some things that claude can do freely there's some things that claude should ask about some things they got to stay with the human so let's talk about safe actions ask first actions and human own actions so safe actions are things like reading files inspecting code bases proposing plans running local tests edit a small feature branch update docs create a draft pull request ask first actions are things like installing dependencies Changing database migrations, touching authentication, changing payment logic, deleting files, things like that. And then human-owned actions are production deploys, customer data decisions, billing decisions, security-sensitive changes. You still want that to be a human being-led. Even if you do have AI employees, that high-risk stuff, you still want to be with human beings. In Cloud Desktop, you can actually choose permission modes depending on how much control you want. So you can start conservative, and then you can use plan mode for the bigger changes. And you can use manual review when you're learning the system. So I would let Cloud move faster as the repo brain, the review checklist, and task scopes get stronger and stronger. That's the management model. You give the AI room to work and boundaries. And I wish more people did that. Going YOLO mode, it's a bit too risky. So thinking about permissions as a strategy is going to be helpful to actually be able to scale your team of AI employees. The ninth piece to understand is skills, connectors, and hooks. This is our last piece. This is the part where. Cloud Code stops feeling like this generic thing, and it starts feeling like it belongs to your company. So I'm sure you've heard of skills. What is a skill? It's basically a repeatable way of doing work. If you find yourself typing the same prompt over and over again, chances are that should just be a skill. So for example, in this MedSpa project I was working on, I would make the landing page tear down a skill. And every time I use it, Cloud should look at that page. It's like a MedSpa owner. And check off that five-second clarity, find that vague copy, and look for the missing trust signals, inspect the CTA, and suggest one focus improvement. I'd also make something like a customer notes skill. You know, I'd read the latest calls or support notes and pull out the exact words that customers use, the repeated objections and the buying triggers that keep showing up. That's super, super useful because now Cloud isn't just building. It's building from my opinion, right? It's building from customer language, and this is a whole trend that I'm seeing happen more and more, and it just makes sense that you'd use that. You can also use that same skill when you're creating copy for ads. I would also do a demo script skill. So I would take the latest product state and customer notes and turn them into a short demo. You know, here's the pain, here's the product moment, and here's the payoff. That's the type of thing that's going to save you. There are places you can download skills, or you can just, you know, create the skills yourself. If people are interested, I can do a deep dive on different marketplaces for skills and how to explore them. Let me know in the comments section. So what is a connector? Well, the connector gives Cloud just better context. So, you know, it gives it access to GitHub. It gives it access to linear. If you use that access to Google Drive, Slack, it's basically just a plug-in that allows you to, you know, access all these different tools. And what's a hook? A hook are the guardrails around the work. So after Cloud edits code, run formatting. You know, before a PR summary, run tests. Before a change ships, run checks that matter. So you've got skills that make the work repeatable. You've got connectors that give Cloud better context. And now you've got hooks that make the workflow safer. And when you combine all those with your roadmap, your review standards, your customer notes, and your routine, Cloud just becomes a lot more bespoke for your company. And that's kind of the bigger point with all these things. These are like power-ups for your business. And you can imagine that this is creating a kind of moat, you know, if you have a really good system around this. It's creating a moat because you're going to get really good outputs from your Cloud code. Okay, so by now, I hope you understand like the main components of using Cloud code to make it an AI employee. But you might be thinking to yourself like, okay, how can I actually make a plan to try this? Well, here's a seven-day plan that I would give to someone who wants to create a digital AI employee. So on day one, and by the way, you can do this in seven hours, you can do it in 70 minutes, you can do it in seven days, you can do it in 31 days. It depends how technical you are, how much time you have, are you working a job? But, you know, I thought it would be fun to just think about it from a week perspective. So on day one, create the repo brain, you know, create the Cloud MD, the roadmap MD, the review MD, the slash context, the slash customers, all that stuff. You write the customer, the problem, the current goal, and the definition. The definition. On day two, you can run the plan mode. So you can pick one small product task and make Cloud inspect the repo before editing. Your output is a plan. Your output is a file list. Your output is risks. Your output is verification steps. On day three, just build one visible improvement. The waitlist form, the pricing page, the demo flow, the onboarding bug. Choose something small enough to review and real enough. Show a real customer. On day four, use the preview loop. Have Cloud open the app in desktop preview. Click through the flow. Check mobile and improve clarity. On day five, review the work. Open the diff view. Read the before and after changes. Ask Cloud to review against review.md. And use the review code flow for a serious change that you might do. On day six, you can actually send it to 10 people. Send the loom, the demo, the landing page, whatever it is. You end up. Building to some people who might care. Then put their replies into that slash customer repo. And then on day seven, create the first routine. Start with the morning brief. Let Cloud read the customer notes and issues. Then recommend one useful build task. Now you have this loop. It's alive. It's breathing. And you're starting each day with context, feedback, and a next move. And it's basically an AI employee, right? It's an AI employee. Because the final loop looks like this. The customer feedback goes into slash customers. The product direction goes into roadmap.md. The working style goes into cloud.md. The quality standards go into review.md. Small tasks go through plan mode. Changes go through preview and review. Recurring work becomes a scheduled routine. And that's the 24-7 cloud code employee setup. Once you see it this way, you know, cloud code doesn't feel like a chat box anymore. The product, the customer feedback, the docs, the demos, the reviews, the recurring work all start. And they live in this operating loop that over time you have to optimize, right? It's not going to be perfect. But once you start building like this, you're not going to build like the old way. In the show notes, in the description, I'm going to include all the prompts that I went through so you can learn from them, so you can copy this workflow. So you can too, spin up your AI, and you can do that. You can do that with AI employees using cloud code. I think that the leverage you get from spinning up AI employees right now is insane. You can use cloud code, you can use other systems, but, you know, do it. Have fun, get your hands dirty, and I'll see you next time. Have a creative day.