The 15 HIDDEN Claude Code Rules That Will 10X Your Vibe Coding

If you're having Claude code problems, I feel bad for you, son. I've got 99 problems, but these 15 hidden Claude code rules certainly ain't one.

Most people rightfully claim that Claude code is the king of the hill when it comes to AI coding tools, which makes it all the more crazy that a lot of people out there don't know half the items on this list that help you squeeze every last drop of goodness out of Claude Code. I've been going pretty hard on AI coding for the last year and a half, and I didn't even know about some of these things. So, I've broken them down into three categories: prompt construction, prompt engineering, and communication. So, that being said, let's check them out.

So, the prompt construction tips are all about how you can get better quality outputs from the prompts that you're using with Claude code. Now, the first one on the list is using XML formatting. Now, if you tend to provide massive unstructured text walls to a language model, it can actually sometimes be difficult for it to properly interpret exactly what you're asking it to do, and some of the details of what you want done can be lost. So, this tip can massively help improve the quality of your outputs.

So, what we're looking at in this example is a prompt that I would pass to Claude Code in order to build functional UIs that actually look really good. So, what a lot of people would do is just go into Claude Code and say, "Hey, make it beautiful and make it look more like Airbnb or make the colors this way," but that doesn't really work too well. And so, what we're doing in this case is we're giving it a very specific goal. We're giving it inspiration images that would be attached to the prompt. We're giving it very specific guidelines about what we actually consider something to look nice, what does that actually look like? And then we're giving a ton of extra context about our ask. So, everything from the app overview, the philosophy of the application, who it's meant to help, what the specific task is that we're asking for in this specific step, we're giving it a ton of structured data, and the language models perform better when you have structured data.

So, inside of this prompt repository, which you'll all have access to below the video, I have a really basic starter kit for this. So, how can you take this and just start using it? Where we prompt for the goal, the format, we give warnings, we give examples of how to do it well, and then we have this section for giving a lot of extra context if it's needed. And so, I'm going to actually come out of Claude Code for a second to show you an example of what this looks like going wrong in practice. So, in this specific example, what I asked Gemini to do was to take this base prompt that I have here and make the prompt better based on what it knows of design principles. And since I wasn't very specific and I gave it a huge text wall, what it did was it actually just used nano banana to make me the image, instead of returning me the prompt that I wanted. And so, if I had simply told it the exact format that I wanted in the output, I would have actually gotten a prompt back like this one instead of an image being generated. And so, what happens inside of Claude Code is very much the same thing where it can sometimes get a little bit ambiguous when we have huge text walls. So, if you're trying to build really meaningful, more advanced stuff and you want to squeeze every last drop out of what the language model is capable of, you should really double down on providing structured prompts whenever you can. But in this XML prompt was actually something really important that Claude Code models just got a lot better at.

Which leads us to rule number two: providing better examples inside our prompts. So, the best thing you could possibly do, if you did nothing else on this list, is to provide very concrete examples whenever you ask Claude Code to do anything important. This is why I believe that following people that are experts in specific pieces of the tech stack is really valuable because they tend to have really battle-tested good prompts and examples that they provide when they're working with models like Claude Code. And so, if you can collect all of those things, you can start doing some really awesome stuff. So, if an amazing back-end engineer shows you how they build tests, you should probably consider taking those and using them to prompt into Claude Code yourself. And the same thing goes for DevOps, for front-end, for product design, for the UX and the UI, for everything.

So, what we're doing in this example is we are giving Claude Code an example of what a style guide would actually look like. So, if I'm going to ask Claude Code to go build me a beautiful app, well, I need to give it all of the constituent parts. And so, what we're doing in this example when we ask it to build us a style guide is giving an example of what one filled out well actually looks like. So, we go through all of the different colors from primary, secondary, accent, all the different functional colors, the background colors, the typography, the component styling, how should buttons look, how should images look, all of that type of stuff, the spacing system, the motion, and the animation. We're going to give it an example of all of this and then say, "Hey, based on me asking you to clone app X, Y, or Z and based on the philosophy of this app and what it's meant to do, you need to build me a design system that follows this example specifically." And so, especially when you're wrapping these examples in those XML tags, you're taking a big shortcut when it comes to building really high-quality stuff.

