How Anthropic Engineers ACTUALLY Prompt Claude Code

追加: 2026-05-28

[00:00:00]I went and watched every anthropic engineer who's spoken publicly about how they actually use cloud code and I learned something I wasn't expecting.

[00:00:07]Almost everyone is using it wrong. And so after going through all of the available content from the main anthropic engineers Barry, Mahesh, and Eric, including many of their engineering blocks, I pulled out the five principles I wish I had when I started my journey with Cloud Code. And if you're new here, my name is Frank and I've built an AI agent startup for enterprise and shipped full production apps with cloud code by myself. And in the next minutes, I'll walk you through each principle that I've learned, plus a few resources you can grab and use as we go. Let's get straight into it. So, the first principle is to stop thinking in prompts and start thinking in skills.

[00:00:40]You see, most people open quad code and write a new custom prompt for every single task. And the thing is that anthropic engineers do not do that.

[00:00:49]>> Skills are organized collections of files that package composable procedural knowledge for agents. That's Anthropic's official definition. In plain language, a skill is a folder that tells Claude how to do a specific task the same way every single time. And here is the mental model Barry uses for why this matters. So, three layers, the AI model, the agent plus prompt layer where most people live, and the skills layer, what Barry calls the application layer. So, you can think about it as a phone analogy. So, Anthropic is essentially building the phone. builds the phone and you build the apps on top. This is how it looks on my workspace. This is essentially a project called work with CC or work with cloud code where I have a bunch of skills that I'm using right now to just ease the process of creating content. So I have skills that allow me to ideulate an idea and back test it against any other video ideas that are currently performing well. Videos that are performing well right now on YouTube. We're able to also extract transcripts, check it between others, check the performance, right? The amount of comments, amount of likes, but also allow me to create diagrams, visuals on Excaliraw, also publishing workflows that allow me to then based on this transcript of my video, create a description that is optimized with timestamps and also helps me repurpose to other platforms as well. So, it's a nice suite of skills that allow me to just make my life a lot easier. But if you are getting started and you don't know what skills to start building or creating with cloud code, I recommend you paste this into clu or at least a version for it. This is a discovery prompt anthropic recommends based on my recent sessions. What tasks am I doing repeatedly that should be skills instead of one-off prompts? So I suggest that you run this against your chat history and you'll find three to five skills you should have built already. Okay? And you can get started from there. But there's one thing worth flagging. Okay? Not every anthropic engineer agrees on how heavy a skill prompt should be. So TK from the clock team pushes back on overgineered one, >> you know, and so sometimes when I see people with a lot of like overbuilt skills kind of like, you know, you're an expert planner or something, right? Like that is usually like outsourcing too much and constraining it.

[00:03:13]>> So when you build skills, just make sure to keep the prompts light, okay? Stay the task and let the model do the rest.

[00:03:20]So that's it. Principle one, if you're typing the same kind of prompt twice, it should be a skill, not a prompt. But keep the skill itself thin. Now we get on to principle two. This just states that a skill isn't just a prompt that lives in a folder. It has three layers.

[00:03:34]Okay. Layer one is the description. This is what Claude reads at the start of every chat to decide whether to use the skill or not. If the description is vague, then Claude won't fire the skill.

[00:03:44]If it's specific, then Claude will fire it. Okay? And it's needed. You'll fire it automatically without you typing the slash command. Then we have layer two, the instructions. This is the actual playbook step by step. And then we have layer three which are the tools, scripts, API calls, reference files.

[00:04:01]Right? This is where most of the leverage lives. And this is where almost everyone stops short unfortunately.

[00:04:08]Here's Eric Schultz from the Enthropic team on exactly this mistake. And I think maybe the funniest things I see is that people will put a lot of effort into creating these really beautiful detailed prompts. Um, and then the tools that they make to give the model are sort of these incredibly bare bones uh like you know no documentation function like the parameters and I want you to read that again. Beautiful promise barebones tools. Okay, that's the most common mistake. And so let me show you what layer 3 actually looks like in practice. So here we have the publish skill as I'm toggling here on and off so that you can see it. Okay. And we have the skill.mmd file right and you can see the description. So the description tells claude when to use it. Okay. And the instructions in itself if you scroll down over here are around 80 lines 80 87 lines right? Well you don't you don't really count this as an instruction. So you would say something around 77 lines let's say. So it's it's pretty short.

