How to use Claude Code better than 99% of People

Get Claude Code: https://startup-ideas-pod.link/claude-greg In this solo episode I lay out the exact system I use to turn Claude Code into what I call an AI employee. My premise is simple: give Claude the same things you would give a person joining your company (a workspace, memory, a brief, a clear ticket, eyes, review, a schedule, and permissions). I build the whole setup live around a real idea I found on ideabrowser.com , a missed-lead responder for med spas, and I share the specific prompts I use at each step. By the end, the product, the customer feedback, the docs, the demos, the reviews, and the recurring work all live inside one operating loop. I close with a seven-day plan you can run at your own pace. And thank you to Claude and Anthropic for supporting the podcast. Setup Claude Code to be your 24/7 employee: https://startup-ideas-pod.link/Claude-code Timestamps 00:00 – Intro: The AI Employee Map 05:47 – Step 1: Creating The Workspace In Claude Desktop 14:53 – Step 2: The Brief And Plan Mode 18:08 – Step 3: The Ticket And Defining Done 22:15 – Step 4: The Eyes And Desktop Preview 26:13 – Step 5: Review In Layers And The Diff View 29:34 – Step 6: The Schedule And Routines 34:32 – Step 7: Parallel Agents And Worktree Isolation 39:14 – Step 8: Permissions: Safe, Ask First, Human-Owned 41:15 – Step 9: Skills, Connectors, And Hooks 44:28 – The Seven-Day Plan 47:42 – Closing Thoughts Key Points I treat Claude Code like a new hire: workspace, memory, brief, ticket, eyes, review, schedule, permissions. The repo brain teaches Claude how I work and what good looks like. Plan mode comes first: Claude reads the context, proposes an approach, and waits for my approval. One ticket at a time means one task, one finish line, and one reviewable change. The eyes matter: Claude opens the app in desktop preview, clicks the flow, checks the console, and reports what a buyer experiences. Routines and permissions turn a chat tool into a 24/7 operator with clear boundaries. The #1 tool to find startup ideas/trends - https://www.ideabrowser.com LCA helps Fortune 500s and fast-growing startups build their future - from Warner Music to Fortnite to Dropbox. We turn 'what if' into reality with AI, apps, and next-gen products https://latecheckout.agency/ The Vibe Marketer - Resources for people into vibe marketing/marketing with AI: https://www.thevibemarketer.com/ FIND ME ON SOCIAL X/Twitter: https://twitter.com/gregisenberg Instagram: https://instagram.com/gregisenberg/ LinkedIn: https://www.linkedin.com/in/gisenberg/

• 0:00Speaker 00

  I think there's a lot of people using Claude code wrong. And they're using Claude code wrong because it is one of the most powerful pieces of technology that have ever existed. And there's a way to use Claude 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

• 0:43Speaker 00

  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 24/7, 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 Claude code like no one ever before with AI agents that run 24/7 that act like AI employees. Enjoy the episode. Shout out to Anthropic for supporting the channel and sponsoring today's episode.

• 1:31Speaker 00

  The way I think about an AI employee and setting it up is actually pretty simple. If you want Claude 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 the files live. And that's where Claude 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 Claude understands what you're building, who the customer is, what matters right now,

• 2:12Speaker 00

  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 Claude is like changing 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? Claude is the exact same.

• 2:54Speaker 00

  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 Claude code, and it's so, so exciting. So you can do it in the desktop app, which is what I primarily use.

• 3:36Speaker 00

  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

• 4:21Speaker 00

  employee. You can basically give Claude recurring work, like a morning brief, weekly issue review, poll 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 could 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, all these like bigger things, you basically want to make sure that the human owns those trust decisions.

• 5:05Speaker 00

  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, understand the business, you give it a clear way to plan, a way to execute, a way to check the product, a way to review things, or 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.

• 5:47Speaker 00

  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 idea browser.com, which is basically a mislead responder for med spa, med spas. So basically, someone fills out a form, DMs the business, calls after hours, asks about pricing, but the business responds too late.

• 6:31Speaker 00

  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 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.

• 7:12Speaker 00

  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 like 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 claude.md, which tells you how Claude to work. You're going to want a roadmap.md file, that's going to tell Claude what matters right now. And you're going to want a review.md file, which is going to tell Claude how to judge the work before it ships.

• 7:55Speaker 00

  So the first, the takeaway I want you to have is Claude 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 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, create or update claude.md roadmap, review, slash context, slash customers, slash specs, slash demos, 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.

• 8:39Speaker 00

  So in this case, it's a med spa owner, an 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 somewhere else. So 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.

