Workflow: review a code change suggested by an assistant
Read the diff before running it, run the tests before and after, and keep the change small enough to explain in one sentence.
SampleWritten to demonstrate the format. It does not describe the owner’s experience, results or recommendations.
A coding assistant can produce a working-looking change faster than it can be reviewed. This workflow keeps review in control: nothing is merged that has not been read, tested and explained.
Step 1: start from a clean state
Commit or stash your own work first, so the assistant's change is the only difference.
git status --short
git stash push -m "before assistant change"git status --short prints nothing.
Step 2: run the tests before the change
Record the result. A change cannot be judged against a baseline you never saw.
python3 -m unittest discover -s testsStep 3: read the whole diff
Read every line, including files you did not expect to change. Ask the assistant to explain any line you cannot explain yourself.
- total = sum(items)
+ total = sum(item.amount for item in items if item.amount is not None)Step 4: run the tests again and compare
The same tests should pass, plus any new ones. A test that was removed or weakened needs a reason.
Every test that passed in step 2 still passes, and no test was deleted without an explanation.
Step 5: write the one-sentence summary
If the change cannot be described in one sentence, split it. The sentence becomes the commit message.
| Signal | What to do |
|---|---|
| Diff touches unrelated files | Ask for a smaller change |
| New dependency appears | Stop and review it separately |
| Tests were edited to pass | Treat as a failed review |
See the project's own contribution notes (external site) for team-specific rules.