[00:05:09]But thing is that the actual work sure part of it happens on the markdown file but we also have tools right so we're not depending fully on a non-deterministic way of working we also have deterministic ways of working which is well a bash script okay basically when we have an AI agent triggering a deterministic tool such as a script we don't leave room for wondering right we just launch the tool this is deterministic this is the input this is the output so essentially We are removing the room for error by adding access to these tools and these bash commands that you see over here. Unlike you know if we were to write these commands as words inside the markdown file on a skilled MD file right so by you know segregating it and having elements of the skill that are just code we're reducing that room for error for the AI agent and yeah so we have bash scripts we have a note script as well and we have a python script that handles the school API okay then we have a reference file for the brown tone it's just good to keep it separate since we might not need it at all times and we're so we're keeping it separate from the skill.md file. Okay. And so you see the skill is mostly tools, right? We have a good amount of code on each of these scripts if you consider the total. And so yeah, skill is mostly the tools and the prompt is actually the smallest part from this. And here's a real anthropic engineer doing exactly this. Chuma who forms part of the product engineering team at Anthropic. She's a back engineer who got pulled onto a front-end feature for cloud AI. So watch how she hooks cloud code up to playright as the verification tool.

[00:06:52]>> Let me show you how I implemented the Excel rendering feature using cloud cord. Firstly, entering my prompt, I need you to implement the Excel renderer feature for cloud.AI. Read the Excel renderer design.md, which is the design doc that contains the spec. Use the playright MCP. The feature should allow a user to preview Excel, CSV, and TSV files. So now, Cloud Cord is reading the codebase, starting the cloud.AI app using the playright MCP. And you can see here it does this to get a accurate read of what the feature looks like without it being implemented yet. And now you can see the previewer, it's not actually implemented. And now that it's ready to actually start implementing COD, it asks me for permission to make changes to those files. I will accept that. And now Claude will run off in this loop with playright and continue making changes, validating them, and iterating on that.

[00:07:57]There we go. We have the summary of all the changes cloud code made and it is ready for me to review the code. I still get to >> and that's it. Yeah, that's principle two in action at Enthropic. A back-end engineer doing front-end work because the tool layer is doing the heavy lifting. And so if I had to summarize principle two, it would be to spend less time on the instructions in the skill and spend more time on the tools that make up the skill. Quick announcement before I continue. After working with Microsoft and data camp, I'm finally putting together an inner circle where I will show you how to master cloud code and agentic engineering. Probably the highest lever skill you can learn in this decade. And so whether you're a business owner automating your operations, a manager upscaling your team or someone who wants to build automations that streamline your own job, this is for you. And the best part is that you do not need to be technical.

[00:08:44]And so if that sounds like you, I'll leave a link for you to apply in the description below. I'll see you there.

[00:08:49]Now we come onto the third principle.

[00:08:51]Build composible skills, not custom bloated skills. And this is part of anthropics four principles for skills straight from their engineering blog. So they want them composable, portable, efficient and powerful. And composable means small skills that work together and not just one J skill that does everything in one go. The thing is that I learned this the hard way. When I started building skills, I had one called for/content creation that did literally everything. The idea, the script, the social posts, the whole content creation and repurposing pipeline from ideation to publishing. It became unmanageable. Okay. Every time I wanted to change how scripts were written, I had to rewrite the whole skill. And so what I did is that I split it up. And I have for/ idea for keyword research, forward slash video prep for transcript to outline, forward/guide to reference docs, title for postp production, title generation, timestamps, publish, thumbnail. Okay?

[00:09:55]And each one each one does just one thing. It's really good at one thing and then each one can also call the others and there's three reasons why this works. The first one is because issues are easy to spot at the skills are small enough. And so when a focus skill breaks, you know exactly where to look.

[00:10:16]Second one is because improvements compound. When I update for/title, every workflow that uses it gets just an upgrade for free. And the third reason is that you can reuse instead of rebuilding. So my analyze skill for example plugs into the video prep guide and title skill. So you can build it once and you can reuse it in many places. Now there's two patterns from anthropic engineers that take this one step further. The first pattern is that you can save scripts inside skills which is something that I briefly showed before. And here's how Barry does it on a script he saved.

[00:10:50]>> Traditional tools have pretty obvious problems. Some tools have poorly written instructions and are pretty ambiguous.

[00:10:56]And when the model is struggling, it can't really make a change to the tool.

