What's up, friends? Uh, we're going to

do a little bit of a different kind of

video. I've been working a lot with

Claude Code recently. I've been getting

a lot of questions on how I use it. And

so, I just sat down to do a little bit

of work and I realized this is actually

a really good opportunity to show a

complicated multi-phase plan with Claude

Code. The only thing I've done so far is

I've written this prompt here. I'm doing

a bit of work to add a CLI command to an

internal CLI that I have to do with my

AI hero courses. But what I'm doing is

less important than how I'm doing it.

All you really need to know is this is a

pretty large feature that will go

probably beyond a single context window.

I have here an initial prompt that I've

put in. I haven't really put too much

thought into this. The way I produced

this was I just talked into my

microphone and used a dictation tool to

dictate it in. And I've also activated

plan mode here by tabbing or shift

tabbing through until I hit plan mode in

the bottom left. Whenever I embark out

on a big piece of work, I'm always

thinking about creating a plan first.

Let's get this running. and I can

actually talk through while it's going.

So this plan is basically is sort of

forcing Claude code to explore the

codebase first. We can see it's kicked

off an explore sub agent task to explore

the current CLI structure in the

codebase. It's also doing some searching

here, just searching different files,

searching different patterns. And what

I'm waiting for it to do is to figure

out anything that's unclear from my

specification and give me back some sort

of plan. Again, we can see it's doing a

lot of stuff here. It's reading

different files. It's doing some other

stuff. Let me check the structure for

explainer solution folders. And now this

is really cool. It's come back with some

clarifying questions. What is the part

of the project repo where you want to

get commit diffs from? I'm going to make

it a CLI option. I just pressed return

to choose that one. It's asking whether

I wanted to use a positional argument or

a required option. I'm going to choose a

required option. And it's now asking me

a really specific question about my

implementation like should it match

exercise numbers strictly or flexibly?

I'll choose flexible. And again, it's

asking a clarifying question here. What

does the 01 represent? It represents the

sequence of the diff. This is basically

a multi-step form and then I end up with

the submit. I'm ready to submit my

answers. Let's go. All right. It has now

come back with a plan. Now, this plan

might look a little bit different from

the plans that you tend to get from

Claude code. The first thing is it's

extremely concise. Here we have a fair

few sections, but the stuff inside those

sections is pretty easy to read. This is

because I have this configured like that

in my rules, which we'll look at in a

moment. We have a new file, get

diffs.ts, ts and in updated file that

seems fine and it's created some

implementation steps here too. The

crucial thing though and I have this set

up in my rules too is it's given me some

unresolved questions and I get to choose

whether I want to auto accept the edits

uh manually approve the edits or keep

planning. I'm going to escape out of

this for now just so I can show you

what's in my rules file. You can call

this command memory and you can

basically be taken to your user memory

or project memory. This is what my user

memory looks like. It's really not very

long, only about 43 lines. I've given it

just some very light hints about what I

want. The crucial thing though is to say

in all interactions and commit messages,

be extremely concise and sacrifice

grammar for the sake of concision.

That's why that plan is so concise and

easy to read is because of this topline

rule. And it's 100% my favorite thing

I've added to rules and I'm never taking

it out. There's some stuff in here

that's specific to my workflow like PR

comments, like change sets as well,

which I use in quite a few repos. I've

already said that your primary method

for interacting with GitHub should be

the GitHub CLI. When creating branches,

prefix them with Matt to indicate they

came from me. Very, very light stuff,

but here's the one we're seeing here,

which is at the end of each plan, give

me a list of unresolved questions to

answer, if any, and again, make the

questions extremely concise. Sacrifice

grammar for the sake of concision. This

is why then we're getting this list of

unresolved questions right at the point

where we can see them. So, I'm now going

to dictate my answers to these questions

into this box. I'll just do the first

question just so you get the idea. Yep,

you can overwrite existing diff files.

That's absolutely fine. And thanks to my

dictation tool, this ends up there.

Okay, I've now got my full answers to

those questions. Let's submit it. And

it's going to continue creating another

plan. Notice how we haven't written any

code yet. This is all just planning

before we dive into code. Okay, it's now

given me a plan without any unresolved

questions. But my Spidey senses are

tingling here. And I've got a feeling

this is a pretty large piece of work.

And if this piece of work is too large,

it's going to overrun the context window

of the LLM. It's going to be much better

going forward if I break this into a

multi-phase plan that I can split over

multiple context windows. So, I'm

actually going to say no, keep planning,

and then make the plan multi-phase. Make

the plan multihase is really, really

nice because it's going to tell Claude

to break this down into a set of

implementation steps. And now we have

our multi-phase plan. Beautiful. Now, at

this point, I'm starting to get a little

bit nervous about my context window.

Like, that's a paranoia that I have. And

I'm just going to go and exit out of

there and just check my context and see

how it's doing. We can see that so far

we have 83.7 free space. That's feeling

pretty good. We've only used about 33k

tokens. Lovely. So I think having had

all the exploration and now having this

plan in memory, we can then start

executing the plan. So I'm going to swap

to autoaccedit and I'm going to say uh

