Review the diff in an order that exposes expensive mistakes early: scope, data flow, errors, tests, then polish. A long list of stylistic suggestions is less useful than one reproducible blocker.

Inspect scope → Review risky boundaries → Run focused checks → Accept or revise
  1. 1Inspect scope
  2. 2Review risky boundaries
  3. 3Run focused checks
  4. 4Accept or revise

Work through the example

Ask for a file location, supporting context and the smallest proposed change. Treat a clean heuristic report as limited evidence.

Start with a disposable branch and synthetic data. Write the expected outcome before changing the implementation, then keep the first failing result. This prevents a later repair from quietly redefining the task. The procedure below is grounded in the repository reference; its examples must still be checked against your project and installed toolchain.

Implementation reference

The following focused section is adapted from the maintained project guide. It preserves the source’s examples and limitations.

3. What counts as evidence

Ordered by strength:

  1. Test output — the suite ran, with counts and pass/fail state.
  2. Build output — it compiles, with the exact command shown.
  3. Command output — a lint run, a script, a grep whose emptiness is the point.
  4. A screenshot — for UI work, the actual rendered result.
  5. A file diff — what changed, when the change itself is the deliverable.
  6. A file:line citation — for claims about what code does.

What does not count:

  • "It should work now."
  • "The change is correct."
  • "I verified the logic."
  • A summary of what a command would print.
  • A test you wrote but did not run.

Evidence for iOS specifically

### Build — SPM
swift build 2>&1 | tail -40

### Build — Xcode. List schemes first; never guess one.
xcodebuild -list -project MyApp.xcodeproj
xcodebuild build -scheme "MyApp" \
  -destination 'platform=iOS Simulator,name=iPhone 16' 2>&1 | tail -40

### Tests
swift test 2>&1 | tail -60
xcodebuild test -scheme "MyApp" \
  -destination 'platform=iOS Simulator,name=iPhone 16' 2>&1 | tail -60

### Lint
swiftlint lint --quiet
swiftformat --lint .

### Rule checks whose empty output IS the evidence
grep -rn "DispatchQueue.main.async" Sources/          # expect: nothing
grep -rn "APIClient\|URLSession" Sources/Presentation/ # expect: nothing

When a grep is the check, show that it returned nothing. An empty result you did not display is indistinguishable from a check you did not run.

When you genuinely cannot build

Common on Linux CI, in containers without Xcode, or in a docs-only repository. Say it once, plainly, and downgrade the affected claims:

UNVERIFIED — no Xcode toolchain in this environment (`xcodebuild: command not
found`). All Swift samples are INSPECTED against the framework docs in
docs/frameworks/, not compiled. A human should build before merging.

Then verify what you can: markdown structure, cross-references, script syntax (bash -n), JSON/YAML validity. Partial verification honestly labelled beats none.

Acceptance and failure review

Checkpoint What to inspect If it does not match
Inspect scope Confirm the input and environment Preserve the failure and return to this step
Review risky boundaries Inspect the intermediate artifact Preserve the failure and return to this step
Run focused checks Run the focused check Preserve the failure and return to this step
Accept or revise Record the observed result Preserve the failure and return to this step

Ask the agent to explain the smallest change that resolves the observed mismatch. Keep unrelated refactors out of the repair. A change that makes a warning disappear is not enough if the behavior or ownership contract has changed. Re-run the same acceptance check so the before and after results are comparable.

Evidence and limits

This is a review procedure, not a guaranteed five-minute duration.

This is an educational guide. Its presence in the series does not certify a completed client-specific lab. The series evidence record separates executed checks from exercises and blocked environments.

Inspect the source used in this lesson.

What to do next

Next: Git for vibe coders: branches per prompt, checkpoints, and undoing an agent's mess