[00:10:59]So, it's just kind of stuck with a cold start problem. And they always live in the context window. Code solves some of these issues. It's self-documenting. It is modifiable and can live in the file system until they're really needed and used. Here's an example of a script inside of a skill. We kept seeing Cloud write the same Python script over and over again to apply styling to slides.

[00:11:21]So we just ask cloud to save it inside of the skill as a tool for its version for its future self. Now we can just run the script and that makes everything a lot more consistent and a lot more efficient.

[00:11:32]>> I briefly explained before that code is deterministic. So the same input gives the same output every time. Okay, AI tokens cost money and code compute doesn't at least it does to much lesser degree. So Claude writes the same script twice just save it. Then we have pattern two where we can decide how much control we give to CLCO when it comes to using certain skills. So we can essentially add these two from matter flags that most people don't know about. What is from matter anyway? So from matter is if you go to any skill let's say over here and we grab the idea to title skill.

[00:12:10]It's this okay this is a language called YAML and this is what cloud code first sees okay so it has a basic understanding on what skill to use. So when cloud code is working it doesn't just load the whole skill. Okay that would be a waste of tokens. What it does instead is that it just reads the skill that it thinks it would need to use and it would only read the description. And if it sees that it doesn't need it, well, it will just go and check the descriptions of other skills until it finds the one that it needs. But this is essentially the front matter. And there are two things that you can add over here just below. Okay, two flags. So these are the two things that you can add inside the front matter or the YAML file that I was telling you about. We have the disable model invocation. And when we set it to true, only you can fire the skill and claude cannot decide to use it on its own. And this is perfect for those skills that are risky or destructive. Okay, has it has elements that are destructive or risky like publishing, deploying, sending emails to real people and so on, right?

[00:13:14]Then we have the user invocable which we can set to false and this does exactly the opposite. We essentially will be hiding the skill from the slash menu and would allow only clock code to fire it.

[00:13:25]And this is typically when we don't tend to use it and is usually part of another parent skill. So it's more of a you would only add it when it's some sort of helper skill. Okay, that should never be invoked directly or you would never want to use it yourself directly. Okay, and this is how it would look. And if you want a bit of help to understand where to add these two front matter flags to any of your skills, just run this discovery prompt over here. Okay, run that prompt against your current skills folder and it'll find the ones that should be split, scripted, or flagged locked with these flags over here. And now we move on to principle four. The principle that separates people who get value from the skills from the people who don't and just stop using the skills. And so day 30 ends up being better than day one. And that doesn't happen by accident. And the mechanism is simpler than you think. Every time you learn a skill and the output isn't exactly what you wanted, you need to ask yourself one question. Is this a one-time fix or is this a fix that should be in the skill forever because I'm going to be using the skill over and over again and this issue is going to pop up every single time. If it's the second one, then just update the skill.

[00:14:36]You add the principle, the example, the edge case, and the next session just starts smarter. And you don't need to do it yourself. You can just ask clock code. Tell it, hey, what went wrong?

[00:14:47]Learn the lesson. Well, just explain the lesson that you've learned on why it went wrong and just put it back in the skill. And the thing is that most people skip this entirely. They run the skill, they get the output and move on. But that's the flat line on the chart. I update my skills weekly. And because of that, my systems with cloud code just get smarter and smarter and smarter and I'm able to just automate more. But not only that, I'm able to automate at a much better accuracy. Right? That's the most important thing because when you start with cloud code and you ask it to automate tasks, it's not going to get things correctly, you need to teach it and make it improve the same way that you're teaching a person, right? As you keep having cloud code act on tasks and automate tasks for you. You're essentially gathering more data, more training data that then you can turn into edge cases, into examples that then you can feed onto the skill file and then it's just slowly going to learn to, you know, close that error trajectory, right, into a much narrower set of tasks so that eventually the margin of error is is just minimal, right? So that's what you're trying to do. You're going to keep using it. You're gathering data.

[00:15:53]You're adding corrections in the skill.mmd file and by adding tools and whatnot so that eventually it can do the task completely accurately. And this is what Barry meant. Every commit is a sharpening. And here is a discovery prompt that you can run yourself. So you can run that prompt at the end of every skill session that didn't go perfectly and then you just commit the update. And so the summary from principle four is that the skill you use today is the worst version that it should ever be.

