WEBVTT

00:00:00.000 --> 00:00:13.360
What's up, friends? We're gonna 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

00:00:13.635 --> 00:01:02.020
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

00:01:02.340 --> 00:01:26.655
it's sort of forcing Claude code to explore the code base first. We can see it's kicked off an explore sub agent task to explore the current CLI structure in the code base. 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.

00:01:26.895 --> 00:01:55.565
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 gonna make it a CLI option. I just press return to choose that one. It's asking whether I wanted to use a positional argument or required option. I'm gonna 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 o one represent?

00:01:55.725 --> 00:02:11.020
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. Alright. 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

00:02:11.020 --> 00:02:22.975
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 dot t s, and an updated

00:02:22.975 --> 00:02:25.775
file that seems fine. And it's created some implementation

00:02:26.130 --> 00:03:13.055
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, manually approve the edits, keep planning. I'm gonna 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 top line rule. And it's a 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,

00:03:13.135 --> 00:03:16.095
like change sets as well which I use in quite a few repos.

00:03:16.255 --> 00:04:44.840
I've already said that your primary method for interacting with GitHub should be the GitHub CLI. When creating branches, prefix them with mat to indicate they came from me. 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 to 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 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 codes yet. This is all just planning before we dive into code. Okay. It's now given me a plan without any unresolved questions. 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 gonna say no, keep planning, and then make the plan multi phase. Make the plan multi phase 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 gonna 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

00:04:44.840 --> 00:04:54.440
free space. That's feeling pretty good. We've only used about 33 k tokens. Lovely. So I think having had all the exploration and now having this plan in memory,

00:04:54.760 --> 00:04:59.000
we can then start executing the plan. So I'm gonna swap to auto accept edits

00:04:59.275 --> 00:05:01.355
and I'm gonna say execute

00:05:01.355 --> 00:05:02.235
phase

00:05:02.235 --> 00:05:07.595
one. Let's go. Okay. We've had our first little paper cut which is it still thinks it's in plan mode.

00:05:07.755 --> 00:05:11.195
I just say crack on please with phase

00:05:11.195 --> 00:05:51.590
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 gonna say yes and don't ask again for p n p m build commands. I'm not gonna review it as it's going. I'm just gonna review it when it gets to the end. So what I wanna do now is open it up in Versus 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 gonna run code dot. And now I do wanna get Claude back into this terminal. So I'm just gonna say Claude continue.

00:05:51.590 --> 00:06:06.495
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 gitdiffs.js.

00:06:06.495 --> 00:06:33.095
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 arsed. You can also see it's left in here a to do for phase two which is really nice. It means that when we go to phase two, 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.

00:06:33.175 --> 00:06:36.855
Yeah. Phase one only used like three k tokens, so we can absolutely

00:06:36.855 --> 00:06:39.335
crack on with phase two.

00:06:39.655 --> 00:06:55.885
And I'm gonna leave it accept edit on. Now that we've done the planning, we can be pretty aggressive with accept edit on because we understand the implementation a bit and we kinda 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,

00:06:56.125 --> 00:07:35.305
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 then what I accidentally did was went into the file and press 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. I'm being very direct with it as well. Pull the files into your context. Context. And note how it 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 gonna be able to get to the end of this feature

00:07:35.545 --> 00:08:06.320
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 g h issue create

00:08:06.320 --> 00:08:32.240
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 out 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 16 k tokens just from our memory files, the system tools, and the system prompt. So I'm now going to ask it,

00:08:32.640 --> 00:08:46.715
get the GitHub issue 24 and enact phase four 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,

00:08:46.715 --> 00:09:00.670
and the exploration might be necessary because we've completely cleared out the context. I think though I'm gonna 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.

00:09:01.070 --> 00:09:12.865
Issues are fine to view. Okay. It hasn't done so much planning or like code base 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.

00:09:12.945 --> 00:09:45.505
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, check-in 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,

00:09:45.505 --> 00:10:10.585
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 Everlight. And I think my top tips are make sure that in your memory file, 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.