The 5-Tool Fix for Claude Code's Worst Habits

Añadido: 2026-05-30

[00:00:00]Tools like Claw Code have four big blind spots. It forgets everything, ignores your codebase, ships bugs, and codes blind. And that ain't good. So today, I'm going to go through five open source tools that help you solve all of those problems. We'll look at each one and talk about what it is, and I'll demo it inside of a real project. Starting with intent layers. So intent layers is an open source skill that I'll I'll link to all of these in the description below.

[00:00:23]But what this one does is it sets up hierarchical agent.mmarkdown files so that agents can navigate your code bases more effectively. And so the way that this works is it creates a root index file called agents.mmarkdown or inside of your clawed markdown file. Now inside of this file it links to child markdown file. So, anytime you have a complex directory, and they define that by something with more than 20,000 tokens, it is going to create one of these files that tells your agent exactly what lives inside of those directories and where to navigate in order to find important information. So this is really helpful when you want a language model to interact with what you already have and not make some of those stupid mistakes where it overwrites existing patterns or modifies things in the wrong spots. So if we were to open up claude and run this intent layer skill, it's going to move through and it's going to create that nested structure for us. So now what this thing is going to do is it's going to detect the current state of your project if you have this in place already yet because you can use this to update things over time. It's going to attempt to calculate how many tokens exist in each of your subdirectories.

[00:01:37]It's then going to generate those context files and add child nodes at any point where you have more than 20,000 tokens inside of a directory. So once this thing is done running, we can jump in and see exactly what it created. So in our case, inside of this project, we have this new intent layer section. And what it's doing is that it's creating pointers to deeper documentation inside of our codebase. So, for example, if we're working on something that deals with our app routes and our APIs, instead of Claude having to read all of the files in chunks and try to understand what lives where, it has a simple pointer to a nested markdown file that explains everything that lives inside of that and the conventions of those files. So, in this case, it's telling it all of our Next.js 16 route groups, our server actions, and the primary API surface all live inside of this directory. if we needed to modify something that had to do with our like Stripe integration, it has a pointer to our Stripe documentation and it knows that the web hook contract and all of the customer race condition handling all lives inside of there as well. One other thing that it adds in that is a super helpful convention to have inside of your projects are global invariance.

[00:02:48]What are the things about your project that are nonconventional or break potentially from the training data that the model actually has? So a really good example of this if you're using Nex.js 16 or higher tools like cloud code are trained on an outdated version of that.

[00:03:04]And so in the new version they have this proxy.typescript file and they've done away with this middleware.typescript file. Now, this can become a problem if you're working on something that touches the middleware and Claude Code's trying to read your project and it thinks this file is missing and so it tries to reconstruct it or potentially even deletes or modifies this proxy file and then your entire project breaks. And so this tool is really helpful at documenting these types of things and making sure we don't constantly bash our head against the wall with the same problem over and over again. So if we were to go look for example at our app directories agent markdown file, we can click in and see what the structure of one of these actually looks like. So for example, it's specifying all of the route groups like our app folder, our off folder, our public folder, our API, and it's talking about what exactly lives inside of that. What are the important conventions to be aware of like we just talked about how the middleware actually gets handled in this case? important project specifics like how these at handles inside of our app actually get rewritten into a different format. So all of these things that are very specific to this project, important patterns that need to be followed that are already in place and then important antiatterns. What are the things that you should not do specifically when you're working inside of this app directory. So an example of that might be if the model is tempted to put business logic inside of our route typescript file, we're going to instruct it that anything that you're thinking about building actually belongs inside of our library. So if you're working on established projects in particular, this type of convention is very helpful. It's going to dramatically improve the consistency of the models, which means it's going to reduce context waste and ultimately it's going to help models actually work inside of your codebase with more of like a tribal understanding of the conventions inside of your project. But the uncomfortable truth is that language models are still pattern followers. So what if in the course of all of this, we actually have a bad pattern in place? For example, what if our app's security actually has really poor conventions in place that claude code or codecs will just copy over and continue to use? Well, the next tool up helps us with exactly that. It's called DeepSseec and it is a security harness that was built by Verscell and it's meant to find vulnerabilities hidden inside of your codebase. And the thing that really impressed me about this tool is it doesn't just do a basic scan. It's really good at finding these hard to find issues inside of your project that unless you were really reading all of the code and knew specifically the types of things to look for, you would probably never find. So this thing is pretty easy to actually configure and run. So we're going to copy the command npx deepseecit and then we're going to hop into our project and run the command. And what this is going to do is it is going to clone that into our project. So the next thing that we want to do is first go into this deepseec folder and then install all of the packages. Now while that's running, we're going to copy this command that they actually want us to paste into the coding agent after this is set up. So what we're doing is basically telling cloud code in this case how to actually use this tool specifically and how to set it up so that we're ready to use it.

