# From request to commit

Course: Claude Code: Pro Level — https://zero2vibecode.com/learn/claude-code-pro
Canonical URL: https://zero2vibecode.com/learn/claude-code-pro/5-4-request-to-commit
Verified against: Claude Code v2.1.292 (2026-10-15)
Last updated: 2026-10-15

Asking for a change and accepting whatever arrives is how sessions go off track. Seven steps with a check at each — exploring in plan mode, the plan, implementation, tests, reading the diff, a correction and the commit — turn a request into a change you can stand behind.

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:

```bash
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:

```bash
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`.

**Careful.** 
A screenshot goes to Claude along with the request. Before pasting, crop out anything personal: tokens, email addresses, customer data. And do not confuse Claude's summary with the result: "everything works" is confirmed only by the test output and a diff you read yourself.

**New in 2.1.286.** If your project or user skills include one named verify, Claude is told to run it right before committing — except for docs-only and tests-only commits. Put your pre-commit check in it (tests, linter, build), and the test step of this loop is no longer only yours to remember. How skills are built is in the Skill patterns lesson.