So, 3 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 quite nice hair was doing this

about a month ago as well. So, we both

had the same idea. A week or so later

Tarik 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 Claude.md should be

extremely minimal, basically only

environment info. 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's actually in the

Claude 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 Tarik and the team some

feedback. And so, this is me and my

honest kind of assessment of what init

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, Vitest 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 setup questions

that you might see in a normal init CLI.

It asks you which Claude.md files should

init 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 code base and

recommend whether skills and hooks make

sense for this project. Okay, it spent 1

minute 54 and it surveyed the code base

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 auto run

prettier after every edit and a verify

skill would give you a quick way to run

type check and tests on and 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 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 because I freaking hate

the UI. Look at this crap. Look. Does

this proposal look right for your

Claude.md 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?

Okay, and now I just escaped and I'm

gone out of it. Don't use the ask user

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 at least an output

describing what it wants to do. It wants

to create a Claude.md file, which I

don't currently have in the repo. It

wants to create a format on edit hook,

which automatically runs prettier after

every edit, so Claude code 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 npx tsc. Let's tackle

this one first. I already have a hook

that checks npx tsc. And if it

encounters it in a bash tool, then it

tells it to run npm run npm run type

check instead. What would adding this to

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

Claude.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 useEffect reducer, not React's

useReducer. Now, useEffect reducer is an

interesting one because it's a library

built by my friend David, who it

basically only has like 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 XState. I

know it's really, really, really, really

good and it just is not that popular.

So, having something in the Claude.md

that actually tells it to use useEffect

reducer, not React's useReducer, might

be useful. Except this stuff is

trivially discoverable from the code

itself. I never use useReducer in the

code base. I only use useEffect reducer.

So, I'm going to ask it, "What value

does having the useEffect reducer in the

Claude.md have that is not because it's

like trivially discoverable in the code

base 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.md." LLMs

are sort of naturally sycophantic 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 useReducer. 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

front end TDD skill. And also, I just

don't think that Claude is ever writing

new reducer code, right? Like, if it's

going to write React code, it's going to

use useState cuz that's what most of its

training data is going to be using. One

line in Claude.md 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 Claude init.

It's 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 npx tsc.

I would like you to stand up to me on

this one. That's another one in the

budget gone. But he's probably right, I

think. I'm willing to go with it on this

one that one line in Claude.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

Vitest light 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 Claude.md, it creates

a dependency from one to the other. In

other words, we need to update our

Claude.md when we update our tests. And

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 sticking a line about the useEffect

reducer. But next, let's say, "When we

do integration testing, there's always

going to be an explore phase where the

LLM actually goes in and explores the

repo before it goes and writes a test.

Do we really need something in the

Claude.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 code base before

writing tests anyway, it'll find effect

Vitest light create test blah blah blah

in the existing test files. Documenting

those patterns in Claude.md 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

we're not really installing effect

packages that often. And effect, if you

don't know, is a kind of back end

TypeScript framework that I use for

building 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 super 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 don't like this sycophancy, 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

Claude.md because they're trivially

discoverable in the package.json and

we've already got a built-in hook for

handling the type check. So, I'm just

slapping it down one more time. So,

Claude.md is just the useEffect 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

just a really minimal Claude.md file

with a questionable useful useEffect

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 Claude.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 code base. 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

Claude.md and see it in all its glory. I

really don't like this top line here.

This file provides guidance to Claude

code when working with code in the

repository. Why am I passing that to the

LLM? The LLM already knows that. Then it

says, "Use use effect reducer from the

use effect reducer package for reducer

based states, not React's 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.init. 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'm

running a cohort course on Claude 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 init

script as well, and tell me in the

comments how you got on. And hopefully,

hello Claude code team, this was useful

feedback to you if you want to improve

it further. Make it less sycophantic,

make it more proactive in suggesting

skills, and make it provide the steel

man argument against why it should

include things in claw.md. Thanks for

watching, and I'll see you in the next

one.