Review, undo, and commit your first change

This lesson reviews an existing, uncommitted patch: the one the previous lesson asked Claude to make in the course’s payments service, an Express and TypeScript app whose routes begin in src/index.ts, with Vitest tests in tests/ run by npm test. Expect edits to src/index.ts, a new tests/health.test.ts, and possibly an extracted src/app.ts. If you are reviewing an agent’s patch in your own repository, substitute its files; the questions are the same.

The agent has added the endpoint and reported its checks. Before reading that report again, try explaining the change from the files alone. The ticket gives you three things to look for: GET /healthz returns HTTP 200 with the JSON body {"status":"ok"}, GET /health still returns that same status and body, and payment behavior is unchanged.

In a separate terminal at the project root, start with the commands below. They need a Git repository with a baseline commit; if your copy has no history, the install lesson shows how to create one.

git status --short
git diff --stat
git diff

Compare the status with the Git status and npm test result recorded before the change. If you did not record one, establish first which changes belong to this task, from the status and the diff, before you stage anything. git diff shows unstaged changes to tracked files. A newly created, untracked test will appear in git status but not in that diff; open it in your editor. If the agent staged files, inspect those separately with git diff --cached.

Follow the request through the patch

Find where /healthz is registered, then find /health. If the second route disappeared, the new code has met only half the requirement. If both exist, trace them to the response they send.

Next inspect tests/health.test.ts. Does it make requests to the application, or does it build a local object and assert that the object equals itself? A test can be green while proving nothing about the route. Check that it asserts the status and parsed JSON body for both addresses, and that it closes any server it starts.

If the agent extracted src/app.ts, follow the old routes into the new file. A moved block should not quietly change payment calculations or middleware order. This is why the ticket’s boundaries were useful: you have a concrete reason to question edits outside the health routes and the small refactor needed to test them.

Before accepting the test, try a prediction. If /healthz returned {"status":"up"} instead of the required {"status":"ok"}, which assertion would fail? If you cannot point to one, the test does not yet establish the promised body. Correct that gap, then run the focused test and full suite again with the test commands from the lesson that made the change.

Repair a mistake at its actual size

A wrong expected string usually needs a small correction. Ask for that correction and rerun the check. If the agent has misunderstood the task and spread the mistake across several files, returning to an earlier checkpoint may be easier to review than another layer of edits.

Claude Code’s /rewind menu lets you choose a checkpoint and what to restore. With an empty prompt, pressing Esc twice also opens it. Read the selected restoration before confirming; this is a choice about state, not a universal undo key. Checkpointing tracks edits made through Claude’s file-editing tools. It does not undo arbitrary shell commands or changes to external systems.

After a restoration, inspect Git status and rerun the relevant checks. The useful question is what is on disk now. A remembered good state is not a substitute for looking.

Add a second reader with /code-review

Reading the diff yourself catches whether the patch matches the ticket. A separate reviewer can catch defects you were not looking for. /code-review runs one inside your session: it reviews the changes on your branch for correctness bugs, in a background subagent with its own context window, and the findings arrive in your conversation when it finishes. It works on any plan and counts toward your usage like the rest of the session (local code review docs, checked 2026-10-25).

/code-review
/code-review 1234
/code-review src/auth
/code-review main...my-feature

With no target it covers your branch’s commits ahead of upstream plus uncommitted changes. A pull request number, a path, a branch comparison, or a commit range works as a target. Three flags change what happens to the findings:

• --fix also asks Claude to apply the findings to the working tree. Its edits go through your permission mode, and a background review’s edits sit outside the session’s checkpoints, so /rewind will not undo them. Use git to revert.
• --comment posts the findings on a GitHub pull request as inline comments, or on a GitLab merge request as one note.
• An effort level before the target (low through max) trades coverage for confidence. At low the review reports only the findings it is most confident in.

Treat the output as a list of leads, not a verdict. It does not replace the diff reading above; it is a second pass over the same files. The review follows your CLAUDE.md, so a rule like the payments project’s integer-cents requirement is something it can check against.

Cloud review with ultrareview (research preview)

/code-review ultra (aliased as /ultrareview where available to your account) runs a fleet of reviewer agents in a cloud sandbox and reports findings that were independently reproduced. The docs label it a research preview, so its pricing and availability can change. It needs a claude.ai login, shows a cost confirmation before launching, and is unavailable on Amazon Bedrock, Google Cloud’s Agent Platform, Microsoft Foundry, and organizations with Zero Data Retention or the HIPAA configuration, where /code-review ultra falls back to a local review (ultrareview docs, checked 2026-10-25). In scripts, use claude ultrareview (optionally with a PR number); it blocks until the review finishes and prints the findings. claude -p '/code-review ultra' launches the review and exits without waiting, so it does not return findings.

For reviews on every pull request without anyone typing a command, the docs describe a separate managed Code Review service that an organization Owner turns on.

Decide whether there is a commit to make

The course payments project’s instructions require passing tests before a commit. Its shipped baseline is six passing tests, so any full-suite failure after this change is a regression unless your own recorded baseline says otherwise. Stop and investigate it. Do not expand the health ticket into an unrelated payment repair just to reach a satisfying ending.

When the required checks pass and the diff is right, stage only the reviewed files. For the app-extraction approach discussed above, the commands would be:

git add src/index.ts src/app.ts tests/health.test.ts
git diff --cached
git diff --cached --check
git commit -m "Add healthz endpoint while preserving health"

Adjust the file list to the implementation you actually reviewed. git diff --cached --check flags whitespace errors and leftover conflict markers before they enter history. If other changes are already staged, separate them first. The commit includes everything in the index, not just the paths from your latest git add.

Explicit staging also catches an easy mistake in agent-generated commit commands: git commit -am does not add new files. It could commit the endpoint and omit its new test. Reading the staged diff lets you inspect what will actually enter history.

The result you want is explainable without the agent’s summary: this route changed, these tests exercise it, these checks passed, and these limitations remain. Put that review loop beside your editor so it is easy to repeat on the next ticket.