So, we've talked a little bit about how to optimize our instructions, but can we do it even better? Well, the obvious answer, since I asked the question, is yes, and we can do it through being more explicit with our instructions. So, we're actually taking this one straight from the horse's mouth: explicit instructions unlock the above and beyond behavior of Claude models. Which means the more specific you can be about what you really, really want, the better the model is going to be at performing that task. So, the example that they give of this in their documentation is that something like, "Hey, now create me an analytics dashboard," is not going to work nearly as well as saying, "Create an analytics dashboard, but include as many relevant features and interactions as possible. Go beyond the basics to create a fully featured implementation." And now we can actually take that concept to the next level. And I have a Claude custom command that you can use here to improve your prompts. And so, what we can do is we can use this custom command that's called "improve prompt." And we can give it something basic like, "I want to add a feature into our app that improves a user's prompt." And so, what it's going to do is it's going to go through and it's going to follow all of these instructions to actually ask me questions in a kind of Socratic dialogue to get more detailed in terms of what we actually want out of this feature. And so, what would happen is we can come through, we can answer all of these questions. And then from there, we're going to have a much more dialed-in understanding of what feature it is exactly that we're going to build and how it needs to function. And so, the reason I really... No, take that out.

And so, this extends just beyond basic feature requests. This idea of being more explicit with instructions persists through every single tip on this list because newer Claude models are being trained more and more to follow explicit instructions better. And so, it's important that we're optimizing every single opportunity to be as explicit and specific as possible. But the next rule up on the list is one that actually kind of surprised me in an interesting way. Claude actually works better when you provide motivating context. Now, what this means is that Claude actually excels when you tell it what the feature is going to actually be used for and how it should impact the user. So, in this example, telling it in a response, for example, let's say you're building like a text-to-speech type of feature or functionality. Instead of saying, "Hey, never use ellipses," what would actually be more effective is to tell the system, "Your response is going to be read aloud by a text-to-speech engine, so never use ellipses, since the text-to-speech engine will not know how to process it." So, small little tips like these actually compound into huge benefits when used properly over time alongside all of the other tips on this list. I've actually thought about building a public MCP server that helps integrate some of these tips when you're not following best practices for Claude Code. So, if you're interested in something like that, maybe we can double-dip a video where I show how to build an MCP server, but we actually codify some of these best practices into how that MCP server functions. Let me know if you're interested in that. Could be kind of cool.

Now, rounding off this list is our last rule in this prompting category: giving very clear direction. So, a lot of us have dealt with those situations where Claude Code kind of goes off the rails and starts changing things that we didn't specifically ask it to change. And sometimes that results in things that were working now becoming broken. Maybe it over-engineers the solution. Maybe it creates a bunch of unnecessary extra files. Maybe it makes some sort of janky workarounds just to make the thing work. Things like that. Well, the fix according to Anthropic is actually surprisingly simple: you just need to tell it not to do that. And so, down here, one of the things that's bothering me about this app is that it takes a little bit too long for this lenses page that I have to actually load. And so, what I'm going to do is tell it that I wanted to improve the page load speed on that page. And then I wanted to only make changes that are directly requested, keep the solutions simple and focused. So, if you're tired of banging your head against the wall as Claude Code goes off and breaks stuff or way over-engineers solutions, it can be as simple as this to fix that. Just like a child, all it really needed was a stern talking to and some clear direction.

Now, we just talked a lot about how to make prompting better, but the next list touches on something that I'm surprised more people don't talk about, given how much we hear that this is the thing that you're supposed to do: context engineering and planning. We hear a lot of people tell us how vibe coding is dead and it's all about context engineering, which sounds cool, but how do you actually do that as someone that is using a tool and not building the tool under the hood, like a Cursor, for example? Because it's not as simple as, "Hey, just give stuff in the prompts that's actually relevant to what you need." It actually goes a lot deeper than that. So, let's get into all of that context engineering and planning.

