Check the intern's work

Your mission

Make a change to your game, then review it like a lead developer before it goes live: read the diff, make Claude justify every change, and run a code review that hunts for bugs.

Why it’s worth it

Your game is public now. If you push a bug, your friends find it. Pros catch problems before that, and the way they do it is a review: looking at exactly what changed, before it ships.

Think of Claude as an incredibly fast intern. Brilliant, tireless, and sometimes a little too creative: it might “tidy up” a file you didn’t mention, or fix a bug by hiding it. You’re the lead. Checking the intern’s work isn’t distrust, it’s the job. And it’s a big part of what the Final Boss tests.

The diff: what actually changed

A diff shows the exact lines that changed: lines added (usually shown in green, with a +) and lines removed (red, with a -). It shows nothing that stayed the same, which makes it the fastest way to review.

Three questions for every diff:

1. Did it change only what I asked for? Unexpected files are the biggest red flag.
2. Does each change make sense? If not, ask why.
3. Is anything missing? Like the edge case you mentioned.

You don’t need to understand every line of code to ask these questions. “Why did style.css change when I only asked for a new power-up?” is a great question even if you can’t read CSS.

Build it

Open your neon-dodge folder and start Claude.

1. Make a change worth reviewing.

Add a slow-motion power-up: a blue diamond that makes the blocks fall at
half speed for 5 seconds. Don't commit yet.

2. See the diff.

Show me a summary of what changed since my last commit: which files, and
roughly how many lines in each.

What you’ll see: Claude runs git diff --stat and lists the changed files. Do they match what you expected? If a file is there that has nothing to do with slow-motion, that’s your first question.

3. Make Claude explain itself.

Walk me through the diff file by file. For each change, say what it does and
why it was needed. Flag anything that isn't strictly needed for slow-motion.

What you’ll see: a plain-English tour of the change. If Claude flags extra changes, decide: keep them, or ask “Undo the changes that aren’t needed for slow-motion.”

4. Run the code review.

/code-review

What you’ll see: the review runs in the background (you can keep chatting), then reports findings: likely bugs, each pointing to a file and line. For example, “the slow-motion timer isn’t reset when the game restarts”. Ask Claude to fix the ones that are real.

5. Playtest, commit, push. Play the game with the slow-motion power-up, including restarting mid-power-up. Then:

Commit with a clear message and push.

Boom. That change went through a real review before your players ever saw it.

Red flags to watch for

• Files you didn’t mention changed.
• Tests or checks were changed or deleted to make something “pass” (you’ll meet tests in Level 7).
• “While I was there, I also…”: bonus changes make reviews harder. Ask for them as a separate change.
• A fix that hides the problem, like wrapping code in something that silently ignores errors.

When Claude gets confused

• The review finds a “bug” that isn’t one. Reviews can be wrong too. If you’re not sure, ask Claude to explain how the bug would actually happen, step by step; if it can’t, skip it.
• The diff is huge for a small request. Claude sometimes reformats a whole file. Ask: “Undo any changes that are only formatting, keep the slow-motion feature.”
• /code-review says there’s nothing to review. It reviews uncommitted and branch changes. If you already committed everything, ask Claude to review the last commit instead: “Review the last commit for bugs.”

Did it work?

• You checked which files changed before committing
• Claude explained each change, and you questioned at least one
• You ran /code-review and handled its findings
• The reviewed change is committed and live on your site