The lessons so far have mostly ended with a single instruction: write this file, check that, fix this paragraph. This one goes further – instead of one request, you walk a whole task through the cycle that comes back every time you work with Claude Code: the plan first, then the work, then checking the result.

Compared with simply typing “do X” and waiting, that sounds like extra work. It isn’t – the plan shows you what Claude Code intends to do before anything moves in your files, and that is exactly the moment when it is easiest to check whether Claude Code understood what you meant.

All you need is a folder where you already have Claude Code installed and a basic CLAUDE.md.

Pick a task you can judge

The cycle only makes sense on a task where you can say whether it came out right. It doesn’t have to be big – for a first run, something small that fits into one sitting works better.

A few examples that suit this exercise: adding a section to a document that already exists, tidying up a to-do list scattered across several files, adding one function to a script you know by heart.

The test is simple: if, after seeing the result, you can say straight away “that’s what I meant” or “no, not that” – the task will do. If you would have to think about it for a while, pick something smaller.

Ask for a plan before anything changes

By default Claude Code reads files and asks for permission before every change – that is Manual mode, the one you have been working in so far. This exercise needs a different one: plan, where Claude Code can read the project and run commands to inspect it, but touches no file until you approve what it came up with.

The quickest way in is for a single instruction – put /plan in front of the task, like this:

/plan Add an FAQ section at the end of the README, with the three questions that come up most often in conversations about this project.

You can also switch for good with Shift+Tab – that shortcut comes in handy later, because it is how you move between Claude Code’s other working modes too.

Permission modes documentation

The status line at the bottom of the terminal confirms you are in planning mode – you will see ⏸ plan mode on there. Claude Code reads files, may run commands that inspect the project, and after a moment presents a plan instead of getting straight to work.

Fix the plan before you approve it

A plan is plain text – the steps Claude Code intends to take, sometimes with a short reason for each one. Read it the way you would read someone’s idea for solving your problem, rather than a finished solution: it is still a proposal.

If something is missing, or one of the steps goes the wrong way, you don’t have to accept the plan in order to fix it. Choose “No, keep planning” and write in an ordinary sentence what should change – Claude Code reworks the plan and shows it to you again.

There is also a shortcut for more detailed edits: Ctrl+G opens the plan in your text editor and lets you change it directly, instead of describing the edits in words.

Approve the plan and let it work

When the plan looks right, choose “Yes, manually approve edits”. That option puts the session back into the mode where every file change waits for your permission – so even with the whole plan approved, you still see and accept the individual steps instead of letting everything run at once.

There is also “Yes, and use auto mode”, which cuts the permission questions down to a minimum. For a first full session, stay with approving by hand – you get more chances to see exactly what is happening before you trust the cycle on longer tasks.

Claude Code starts working through the plan, one step at a time, asking for permission at every file change – just like Manual mode, except that now each step already has its reason from the plan.

Check the result yourself, not from the summary

Once the task is finished, Claude Code writes a summary of what it did. Read it – but don’t end the exercise there. The summary says what Claude Code thinks it did, not what actually changed in the files.

Open the changed file and read the part the task was about. If you work with Git, git diff shows you the changed lines alone, without reading the file over again.

Check the specific thing you asked for, not a general “does this look fine”. If the task was adding three questions to an FAQ section, count them – literally count whether there are three.

The same habit pays off later on longer tasks, where checking “by eye” is even easier to skip. The sooner it turns into a reflex, the fewer times you end up with a summary that doesn’t match what is in the files.

Save what worked, for next time

The last step is easy to skip, because nothing prompts you to do it any more: writing down what from this session is worth carrying into the next one. Not a diary of every task – just the things that genuinely make the next session easier.

If Claude Code didn’t know something while planning and you had to tell it – that a certain folder is not to be touched without asking, say, or what you call a thing in the project – that is exactly the kind of information worth adding to CLAUDE.md. Say so to Claude Code directly, the same way you dictate any other correction:

Add a note to CLAUDE.md: files in the data/ folder are not to be changed without asking.

At the end of a session, ask what Claude Code has just learned and whether it is worth saving. The next session then starts not from nothing, but where this one left off.

Tasks

Tick them off as you go. The state is remembered in your browser, so you can come back to this list tomorrow.

  • A small, concrete task picked – one you can judge at a glance
  • Task started in planning mode
  • Plan read to the end before the decision
  • Plan corrected, if something was missing
  • Plan approved with “Yes, manually approve edits”
  • Result checked in the file itself, not only in the summary
  • A note for the future added to CLAUDE.md, if there was anything to save