So, first up on the list, we have what I'm calling context window splintering or splitting, which isn't a technical term, but it sounds cool. And so, what this is is that when you kick off a new feature, Claude Code actually performs better when you do the brunt work of the setup of that task in a context window and then you move to an entirely separate window to actually do the step-by-step implementations. And this is something that is coming directly from Anthropic: use a different prompt for the very first context window of a major thing that you are doing. So, let's say we have this feature here, which is this agents feature. Now, this is something that the AI actually hallucinated into my app. So, I need to take it out. But the thing is, there's a lot of API endpoints for it. It's tied into other pieces of the UI, and so I need to make sure that it's surgically cut out. What I can do is I can hop back into my Claude Code instance and tell it, "I need to remove this agents feature from my app, and I need you to actually spend a lot of time fully mapping out this task and what's required. We will use a different context window to actually execute. So, make sure you are fully researching this topic through and being thorough." That this has actually gone through and built a pretty comprehensive plan for what needs to be done and used a lot of its tokens to actually plan this thing out fully. We can just open up a new context window, paste in the path, and tell it to start implementing this plan. And all we need to do is simply paste that in. And now this is going to be a lot more efficient [snorts] and effective way of doing things moving forward. First context window for a new chat. Make it fresh and use that for a lot of the planning of the orchestration, and then move to separate context windows to actually implement. Now, this is something that a lot of us kind of did implicitly by compacting windows, summarizing the steps, and then just working within the same compacted window. But according to Anthropic, this is actually a lot more effective.

But this actually feeds nicely into the next tip or rule, which is the explore and then implement framework. The thing that always shocked me with Claude Code was how well it handled very large, complex, multi-file changes, and it was significantly better than any other tool out there for that. So, I was surprised to learn that by default, Claude Opus is actually very conservative at exploring your codebase before it decides to do something. Now, like a few of the tips on this list, the solution is very simple: you just need to tell it not to do that. Now, again, I built a Claude command here for you guys that you can use, and it'll be in the description below, where when we have an ask for something, we can just invoke this slash command and tell it that you need to explore this thoroughly first, and then you can proceed to implementation. Here's an example of us kicking this off. So, we can say, "Explore first," which is going to load this custom command in. Again, the page load speeds are super low for the first rendering, and then they're faster every time you visit it. And so, I'm sure there's something about my database queries that need to be optimized. And so, I'm letting it explore first and then move through to the implementation. And so, it goes through a four-step process for this: it lists out the entire directory structure, it looks at all of the different related files, it goes deep into reading those related files, and then it summarizes the patterns. And from there, it will determine what it needs to do to actually move forward with an implementation. So, if you deal with a lot of solutions that seem thorough at first but then fall apart when it actually implements it, this is the type of command or way of working that is going to really help avoid that type of thing happening.

Now, the next thing up on the list is one that I was kind of wrong about, I guess, but I've learned from it now, and so I'm happy for that. It's almost always better to clear out the context window and then reference a file that's tracking the progress of the task or list of tasks than it is to compact the window and then continue working in that window. Old approach to managing context was that I would run a slash command to compact the window, and I would provide a series of instructions to keep track of all of the files that got changed and what the next steps in the process should be. It's actually better, majority of the time, to just have a reference file that's tracking the progress and then clear the context window out entirely and pass in that reference file, allowing Claude to just pick up where it was. So, an example of this in practice, if we were looking back to that feature where we were removing the agents piece, it would be a lot more effective for us to come in here, have this progress dumped into a to-do list, and then just kick off a new window to complete that list than it would be to come in here and go, "Compact," and then tell it to keep track of the task list state and major changes that were made. So, this approach here was my old approach. It's still effective and gets the job done, but again, this is all about the small changes that when you add all of them up together and start using them, they result in really big efficiency and quality gains. And so, this is one of them. This method of compacting seems to be a lot less effective than just clearing and then keeping a running tab somewhere in a file of where you actually are in your progress against that plan. So, when in doubt, clear it out. I'm going to put that on a t-shirt.