• 9:24Speaker 00

  And 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 think, see it as like you're setting yourself up for success. If you don't have all, you know, an optimize, the optimized MD files and the optimized places and folders, then you're, you're

• 10:09Speaker 00

  You know, Claude 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 Claude 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 Claude 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.

• 10:53Speaker 00

  You say, I want small reviewable changes. 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, you know, have business context too, right? So you create a business context section. You say, the product helps med spas respond to missed inbound 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.

• 11:36Speaker 00

  You say, you know, 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 Claude.md file because you want to just, you want it to know how you work, what is, what does that, you know, 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 Claude.md file. Really, really helpful to do. All right, so it's updated my Claude.md. It's actually updated my review.md, but I'm going to talk about how we can do, give it even more feedback on review.md. The next step I want to do is, is basically tell Claude what it needs to focus on this week.

• 12:21Speaker 00

  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, simple demo that shows how a med spa can recover missed leads. 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 wanted to basically cook on the MVP. I want it to be like exceed my expectations.

• 13:06Speaker 00

  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 beauty looks like to you, what is acceptable and not acceptable? So I've got a prompt here for that. 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

• 13:51Speaker 00

  understand the offer in five seconds? Is the CTA visible? Is the copy specific to the buyer? And does the page use the words customers would actually use? So this is specific to my med spa idea, but you can imagine how you can use this for whatever idea you're looking at, 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.

• 14:34Speaker 00

  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

• 15:19Speaker 00

  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 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.

• 15:59Speaker 00

  First, inspect the current app, the Claude MD, 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, 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 for the first version. And 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.

• 16:39Speaker 00

  And it's not, 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 Superbase because I want real submissions, or, you know, the form isn't simple enough. Just give me name, email, company. You can say things like, don't touch off 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 the 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.

• 17:23Speaker 00

  It tells me the user experience. It explains what it looks like, the one line promise. So I can go and review all these things. 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, 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.

• 18:08Speaker 00

  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 approve the product, right? You would say, do a specific task, like add a waitlist form to the landing page. It should collect a name and an email and a company. And after someone submits, show us a simple success message. And by the way, keep it consistent with our current brand identity.

• 18:52Speaker 00

  That is a good ticket. 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, or fix the onboarding redirect bug after the email verification.

• 19:24Speaker 00

  Turn these five customer objections into a sharper landing page section. Section. These are small enough, these are small enough that Claude can understand the finish line and just get to work. And you could 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, 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

• 20:07Speaker 00

  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

• 20:51Speaker 00

  going to show you exactly what has changed. And what's cool in it is in the Claude desktop app, it's, 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 you know, it's hard to really trust it. So the rule here is pretty simple. Give Claude one clear ticket at a time, which is one task, one finish line, and one reviewable change.

• 21:35Speaker 00

  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, it's, it's changed the shell. It's done this headline. 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.

• 22:19Speaker 00

  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, what 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.

• 23:00Speaker 00

  The desktop preview is a, 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, are bigger than the browser preview. 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. Check, it could check if the form actually fills the submission. So it could do really anything.

• 23:41Speaker 00

  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, and see how that works. So here's my prompt. Start the app and inspect the waitlist flow. Open the landing page in 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.

• 24:23Speaker 00

  So asking it a bunch of just questions and then say, make one focus pass 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 use four tools for that. Look, you can see it went and 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.

• 25:06Speaker 00

  You can see the success state has rendered. It's verifying the backend 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 with 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 add 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 Claude code has eyes. Right? And it's amazing how few people actually use the eyes.

• 25:51Speaker 00

  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 see, the bottom, the bottleneck moves to judgment. So did it solve the right problems? Did it change the right files?

• 26:35Speaker 00

  Did it create this like weird edge case? Did it make the product clear for the customer? 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 you in Claude desktop. 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. You can click through the changes.

• 27:16Speaker 00

  You can ask yourself a few questions like, does this match the ticket? Does this match the plan? Is there something surprising in here? 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 auth and routing and databases and stuff like that, 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 M D 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?

• 28:01Speaker 00

  So I'm going to say use review dot M D 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. So all that good work that we did with the review dot M D upfront is going to pay dividends. And let's see what it, let's see what come, 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.

• 28:44Speaker 00

  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 of must, should and okay to be super, super helpful. So you can do slash review. 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, payments, that sort of thing.

• 29:28Speaker 00

  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. 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 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 build, 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 that they go and do tasks.

• 30:12Speaker 00

  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 got to go do. That kind of work is, you know, quote unquote boring, not glamorous, but it's the exactly, 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. I wouldn't start by asking Claude to ship production code while I'm asleep. 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,