[00:06:23]And so after that is done, what we have is a high-level explanation of like the primary threat model of this app. So based on the context of like everything that lives inside of our app, what are the things that would be the areas that someone would attempt to attack? So once we have that in place, we can come down and we can run the first command. So this first command is called pmppm deepsect scan. And this is basically going to look for candidate files that would be the most likely files to have an issue in them. So the way that it determines this is it has these different matchers that will basically look for like the types of files that would contain the logic that could potentially have security holes. And then the next step is going to be doing a larger deep dive into the actual grouping of files. So what we can do now is we can come through and run pmppm deepseec process. And so what this is going to do is it's going to now break down the work into batches and it is going to process every single batch in order to find any of these like deeper issues that might be living inside of your project. So I've run this a lot inside of like a smallsized project.

[00:07:32]This will cost roughly 20 to $30 in token credits, but for finding the types of vulnerabilities that this thing can find, I think that price is is well worth it. All right, guys. So this thing just finished running and now the final step that we can run here is to generate a report. So it's going to take all of those findings and it's just going to compile it into a report for us that gets placed inside of this directory in a report.mmarkdown file. So if we were to move through now and read this, we can see all of the issues that it found.

[00:08:01]Again, grouped by critical, high, medium, high bug, and then general bug.

[00:08:06]And so here's an example of the type of thing that it might find in the context of our app that we're working on in this project. It's possible that someone could try to prompt inject the system.

[00:08:16]So when we have this function that we call called build system prompt, it basically takes the context of the recipe in this case that someone's trying to branch off of to create a variant and it directly injects it into the language model system prompt and it doesn't do any sort of like escaping or sandboxing of that. And so if we were to think about it, someone could create a recipe that says something like ignore prior instructions and then injects us with some sort of attacking prompt that could have any number of side effects.

[00:08:45]So obviously something like that would be very bad and I think that's something that might not be super obvious to you.

[00:08:51]Again, especially if you are vibe coding and not experienced in engineering, there's a lot of different situations like this that could potentially happen.

[00:08:59]And the thing that's really cool about this is it will give you a concrete recommendation on how to fix it. Now, if you want to see this tool in more depth, specifically about how we actually like can patch these things with the spectriven development tool, I will link you to a video at the end of this one where I've covered this tool specifically in a little bit more depth.

[00:09:16]But deepseec is really just handling the security layer of things. What about like general performance issues that we might run into with our app? So a big problem is that tools like cloud code and codecs don't necessarily build things with best practices. So they will 100% build things with conventions that are known to be bad. And so if you build things in React or Nex.js or even React Native, this skill can go through any project and really dial in the best practices in terms of what you are doing. And the way that it does that is it has this rule set of things that it will look for. And these things are based on like 10 plus years of actual React engineers and what they know to do in order to like really optimize what you are building specifically from a performance perspective. So we're going to come through and we are going to run this command skills ad versel labs agent skills and then we can come down like I said and depending on what it is that we're trying to do we have a lot of different skills to choose from. In this case, I just want to audit the React best practices for React and Nex.js. So, I'm going to just choose that skill.

[00:10:23]We're going to install it with cloud code in the project. Now, we can boot up cloud code and we can run this command for versel react best practices. And so, the type of output that you get from this is going to be grouped into critical severity issues, high severity, medium, low, and so on. And so, we can look through at the type of responses that we get from this tool. So the first case we have this like sequential waiting when we could run both of these processes in parallel and the thing that's really nice about this is it is giving us a very concrete recommendation. So for example in this case after establishing the active conversation ID all three of these things can be fired in parallel. There's no point in waiting for all of them. And so the thing that I really like about this is we get a really concrete recommendation for all of these. So for example, after establishing what the active conversation ID is inside of this project, we can fire the profile conversation and recent messages retrieving in parallel. We don't have to wait for each of these to go in order.

[00:11:22]And so now we can see as we continue to scroll through, we have some optimizations with how our imports are working. We have high severity issues with how our caching is working or lack thereof. and it continues on identifying again critical high, medium and low severity issues. So now the next step from a process like this would be to take some sort of spectriven development tool and pass all of these in to actually track the changes and really systematically implement them. So, I think part of the thing that makes this like a really powerful library is that it has both like the incorrect version of like what someone might be doing and then it has actual examples of what the correct implementation of that thing is.

