From request to commit

This is the level’s final lesson. Let’s take one real task and carry it from the request to the commit — with a check at every step.

Seven steps

1. Explore in plan mode: Claude reads and answers without changing anything.
2. Plan — approve it only when it matches what you need.
3. Implement — you approve edits as they come.
4. Test — the tests say whether the change works, not the summary Claude writes.
5. Diff — you read it line by line.
6. Correct — anything you do not like, you ask to fix in plain words.
7. Commit — the change is saved and easy to roll back.

The task

A teammate writes: “if linkcheck.json names a folder that does not exist, the tool says all links are fine and exits with code 0.” They attached a screenshot.

1. Explore

Press Shift+Tab until the status line shows ⏸ plan mode on. Paste the screenshot from the clipboard: Ctrl+V (in iTerm2 Cmd+V also works, in Windows and WSL it is Alt+V). An [Image #1] label appears in the input. No label means the image was not added: drag the file into the Claude Code window, or give its path, for example “look at the image .practice/bug.png”.

This is linkcheck's output for a config with a folder that does not exist. Why does it think everything is fine? Where in the code is the folder list read?

2. Plan — with a failing test

Plan the fix. First add a test that reproduces the bug and run it — I want to see it fail. Then fix the code.

This is straight from Anthropic’s recommendations: write a failing test that reproduces the problem, and only then fix it.

While the plan is on screen, open a second terminal and save two things:

git status --porcelain > .practice/before.txt
printf '%s\n' src/config.js src/cli.js test/config.test.js > .practice/plan.txt

The first records that the working tree is clean before you start. The second records which files the plan intends to change, the test included. If the plan names extra files, send it back and ask it to stick to the ones that are needed.

3. Implement

Choose Yes, manually approve edits and approve the edits one by one. Read the commands too: a plain Yes when a command does what the plan needs, and No with an explanation if it does more — for example, stashes changes or overwrites files. Do not choose Yes, and switch to auto mode: then the remaining steps would be checked by background checks rather than by you.

4. Test

The new test should fail first and pass after the fix. Claude Code collapses long command output into a short summary. Ctrl+O expands it — find the test summary at the end; Esc takes you back.

5. Diff

Type /diff. One of two things opens:

• a panel next to the conversation. Test files are hidden in its list until you click the row with a counter like 1 test/generated (show). If the panel already opened by itself, read it there: running /diff again closes it;
• a list above the input. Pick a file with the arrow keys, Enter opens its diff, Esc goes back.

In the second terminal, git diff shows changes in tracked files. A new file Claude created does not appear there until you run git add -N path/to/file. If the diff stops at a colon, that is the pager — q gets you out.

6. Correct

You read the test and see it checks only one case? Say so directly:

The test only checks one missing folder. Add a case where one of three folders does not exist, and run the tests again.

After the correction, look at the diff again and make sure the tests pass.

7. Commit

commit the fix together with the test, and say in the message what changed

Claude asks before running the commit — read the command in full. Then check that the commit touches only the files from the plan:

git show --stat HEAD
cat .practice/plan.txt
git status

The commit must not contain a single file outside the plan, and git status should say nothing to commit, working tree clean.