Now, let's continue down the list with another doozy that I didn't really know about and is really, really amazing. You can actually encourage Claude Code to understand the task size and plan its context window accordingly. So, the way that Claude Code works is that once it approaches its context window limit, it starts cutting corners. So, it's thinking, "I need to complete this before my token allocation runs out." So, basically, it's optimizing for finishing the task before the window auto-compacts itself. And what that means is you're going to lose the quality of the output as you approach the upper limit of your context window. So, if you're working on a huge task that really required maybe 50% more tokens to complete successfully, it's going to start giving you worse and worse code being generated the more you move toward the upper limit of that context window limit. So, I have here a prompt that you guys can use for this. So, we're basically telling Claude that its context window will be automatically compacted as it approaches its limit, which allows it to continue working infinitely from where it left off. Therefore, we do not want it to stop tasks early due to token budget concerns. As you approach your token budget limit, just save your progress to state memory, and then you'll be good to go, basically, as we proceed forward. And so, we can copy this. So, what we do is we hop back into our Claude Code and we're saying, we're pasting in that prompt, telling it that you need to be consciously, like, meta-aware of the fact that you're going to do this thing, and then we're just going to give it the context for the plan. So, what I did was I went back to this "explore first" approach and I told it to, "Hey, dump this all into a file," and now we're saying, "Here's the plan, start implementing it, but know that you cannot truncate the quality of your output as you start approaching your context window limit." So, this encourages the model to get right up to its limit, knowing that the work will carry over to a fresh window. So, it's really an amazing hack, and I highly recommend it for anyone that's trying to improve, again, the overall quality of their outputs, and it goes hand-in-hand with the next tip, which is emphasizing incremental progress and tracking.

So, if you look at successful real-life developers, one of the things that makes them really great at what they do is breaking problems down into really small chunks and completing them incrementally. And Claude actually works best when it's used the same way. And what that means is we can use those tokens very effectively to demolish smaller, very specific tasks with very high quality. And that's what this prompt is meant to help us do. Now, it's important to note that this is not necessarily done automatically by a tool like Claude Code. So, here's how you can prompt it in. We can simply tell it, "This is a very long task. So, it may be beneficial to plan out your work clearly. It's encouraged to spend your entire output context working on just the task. Make sure that you don't run out of context with significant uncommitted work. Continue working systematically until you have completed the task." And a simple addition that is going to help us yield much higher outputs.

So, last but not least, we're going to move to the final group, which helps us communicate better with the model and be really sure that the outputs we're getting are the best that they can be. So, we're going to move on to verification systems and communication with the model. So, the first rule in this set is source verification and success criteria. So, what we're talking about here is researching. When you are trying to research something that you intend to add in with Claude Code, how do you actually do that in the best way possible? So, we have to remember that Claude Code and language models in general love themselves a good old-fashioned shortcut. Kind of like when they convert all your TypeScript to "any" so that everything just passes without any problems. So, when you're researching, you want to make sure that you ask to double-verify its sources and that you tell it what success from that research actually looks like. So, in this example, and again, I have the prompt here that you can get in the description below, I need to understand the best practices for building an MCP server that allows a user to authenticate into the user account of my application and then allows them to retrieve prompts and lenses from our app. These are two features inside of this app that I've been looking at in this video. This research is considered successful when you have multiple confirming sources for your approach and that it clearly outlines all the necessary technology and design patterns for making this thing happen. And so, what it's doing is it's going down and it is really breaking down how it's going to actually orchestrate this research in order to meet those success criteria. So, if you're tired of having a model look into API docs or the best way to handle a problem and it gives you incorrect or incomplete solutions, simply changing how you ask those questions and again, being more explicit with the instructions that you give, can make a world of a difference in the terms of output that you're going to get because you can make it double down on its approach and verify all of the sources against one another and then make sure it's actually answering the core research question that you really had.

Now, we can see as this thing is moving through, it is getting very specific and going into a lot of depth on the types of questions that it's getting answers to. It's performing a self-critique of how well it did the research, and now it's building me a really robust, comprehensive research summary about what exactly I would need to do if I wanted to do this for this app.

The next rule helps you find problems better in real time. So, one of the big changes with recent Claude models is that they tend themselves toward being less verbose with their outputs. So, what that means is they're going to try to be efficient with the tokens they use to explain to you what they just did. And so, they might skip summaries after tool calls and just move from action to action to task to task to task without telling you what it did and why. Now, this obviously helps the workflow be a lot more streamlined and move more quickly and saves on tokens. But as a beginner or an intermediate in AI coding or vibe coding, using these tools to learn is a serious competitive advantage. We don't just want the tools to go out there and code on our behalf and we have no idea what's going on. I love to use tools like Claude Code to actually teach me why it decided to make certain decisions, what the trade-offs were, and then I can store that into memory and get better and better over time. So, the way that you can control this is simply by telling it. Now, with a lot of these prompts that you're going to have, by the way, you can either put them in as a system prompt in your Claude.markdown file, or you can create a custom command if you feel like you just need it for this specific instance. But in this case, with the idea of making it more or less descriptive to you of what it just did, we can tell it, "After completing a task that involves tool use, I need you to provide a quick summary of the work you've just done." And of course, you can change this to make it more educational, explain it like a fifth grader, whatever you want it to be. You can add those in as custom instructions. And again, you can place them in a system prompt. Now, a bonus tip: the new Claude models take system prompts a lot more seriously. And so, if you put this in there, it is going to really start doing this every single time. So, again, if you view the model as a teacher, then controlling the verbosity of the outputs is kind of important so we can learn about what the trade-offs are in the decisions that were made and why.

