Review answers one question: does the actual result meet the request? It is different from Approval, which gives permission for an action to happen.

​
What a useful review leaves behind

A useful review shows what was checked, what decision was made, why, and who owns the next step.

​
Before you start

The Issue should have:
  • a named reviewer
  • a result that can actually be opened
  • clear acceptance criteria
  • links to relevant Runs, checks, and known risks

​
Review the result

  1. Open the Issue and read the original request and acceptance criteria.
  2. Open the produced file, preview, report, screenshot, or link. Do not approve work from a summary alone.
  3. Check the important facts and tests. Open the Agent Run when you need to see which runtime ran, whether it finished, what it changed, or why it failed.
  4. Compare the result with each acceptance criterion.
  5. Record one decision with a specific comment:
    • Accept when the result meets the request.
    • Request changes when the assignee should revise it.
    • Blocked when a required input, permission, or result is missing.
  6. Create a follow-up Issue for separate work instead of hiding it in a vague acceptance comment.

​
Check the review

A later reader should be able to see the result, the reason for the decision, and the next owner without opening a private chat or reconstructing the Run. Accepted work closes through the review action; requested changes keep the review comment and return the task to its assignee.

​
If you cannot decide

Do not accept a task with a missing result or missing proof. Ask for the exact file, source, test, screenshot, or Run detail you need. If the review reveals a lesson that should affect future work, save the feedback first. Propose a Skill or instruction change separately, with the examples it is based on and a way to test or undo it.