Skip to main content

Start with the original request

A worker saying “finished” is a useful signal to inspect its report. It is not by itself proof that the result was saved, uploaded, or deployed. Use this lesson after assigning one project task.

1. Ask for a report you can check

Expected result: another assistant can locate the same files without asking you to reconstruct the conversation.

2. Separate the evidence

A Linux reviewer should not present a Windows-only test as independently rerun. A simulated provider test proves the tested mechanics, not a real model’s performance.

3. Correct one concrete gap

If the report exists only locally, ask the worker to publish and verify that report. Do not repeat the underlying work just to recreate a missing message. If the behavior is wrong, describe the unmet requirement, the evidence, and the smallest useful correction. Preserve the failed attempt in its branch and record a new attempt separately.

4. Stop when the task is sufficiently verified

For an ordinary documentation change, inspect the text, links, and build. Do not turn every review into an unlimited search for hypothetical failures. Additional checks should resolve a concrete risk or an agreed requirement. Expected result: a clear acceptance or one bounded follow-up, with reasons. Next: continue in a new chat.