[00:12:07]And so this is going to get you a lot closer to having an app that actually performs in the way that it should and not having something that is going to really break and strain under a little bit of load from real users. So again, this library bundles up a decade's experience from Burcell's actual engineering team. And if there's one thing that I think Vibe coders need to do a lot more of, it's borrowing and copying conventions from people that really know what they are doing in a specific field. So whether it's performance best practices, security, design, like whatever it is, we should be trying our best to mimic what really experienced people actually do in their real workflows. But across all of these tools we've been using, we're accumulating a lot of valuable context.

[00:12:53]How do we make sure it actually gets carried across future sessions? Well, the answer to that is having a persistent memory system for your coding agent. And so, one tool that I found really valuable for this is called agent memory. It has 18,000 stars on GitHub and it has a lot of really awesome functionality under the hood that we are going to look at. Installing it is really simple. You run this basic mpm install command. You start up the server and you connect it to cloud code. And from there, it's going to operate in the background and listen in on all of your sessions and start compiling learnings about things that are going on inside of those sessions. And so on a high level, the way that this thing works is it creates four different tiers of memory inside of your projects or across your projects. First is working memory. So what are just some raw observations from it using tools regularly? Episodic which are compressed session memories about like what happened inside of you know the conversations that you are having.

[00:13:52]Semantic memories which are extracted facts and patterns about your project or ways that you work. And then procedural memories which are workflows and decision patterns. Now the thing that's cool about this is that memories will decay over time. Meaning if you don't use a certain memory frequently, it'll have less of a priority in the system so that it's not getting recalled later in time when it's not as relevant. So an example of like a memory that might get used somewhat regularly is one that we looked at earlier in the intent layer section where we're documenting that this project uses proxy.typescript instead of middleware.typescript and we are explaining the details behind that decision. But eventually when we get newer models that are trained on the newer versions of these docs, this might not need to get called as much and so it will auto evict out of the memories. So we're keeping like a running log of memories that are actually valuable based on how we work on a day-to-day basis. Similarly, when we ran that Verscell best practices audit, that was saved as a pattern, right? Because at the end of the day, those were patterns of how we should be building things and they're getting tagged, which means when we go to build something in the future, it would be able to read the bundle barrel imports pattern of working and automatically apply that to new features that we build. So, a lot of people in the past have solved this problem by having like persistent files inside of our codebase. Like you have a claude markdown file and maybe you have a rules folder that you point it to and it goes through and it reads those things. I view this as like more of a living breathing version of those types of files. So there are some other reasons this is beneficial. Number one, it's going to enable a semantic search of your project. So there's a lot of tools that this thing surfaces to help us out in like managing all of this stuff over time. We can look at timelines of actions that we've taken in our projects. we can search through our project history to like find things that we're looking for in a smarter way based on the actual relationship of that information to other pieces of information. And we have a really nice dashboard where we can view all of these things and interact with them over time like our memories, the timelines of different sessions and conversations that we've had. For example, a log of our deepseec run that we just went through. We can surface lessons based on like conversations we've had and conclusions that we've come to. We can create actions or things that we know that we need to come back to later on in time and a bunch of other stuff that you can come in and check out if you find something like this valuable. So over time, 80% of the stuff that you do ends up really becoming lost to claude code if you're not documenting those things after each session. And a tool like this keeps those findings 100% searchable over time. But here's a question nobody really asks. With some of these tools, we're writing better code. Maybe we're making better designs, but how does Claude code actually verify that it did something the right way, especially when it comes to something visual? The next tool up helps us with that. And so the rationale behind this is that if you had to go actually ask a human to build a website, but told them that they couldn't actually use the browser, how good would the actual result look in the end? Probably not good. And it works the same way. So if we give our coding model access to the browser, it can write the code and then iterate until the thing actually looks good. And so the way that you do this is actually pretty simple.

[00:17:16]All you need to do when you kick off claude is type in d-chrome.

[00:17:20]And that's going to open up claw code with access to chrome. So let's say we're inside of an app. And I really don't like how when I click on the user's profile down here, it pops up in this modal. And I would rather have this be like a traditional preferences and setting page. So we can come through and we can tell it to use the Chrome extension to iterate and verify until the work is complete and then explain what it is that we want to do. In this case, extract that modal into its own individual page so that we can start adding in more like complexity into what users can actually manage in their settings. As now we can see Claude has actually spun up a Chrome browser and has taken over and is testing their changes. So we can see now it's not a modal. It is a actual settings page where we can go in and now we can have these tabs at the top for preferences and profiles and all of those types of things. So sometimes simple verification loops are the best thing you can do.

[00:18:14]I've actually extracted this type of workflow into a basic slash command that I can run to go verify any front-end changes that get made. So that's it for this video. If you found it helpful, make sure to subscribe so that you get more stuff like this in your feed.