Claude Code tried to improve /init... Is it any better?

So, three weeks ago, I made a video called Never Run Claude in It. My reasoning being that it creates these huge bloated Claude.md files, which don't end up actually serving you that well. Turns out this relatively unknown YouTuber with uh quite nice hair was doing this about a month ago as well. So, we both had the same idea. A week or so later, Tariq from the Claude Code team said, "I want to make init more useful. What do you think it should do to help set up Claude code in a repo?" It's worth noting that I then said use progressive disclosure much more aggressively and propose a set of skills for the agent to understand the repo's best practices. The stuff inside claw.md should be extremely minimal, basically only environment info. And of course, lots of people had good ideas in this channel like Dex did as well, you know, progressive disclosure, you get the idea. And so just a couple of days ago, they are now testing out a new version of init based on our feedback. And you can try it out with this environment variable. So it is actually in the clawed binary. So we can try it now. So, I feel like I have a duty to check out whether this thing is actually good to see if I need to like deprecate my old video or anything like that. I also kind of want to give Tariq and the team some feedback. And so, this is me and my honest kind of assessment of what in it looks like now. So, I'm going to take this command here and I'm going to run it inside my work repo. This repo is my course video manager repo, which you will have seen before if you watched my feature build video. It is a React router application with the usual TypeScript prettier vest kind of setup. So let's run this and let's see what this new init thing does. I'm going to kick this off then by simply running init and seeing what happens. Now full disclosure, I did try this out once and so I have seen this before. It appears that it immediately asks you a couple of questions kind of like uh setup questions that you might see in a normal init CLI. It asks you which claude.md files should in it set up. Either a project claude or personal or both project and personal. Since I'm a solo developer working on this, I don't really need a personal one. I'm happy with just a project one. Now, should you also set up skills and hooks? Like, this seems like a weird question to me because I don't know what skills and hooks I need. Claude, why don't you tell me? So, I'm just going to go down here and dictate. I have no idea. Why don't you tell me? Go on, Claude. Show me off your secret menu what you think I should go for. And let's see what it says next. Okay, it's going to do the classic thing where it's going to explore the codebase and recommend whether skills and hooks make sense for this project. Okay, it spent 1 minute 54 and it surveyed the codebase thoroughly. Cool. There we go. Skills plus hooks make sense for this project because you already have three skills. A format on edit hook would also run prettier after every edit and a verify skill would give you a quick way to run type check and tests on demand. Okay, so I don't think this thing should actually ask you these questions. It should just say, okay, let me explore what opportunities there are for skills and hooks now. Okay, a lot of people ask me about why I don't tend to use the ask user question tool. For instance, in the skills I write, I don't tend to write use the ask user question tool. A lot of people ask me about this, especially in this little grill me skill, which you may have seen me use before if you follow this channel. Now, the reason I don't like this one is cuz I freaking hate the UI. Look at this crap. Look, does this proposal look right for your claw. Skills and hook setup? I have no idea if it looks right cuz I can't bloody see it. What happens if I press N to add notes here? I can't add notes on the design. Can I? Oh, okay. And now I just escaped and I'm uh gone out of here. Don't use the ask us a question UI. That UI is pants. There we go. Let's insult it and see what it does next. Okay, so it's come back with a document which or at least an output describing what it wants to do. It wants to create a claw.md file which I don't currently have in the repo. It wants to create a format onedit hook which automatically runs prettier after every edit so claude codes uh stays formatted. I'll get to that in a minute. And then it wants to add some steering stuff. So it wants to say use npm run type check never npxtsc. Let's tackle this one first. I already have a hook that checks npxtsc and if it encounters it in a bash tool, then it tells it to run npf run npm run type check instead. What would adding this to the claw.md add that the hook doesn't already guarantee? So let's see what it responds to that. Nothing. You're right. The hook already enforces it deterministically. adding it to claw.md would be redundant. I'll drop it. Okay. So, let's go through the rest of the items and just check that it actually wants to do it. So, let's start with use effect reducer, not reacts use reducer. Now, use effect reducer is an interesting one because it's a library um built by my friend David, who it basically only has like uh just over 4,000 weekly downloads. Usually I wouldn't use a library like this, but because I've used it many, many times before and I used to work with David on XATE, I know it's really, really, really, really good and it just is not that popular. So having something in the claw.md that actually tells it to use use effect reducer, not react use reducer might be useful. Except this stuff is trivially discoverable from the code itself. I never use use reducer in the codebase. I only use use effect reducer. So I'm going to ask it what value does having the use effect reducer in the claw.md have that is not because it's like trivially discoverable in the codebase itself. I'd like you to stand up to me on this one. Give me the best possible justification that you have for including this in the claude.mmd. Llms are sort of naturally sycopantic and so telling it to stand up to me is a nice way that you can sort of prompt it to justify its decision a little bit more. Okay. The strongest case when claude writes new reducer code from scratch. Its default instinct is use reducer. It's the standard React pattern, but we've already got this in a skill. Actually, we've already got this in a do work frontend TDD skill. And also, I just don't think that Claude is ever writing new reducer code, right? Like, if it's going to re react code, it's going to use use state cuz that's what most of its training data is going to be using. One line in claude.d is cheap insurance against a mistake that's annoying to catch in review. I guess this is like probably true, right? And this is the nasty thing about this is that these things would be really annoying to have to catch in review and having it always in the LLM's context might actually be quite useful. The thing is though is I'm not thinking about this purely in terms of tokens. I'm thinking about this in terms of the budget that the LLM has for instructions. I talked about this before in my previous video on Claudinit is like the LLM can reasonably only handle like 500 instructions. And if you think about it, the conversation itself is full of instructions, right? I already have a hook that checks npxtsc. I would like you to stand up to me on this one. That's another one in the budget gone. But it's probably right. I think I'm willing to go with it on this one. That one line in claw.md is worth trying out at least. So let's zoom up and see what else it wanted to add. It wanted to add testing patterns effect vgite create test db truncate all tables. So we do a lot of integration testing in this repo and we do use each of these patterns. Create test DB and truncate all tables. But we might not use those forever, right? And I suppose if we put them in claw.md, it creates a dependency from one to the other. In other words, we need to update our claw.md when we update our tests. What I'm thinking is that every time you do an integration test, you'll probably do an explore phase in that repo and then it's going to pull out any integration tests that you do. So that's what I will tell it here. In fact, I'll just tell it that it looks fine. Stick in a line about the use effect reducer. The next let's say when we do integration testing there's always going to be an explore phase where the uh LLM actually goes in and explores the repo before it goes and writes a test. Do we really need something in the claw.md is going that's going to naturally be surfaced through exploration? I feel kind of sorry for the agent at this point because I really am just grilling and grilling and grilling it. No, you're right. If Claude is going to explore the codebase before writing tests anyway, it'll find effect vest pg light create test blah blah blah in the existing test files. Documenting those patterns in claude.d is redundant. They're right there in the code. Now, this one's interesting. npm install force for effect packages. This one is like super rare because um we're not really installing effect packages that often. And effect, if you don't know, is a kind of backend TypeScript framework that I use for building uh really robust stuff and lots of people use it and it's wicked. It would be very easy here to just say yes, but I just want to be super duper strict about our instruction budget. I don't want to burn it on something that doesn't happen very often. Let's put the effect package installation stuff inside a specific skill that's invoked whenever we run effect packages. Then we'll be able to progressively disclose the rationale behind the effect packages. And it won't burn the instruction budget of the LLM to include just a brief description. So let's see what it says to that. And it says smart. That's a better home for it. I I don't like this sicker fancy, you know. I just want it to really like um you know interrogate me and say no, I have an opinion about where it is best to be used. It feels to me like this init script is just kind of going with all of my suggestions here. I want it to stand up to me. Finally, we don't need the build and type check commands inside claw.md because they're trivially discoverable in the package.json and we've already got a built-in hook for handling the type check. Sorry, just slapping it down one more time. So, claw.md is just the use effect reducer line. That's refreshingly minimal. That's I mean that's refreshingly minimal is like this generation's version of you're absolutely right. So, okay, we are down to a just a really minimal claw.md file with a questionable useful uh use effect reducer inside here. Let's just see what it says if I just say yes. And let's see the final outputs. Okay, so it wrote two files. It wrote this claw.md and it wrote a skill. Let's take a look at the skill first. When installing any effect package, always use npm install force. That's nice. I like that it has a why not. That's really useful. I really don't like these currently installed effect packages because this may change in the future. So, kill that. I only want to make recommendations here that are durable, right? That actually are likely not to change in the codebase. And because this skill is really only for models to invoke, I'm going to say user invocable is false here. This means it's not going to appear in my list of skills that I can invoke. Let's take a look at claw.d and see it in all its glory. I really don't like this top line here. This file provides guidance to claw code when working with code in the repository. Why am I passing that to the LM? The LLM already knows that. Then it says, "Use use effect reducer from the use effect reducer package for reducer based state, not react built-in use reducer." I mean, this is really narrow, right? Like, how often are we creating new reducers? We're really not in this repo very much. I'm just going to kill it. Screw that. I'm not having it. So, we end up with this skill which is uh quite useful for extremely narrow situations, but I feel like it's quite possible that someone with uh less context paranoia than I would have would have ended up with a fairly decently sized claw.md. However, I do like this skill and I will keep this skill which is more than I could say from the previous uh claw. The previous one would have asked me no questions, created an enormous claw.md file and then just pieced out. So, this I suppose is an improvement. If you're digging this stuff I'm putting out, I am running a cohort course on clawed code for real engineers. We're going to be looking at the decades old actual engineering techniques that are translatable into AI coding and are key for producing great outputs. If you're into that, then you should definitely check it out. But if you're not, thanks for watching anyway. I really appreciate you. I would love it if you could test out this innit script as well and tell me in the comments how you got on. And hopefully, hello claw code team. this was useful feedback to you if you want to improve it further. Make it less sickopantic. Make it more proactive in suggesting skills and make it provide the steelman argument against why it should include things in claude.mmd. Thanks for watching and I'll see you in the next