Your first change, from request to commit

01The goal

Take one change from request to commit: explore, plan, implement, test, review the diff line by line, correct, and commit. After this lesson, "the agent changed my code" becomes "I shipped a change the agent wrote" — the difference is the loop.

02The idea

Anthropic’s own best-practices page recommends explore, plan, implement, commit. We add the checks a review-driven team insists on between those steps:

The two most often skipped are the two that matter most. First, the summary is not the work: Claude’s closing paragraph is a claim; the test output is evidence. Second, the diff is where you find the extra "helpful" edits no plan mentioned — the renamed variable two files away, the added dependency. On our board, an implementer’s last step is to land work in review, never done, and the commit is the reviewer’s evidence. You are both roles today.

03The walkthrough

Identify a real gap in your scratch repository — for instance, a link checker that skips links with titles or a parser that silently accepts empty input. If you cannot find a suitable candidate, create a small Markdown link checker as a starting point: ask Claude for it in plan mode, as this is lesson 2 in action.

1. 01Plan mode on (Shift+Tab). Explore: "How does this app find links in a Markdown file? Which kinds would it miss?" — make Claude show you the code before it proposes anything.
2. 02Plan: "Plan a change so links with a title, like [setup](setup.md "Setup guide"), are checked too. Add a test." If the plan names files that surprise you, send it back with one correction (lesson 2). Approve with "Yes, manually approve edits".
3. 03Implement. Approve each edit; read each command before it runs. Yes when it matches the plan; No, and redirect, when it does more — a command that stashes, overwrites or moves files is the usual suspect.
4. 04Test, and see it yourself: "run the tests". Long output collapses to a summary — Ctrl+O expands it; find the test summary near the end; Esc returns. Look for fail 0 with your own eyes.
5. 05Review: /diff shows the changes beside anything else uncommitted. Read every line, the test included. A brand-new file will not appear in git diff until git add -N <file> — do that, then look again.
6. 06Correct, always at least once. Read the new test: if it covers only the double-quoted case, ask for a single-quoted case too — "Add a case for [faq](faq.md ‘FAQ’) and run the tests again." You are teaching yourself to expect completeness, and teaching the session that you read.
7. 07Commit: "commit this with a message that says what changed." Read the whole commit command before approving it. Then in your terminal: git show --stat HEAD — one commit, code and test together — and git status, which should end "nothing to commit, working tree clean".

04Your turn

A second gap, same loop, without the training wheels: angle-bracket link targets like [notes](<my notes.md>) if you used the link checker, or a second parser edge case in your own repo. The full loop, ending in a commit whose stat shows code and test together. One correction minimum. If the tests fail, read the first failure and ask Claude to fix the code — not the test.

Two guardrails while you practise. Never fix a failing test by weakening the test — the test is the spec you just wrote; change it consciously or not at all. And never approve a commit command you have not read: branch names, --amend, and unexpectedly staged files all live in that one line.