execute phase one. Let's go. Okay, we've

had our first little paper cut which is

it still thinks it's in plan mode. I

just say crack on please with phase one.

Lovely stuff. While it's doing its

thing, we should talk about this little

status line down the bottom. I have this

customized so it shows which repo I'm in

relative to my repos folder. It also

shows which branch I'm on and how many

staged, unstaged, and new files I have

inside the current repo. It's already

asking me to build the project. That's a

good sign. And I'm going to say yes and

don't ask again for PNPM build commands.

I'm not going to review it as it's

going. I'm just going to review it ah

when it gets to the end. So, what I want

to do now is open it up in VS Code to

have a look at the files and just see if

there's anything I need to tweak. I'm

actually going to exit out of Claude

here by pressing control C twice. I'm

just going to run code dot. And now I do

want to get Claude back into this

terminal. So, I'm just going to say

Claude continue. And Claude will now

pick up our conversation where we left

off. It's a really nice little flow if

you just want to X out of Claude, run a

CLI command, and then go back. So, now I

can just use the, you know, standard git

diff viewer that we're all used to just

to see what's going on here. I can see

that it's added get diffs.js. That's

nice. And it's added this to internal.

There is a TypeScript error there, but

shocker, it was actually there before.

And I'm not entirely sure how to fix it,

and I can't be asked. You can also see

it's left in here a to-do for phase 2,

which is really nice. It means that when

we go to phase 2, we actually have a

hint in the code where it's going to

execute it. So, this all looks good.

What I like to do is either commit these

changes or just stage them so it's

really clear between phases what's been

added. If we go back to Claude, let's

have a quick check on context. Yeah,

phase one only used like 3k tokens. So,

we can absolutely crack on with phase

two and I'm going to leave it accept

edit on. Now that we've done the

planning, we can be pretty aggressive

with accept edits on because we

understand the implementation a bit and

we kind of get what's going on. Phase

two is complete and I'm reviewing it and

it looks pretty nice. A quick check on

context. We are in a very healthy place.

Let's do phase three, please. Something

I really wish that Claude code would add

is to just add the amount of tokens that

I've used so that I can put it in my

status line. That would mean I wouldn't

need to keep running context. I would

just have it right there, which is

something that cursor does really really

well actually. So phase three is

complete and what I accidentally did was

went into the file and pressed save and

an auto formatter ran and it did a

little couple of changes. When that

accidentally happens, the claw code

doesn't know anything about it. So I do

like to tell it and being very direct

with it as well. pull the files into

your context. And note how it in

followed my instructions really well. It

didn't do anything. It just literally

read a file again. So, our context is in

a pretty healthy place. And I'm pretty

sure we're going to be able to get to

the end of this feature without actually

needing to reset the context window. But

I want to show you what it's like when

you do reset the context window. The

cool thing about having a multi-phase

plan is that we can preserve it between

different context windows and the LLM

should have all the information it needs

to carry it on. But the question is

where do we actually store it? Do we put

it in a local file or do we do something

else with it? What I like to do is

actually keep these as GitHub issues and

I've said to it make a GitHub issue

containing the current plan including

all of the items that you've checked off

the plan list. This is calling GH issue

create with this plan in the description

of the issue. Everything's been checked

off for all of these phases except for

phase four and five. I'm happy with this

so I'll accept this. And now that I have

this asset outside of my context window,

I can feel happy clearing it. And this

means if I run context now, we now have

virtually nothing in the context window.

No messages whatsoever. We're down to

16K tokens just from our memory files,

the system tools, and the system prompt.

So I'm now going to ask it get the

GitHub issue 24 and enact phase 4 of

that plan. Now I'm deciding in my head,

do I want to go for accept edits on or

do I want to go for plan mode? because

plan mode basically forces it to do a

little bit of exploration and the

exploration might be necessary because

we've completely cleared out the

context. I think though I'm going to go

for accept edits on and basically just

get it to take the information from the

plan and get going. You can see it's

asking to view an issue and I'm happy to

say don't ask again. Issues are fine to

view. Okay, it hasn't done so much

planning or like codebase exploration

here, but it has read the correct file

and it's now implementing the correct

stuff, I think. Yep, that's actually

looking really nice. Let's now do phase

five. And of course, because it's

already fetched the GitHub issue, it

doesn't need to fetch it again. It's

still just in the context window. So

this process then of splitting work into

phases is really, really important. You

don't have to put each phase into a

separate context window. You can do as

many phases as you like, checking the

context window as you go. And I really

like keeping these assets in the cloud

because then actually people can comment

on them, add stuff overnight, add stuff

async. And I find this flow is a really

nice combination of letting the AI go

and do its work on accept mode and

having a lot of upfront thinking, doing

lots of thought via planning. And this

is currently how I'm doing all of my

coding, not only for AI hero stuff, but

also for Everite. And I think my top

tips are make sure that in your memory

file you have a tip to be extremely

concise. Get it to produce unresolved

questions at the end of each plan. And

get it to use the GitHub CLI to create

issues so you can share context across

multiple context windows. Thanks for

watching. This ended up being a pretty

chunky video and I will see you in the

next one.