Now, next up on the list is how we direct tool usage. So, depending on which way you like to go, you can make Claude Code either more proactive or more conservative in whether or not it chooses to take actions before it asks you about it. So, the newer version of Claude models are engineered for very precise instruction following, which means if you want to be more proactive or conservative in how it takes action, you need to actually tell it. So, shout out to rule number three for being explicit with instructions. So, here we have a prompt that you can use if you want it to take action a lot more often without necessarily asking you. And so, we have two prompts here that we can use. The first one will instruct it to be more proactive. And what that means is it's going to do more stuff itself. And so, if your intent is unclear, it's going to infer what you most likely meant, fill in the details itself, and then execute. Now, depending on the type of task, that may be fine. But if you want it to be more conservative and check in with you more, we have a separate prompt: "Do not jump into implementation or changes unless the user explicitly tells you to." So, we're basically saying you need to check in with me basically at every single point because I want to be in control of the process. Now, this is the approach that I prefer with Claude [snorts] Code most of the time. Again, depending on what I'm doing. So, if you're tired of it taking action when you would have preferred it challenge you or provide feedback, again, you just need to tell it explicitly not to do that. So, that being said, let's move on to the next one.

Minimizing hallucinations. So again, this is one that you can place in a system prompt, but what's nice is that the Claude 4.x models are designed to hallucinate less. But what's better is that you can actually double down on it with this type of system prompt. And so, what we're telling it to do is to never assume or speculate what is inside of a file. You have to actually read what is inside of a file, investigate it fully before you move forward with implementing something based on what you think is inside of it. Now, this is really pretty great because a surprising flaw of Claude Code, if you consider it a flaw, is that it would speculate about what's inside of a file. So, imagine you have an app like this where we have inside of our app directory, we have an API, and then inside of this lenses folder, we have a root file. Now, imagine if Claude Code didn't actually decide to read what was in here and just inferred what would probably be in here based on other conventions or based on other things that's read inside of the project. Well, sometimes that might work, but a lot of times what might happen is it builds something that is actually entirely disconnected from what the reality of this file is. But again, that can cause a really big problem if it just assumes the structure, assumes the parameters, assumes the different functions that are inside. But we can overcome that by simply telling it not to do that.

Now, we're going to end all of this with just one last rule that we've been doing on this channel since day one, but it's worth repeating because it is actually in Claude's guidelines and best practices now, which is providing specific design guidance for front-end tasks. So, if you're going to build a front-end component, send your UI and your UX guidelines inside of your prompt to the system inside of this doc that we're looking at. This is the final tab for us doing exactly that for a video that we did recently where we used Gemini to actually build us some really nice-looking screens. But the way that we did that is we gave it a ton of context about all of our UX guidelines, our stylesheets that we have, how they're meant to be used, what does good user experience actually look like. We're giving all of this to the model and then telling it to go build the features. So, if you want to see a full video that uses this exact system, which again, is in line with Claude's own guidance on how to use their tool, that video is live Monday, December 8th, and I will link it at the end of this video so that you can see the type of impact it has. So, if you're tired of thinking you did a great job extracting another app's design system and putting it into your CSS, but then it doesn't follow it properly and makes some dud of your UI and you're like, "What the hell just happened?" This is your golden ticket to avoiding that type of stuff.

15 underappreciated rules that will 10x your Claude Code coding. Just remember, no matter what all of the talking heads say, these tools are enabling a new class of builders. And we just need to get better and better and better each and every day with how we use the tools and squeeze every last drop of goodness out of them that we can. So, like always, all of these prompts that I've been showing off in this video are for free in the group description below, alongside my free vibe coding intro course if you want to check that out. If you found any of these tips helpful, again, I will link you to a video where you can check out applying a lot of this stuff in real time to build an actual UI. But that is it for today. I will see you in the next.