Why this matters
Pathway C’s standard is a change in a repository, not a screenshot of a chat. Grok Build will happily write across six files because the model thought it was being helpful. Your job is the same job it is on a human PR: look at the diff, ask whether this is what you asked for, and refuse the rest.
C2 taught the permission card. C3 taught you not to start until the approach is chosen. This module is the middle of the real loop — implement a small change in a real git repo, read the proposed edits, accept only what you intend, and prove it with git diff. If you cannot describe the diff in a sentence, you are not done reviewing.
Teach
Pick a repo that can take a bruise
Use a repository you own:
- The C1 scratch repo is legal if you add a tiny bit of real structure (a script, a config, a second markdown file).
- Better: a personal project or a throwaway clone of something small you understand.
- Not legal: this LMS, a client tree, Golf, Explorer, anyone else’s default branch, or a repo you cannot reset.
Grok’s working directory is the launch directory (grok or grok --cwd). Sessions group by that path. Launch from the repo root so @ and project files resolve where you think they do.
Before you prompt, know the starting point:
git status
git diff
git log -5 --oneline
If the tree is already dirty, either commit your own work or stash it. You need a clean baseline so you can see what Grok changed.
Bound the ask
Bad: “Improve this repo.” “Fix whatever is wrong.” “Make it production ready.”
Good: one outcome, named files or a named behavior, explicit non-goals.
In this repo, add a PRACTICE-LOG.md with a short heading template
(date, task, what I refused). Do not edit existing files except
README.md, and only if you add a single link to the new file.
Do not commit. Do not add dependencies. Do not reformat anything.
Attach the files that matter (@README.md) so Grok does not wander. If the change is a function, attach the file and a line range.
If the approach is still ambiguous, /plan first (C3), approve, then implement. If the path is obvious, stay in Normal and watch the diffs.
What “read the diff” means
When search_replace or a write lands in scrollback:
- Read the path. Wrong file → reject.
- Expand the block. Open the viewer (
Enter). A +12/-3 pill is not a review.
- Read every hunk. Ask: is this the behavior I asked for? Did it rename something for style? Did it “fix” a comment? Did it touch tests you did not name?
- If two files changed and you asked for one, reject and say so.
- Allow once only after that.
Then leave the TUI’s word as insufficient. In the same session or in another terminal:
git status
git diff
git status is on the read-only auto-approve list. So is git diff. Read them yourself. If Grok summarizes the diff, that summary is not the artifact. The patch is.
If you do not like what landed, you have git. git checkout -- path or git restore path throws away an uncommitted file. Tell Grok what was wrong and make it send a smaller edit. Do not pile a second “fix the fix” on top of a messy tree without looking.
Commits are a separate decision
Grok will offer to commit. The default answer is no.
- You did not ask.
- You have not run the tests (if any exist).
- You have not looked at
git diff --staged.
- Conventional messages are fine; surprise
git add . is not.
If you do want a commit later, you stage what you intend, you read git diff --cached, and you write or accept a message that matches the hunks. git push is on the dangerous-command list and should scare you in a practice module. Do not push from this lesson.
/review exists as a bundled skill for a second-pass review of local changes. It is optional here. It does not replace your own reading of the TUI diff and git diff. If you use it, still reject or restore anything it flags that you agree with.
Rewind is not a substitute for git
/rewind (alias /undo) rolls the conversation back. It is not a guaranteed clean restore of every file on every setup. Treat git as the source of truth for the tree. If a turn went sideways, restore the files, then rewind or /new if the chat is junk.
/compact shrinks context. After a long implement-and-reject loop, start /new with a tighter prompt rather than arguing with a polluted session.
Worked example
A personal scratch repo with README.md only.
@README.md
Create PRACTICE-LOG.md in the repo root with this exact skeleton:
# Practice log
## YYYY-MM-DD
- Task:
- Accepted:
- Refused:
Add one markdown link to that file from README.md. Do not change
any other wording in README.md. Do not commit. Do not add a
license, CI, or extra docs.
Grok reads README.md, writes PRACTICE-LOG.md, patches the README.
You open both diffs. The new file matches the skeleton. The README hunk is one link. You allow each edit once (or reject the README if it rewrote the title).
Then:
Show git status and git diff. Do not stage, commit, or push.
You read the same two paths in git. You add a first log entry yourself, or you ask Grok to add today’s date as a filled section — and you read that third diff too.
If Grok also added CONTRIBUTING.md or restyled the README, you reject, git restore anything that already landed, and repeat the prompt with “only those two files.”
That is a passing loop: bounded ask, two files, two reviews, git agrees.
If you do not write software. The “real repo” is the C0b scratch repository. The change is a heading on a price list, a “last updated” sentence on a letter, or a one-line index of the files you already have. Bound it. Read every hunk. git status and git diff are the artifact. You have reached repo level when you can describe that diff in a sentence and refuse the rest.
Your turn
Do c4-l01-e1 in Grok Build, in a git repo you own. You will ask for a small change, reject at least one over-broad edit, accept a narrow one after reading the TUI diff, and attach git status plus git diff as proof. No commit required. No push.
Common failure
The tree was dirty and you cannot tell what Grok did. Stop. git diff against a dirty baseline is how people keep junk. Reset or stash your own work, /new, try again.
You accepted a multi-file “cleanup” because the main hunk looked right. Restore the extra files. The review is of the whole patch, not the headline.
You let it commit. The exercise fails. git reset if you need the commit gone (only on this practice repo, only if you understand what reset does). Do not force-push anything.
You reviewed Grok’s prose instead of the diff. “I added a practice log and linked it” can hide a 80-line README rewrite. Open the viewer.
You ran --yolo because there were many cards. Fewer, smaller prompts. One file per turn if you have to.
What’s next
C5 is how you stop re-explaining the repo every session: AGENTS.md, project rules, and (separately) experimental memory. Rules are not a substitute for reading diffs. They are how Grok starts closer to your conventions before the first edit lands.