[00:16:21]And every session that you work on should just make it better. And now I'm going to present you with principle number five which in this video and probably outside of this video as well is one of the most important principles that I've personally learned from using cloud code for almost one and a half two years already. And the one that I think most people don't talk about enough which is the output format that cloud code gives you. You see, most people ask Clock to write plans, specs, PRDs, right? Things to make decisions or help you with the decision-m process in markdown, okay? Or just in plain text.

[00:16:56]But TK from the CLCO team explains why that's now a mistake and there is a more efficient method. The plans are so long, I honestly have stopped reading them.

[00:17:06]And this was honestly a mistake. Like I think that you still need to be really in the loop. You really need to understand what the agents are doing.

[00:17:13]Uh, but like a thousandline markdown file, you know, I don't even edit them anymore. I just ask Claude to edit them instead.

[00:17:19]>> And so I think one of the things that I've been seeing emergently in the cloud code team is that like they that we're using HTML files instead.

[00:17:26]>> His fix is to stop using markdown for many of these things. It's to use HTML.

[00:17:33]And what's actually in his HTML plans?

[00:17:35]code excerpts, mockups, which I use personally, decision tables, failure modes, sample outputs, edge cases displayed on a screen, right? So, it's all rendered. There's no ASKI. There's no 1,000line walls or just three paragraphs of text, right? We're using something a bit more efficient to explain some piece of information that is relevant for us building, okay?

[00:17:59]Something you'll actually open and read at least in more of a visual way. And part of the reason to why this matters more now than ever is what Tariq explains as computer allocator framing.

[00:18:10]This is the sound bite worth a whole video >> because when I you say okay cloud can run for 8 hours what you're really saying is clock can spend like 500 bucks you know what I mean and and so if you're spending 500 bucks or like I think all of us are becoming these compute allocators now right >> so you see it 500 bucks per run you cannot afford to skim the output so make the output something you actually want to read and you'll actually digest yourself and this is the prompt I stole from him and I use this for anything bigger than a single skill, planning, a publishing workflow, a refactor, a new tool, you know, you can run it once and you never go back to markdown. And here is a pro move from TAK. For parts of the plan you want to edit, ask Claude to build a custom HTML interface just for that decision. You edit it in the UI or you edit it by talking back and forth, copy the result back, and then you can just throw the UI away. And this is actually something that I preach a lot when I develop software myself using cloud code. So I always bring this but I use this really amazing plug-in called superpowers. Okay, it's a it's a plug-in which is a collection of multiple skills and within those skills as a brainstorming skill and essentially throughout the development process you want to plan out how the UI and UX is going to feel or look like because if you do it like this then you end up avoiding a lot of the back and forth that comes with you know clock and having conversations later and refactoring which ideally you don't have to do that. So if you you know prepare the UIUX, you meticulously check it out and plan it out before then the whole experience afterwards becomes much more smoother. And so with this skill, I'm able to display things on the screen and I'm able to decide what to pick, what to not pick. I refine on that HTML file that I would then throw away, but I would refine it. And this does two things for me. The first one is that I end up not losing my train of thought because everything is just happening in the same clock code session. Clock code just displays an HTML for the UIUX. I screenshot it. I say, "Hey, I don't like this. Let's change it." And I can just tweak it with cloud code in the same code session. So all of the train of thought happens in the same conversation in the same spot rather than just me switching between apps, you know, perhaps generating a UI on Figma, bringing it back and so on. And the second thing is loss of context. If I were to design something in Figma, then import it, I create a screenshot somewhere else in another app and then I bring it. By doing all of that, I am definitely losing some context that cloud code might not catch when it comes to edge cases or certain things. But if I keep the conversation with a cloud code and I ask it to generate HTML in that same conversation, well, it retains all that context. So it exactly knows what to build. it can then grab that HTML that we generated in the same session and it exactly knows what to build. It has that HTML already in the session. Right? So those two things I think are really important. I've used superpowers and and the the ability to write HTML to make decisions and make designs. It's really really powerful and you guys should definitely leverage it.

[00:21:19]So yeah, these are the five principles and I believe if you apply these principles, you'll be able to use cloud code at a much more effective rate and I will also leave the guide that you seen in this video. Probably seen it briefly.

[00:21:32]I'll leave this in the description so you can go ahead and download it and use it alongside cloud code. And if you enjoyed this video, you want to see more videos like these, let me know. Give me a like, thumbs up, and subscribe. It helps the channel a lot. And leave a comment for any suggestion for future videos. And if you didn't like the video for some reason, also drop a comment because any feedback is good feedback, right? Thank you so much and I'll see you in the next video.