• 30:56Speaker 00

  create a morning brief for me. And this is using a tool on Claude code called routines. So here's a sample routine prompt. I say every weekday morning at 7:00 AM, read slash customer slash contacts, open GitHub issues if it's connected and then create or update slash contacts morning brief M D 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 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.

• 31:40Speaker 00

  And now you're, 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.

• 31:50Speaker 00

  Cool. So that's all done. I like this task as your first task because 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.

• 32:11Speaker 00

  And took like a few seconds to 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:00 PM, 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.

• 32:55Speaker 00

  And maybe there were customer complaints that you didn't see. Maybe people had the same onboarding problem and it's going to help you like prioritize your week. 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 poll request. So I'm going to say, when a poll request opens, review it using review dot M D.

• 33:34Speaker 00

  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. 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. And then every poll request, Claude is going to check that work against your standards because it's looking at the review dot M D. 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.

• 34:16Speaker 00

  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 clear. 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. So it's not really one employee, right? You're duplicating five, 10, 15, 20 employees. Is that possible?

• 34:58Speaker 00

  Yes, and I'll explain you how that works because if your work is scoped well, Claude can 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 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.

• 35:42Speaker 00

  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. And you want the Med Spa owner to understand the value in the first five seconds. And the last thing is sales. Maybe you've got a bunch of customer notes and you want to turn them into a sharper demo script. Those are all really different jobs, right? One is debugging, one is product and copy, one is sales enablement. In the old workflow, I would probably do those one after the other.

• 36:26Speaker 00

  In the AI employee workflow, I can give each one its own Claude session and with the same product context and a very clear output. So the bug session fix should come back with the root caused, the files it changed, 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 it used, and what changed in the preview and why the new version is clear. And the demo session, 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.

• 37:11Speaker 00

  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 approve the plan, implement the smallest clean fix. And when you're done, give me the root cause, the files you changed, the checks or tests you ran,

• 37:57Speaker 00

  what you should review in the diff, and anything that feels uncertain.

• 38:03Speaker 00

  Now, for the landing page hero, you can do a similar format of the prompt. And you can just say, improve the landing page hero so a Med Spa owner understands the value in five seconds. Use Claude dot M D, roadmap M D, review dot M D, and the latest customer notes. Important to include that there. Keep the change focused on the hero section unless a small supporting change is necessary. And when you're done, give me the before and after, et cetera, et cetera. 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.

• 38:45Speaker 00

  The demo should show pain, the product moment, and the payoff. And when you're done, give me the demo script, et cetera, et cetera. 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 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.

• 39:27Speaker 00

  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-owned 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 poll request.

• 39:56Speaker 00

  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. Like 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 Claude 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.

• 40:42Speaker 00

  And you can use manual review when you're learning the system. So I would let Claude 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, you know, going YOLO mode.

• 41:05Speaker 00

  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 Claude 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 Med Spa project I was working on, I would make the landing page tear down a skill.

• 41:49Speaker 00

  And every time I use it, Claude should look at that page like a Med Spa 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 Claude isn't just building from my opinion, right? It's building from customer language, and this is a whole trend that I'm seeing more, happen more and more.

• 42:30Speaker 00

  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 hours every single week. There are places you can download skills.

• 42:59Speaker 00

  Or you can just, you know, create the skills yourself.

• 43:04Speaker 00

  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 Claude 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 plugin 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 Claude edits code, run formatting. You know, before a PR summary, run tests. Before a change ships, run checks that matter.

• 43:47Speaker 00

  So you've got skills that make the work repeatable. You've got connectors that give Claude 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, Claude just becomes a lot more bespoke for your company. And that's kind of the bigger point with, with, uh, with all these things. These are like power ups for your business. And you can imagine that this is, 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, uh, from your Claude code.

• 44:28Speaker 00

  Okay. So by now, I hope you understand like the main components of using Claude 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 the, on day one, and by the way, you could 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.

• 45:09Speaker 00

  So on day one, create the repo brain, you know, create the Claude 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 of done. On day two, you can run the plan mode. So you can pick one small product task and make Claude 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 to show a real customer.

• 45:54Speaker 00

  On day four, use the preview loop. Have Claude 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 Claude to review against review.md and, 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, 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 Claude read the customer notes and issues,

• 46:38Speaker 00

  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 Claude.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 Claude code employee setup.

• 47:21Speaker 00

  Once you see it this way, it, you know, Claude 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 this, 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 employees using Claude code. I think that the leverage you get from spinning up A employees right now is insane. You can use Claude code, you can use other systems, but you know, do it.

• 48:04Speaker 00

  Have fun, get your hands dirty, and I'll see you next time. Have a creative day.