Verify

Agents that did not write the code check every Done means point and fix what fails. Then the same page becomes your review: the code first, then what changed and each point as it ran. A failure is never marked passed.

An example task in a fictional project.

The checks

Project commands and scans produce recorded results:

Project checksTests, types, lint and build run on the commit. A failure is recorded, and the reviewer rules on it.

Code healthComplexity and duplication in the files your agent changed, fed back to it after each turn.Security scansSecrets, dependency advisories, GitHub workflows and risky code. An unavailable scan stays not checked.

Recorded proofA point passes only with evidence: a check's output, a captured response, a screenshot or a file.

Separate agents review the code and its behavior:

Independent reviewReads the whole diff, adds missing tests, runs each Done means step and compares screens with their artifacts. A small task gets one reviewer.

Security reviewWhen the change crosses a trust boundary or edits agent controls. Your agent fixes critical and high findings first.

Design reviewChecks each finished design before you see it, unless you turn Design review off in Settings.

Second opinionA reviewer from another agent family checks risky changes when enabled, or on request. Findings are Taken or Kept.

Note

With Independent review off in Settings, no fresh agent checks the change, and Verify shows it as skipped.

Two fix rounds

A review fails on a Done means point, a red check, a critical or high security finding, lost data, or a bug it reproduces in the changed lines. Your agent fixes it and commits; a fresh reviewer rechecks what failed and what the fix changed. That can happen twice, and a round that fixes nothing ends them early.

When the checks cannot finish

Some failures end the checks: a point still failing after the second round, a prerequisite only you can supply, or an unavailable environment. You get one question: change what Done means says, ask for one more fix round, or stop the task. Work outside the task becomes a follow-up with its owner. No answer marks a failing point as passed.

Review the result

The header counts the points proven, one tick each, and each point shows its evidence as it comes in. Read the record opens agents/03-verify.md, with the findings, commands and every judged round.

WhyThe request in one sentence, then a release-note line for each change users see.

CodeThe complete change and where to start reading.

Diagrams and screensThe change in diagrams, and each screen switched between Designed and Built.

Done meansEach point as it ran, with its picture or output, and whether it ran as a script or in a real agent session.

Anything only you can check, such as your account or a device the agents cannot run, comes to you as a question. What turns up while you review, your agent fixes at once; rechecking shows over the part that changed.

Note

03-verify.md is the pull request description; its pictures stay on your computer unless you publish them. For changed lasting artifacts, choose which pages to fold in.

Read the code

Review the code opens the file tree and a Unified / Split diff. Viewed saves your reading progress; All viewed and Clear apply to every file.

Ask about any line

Select the lines you want to discuss. Write in the quick feedback field and send it to your agent with the file, revision and selected lines. Sending it never approves the change or allows a push.

Findings from the agents

Security and second-opinion findings appear on their lines. Request a change, or record why a finding is not a problem; the reason becomes a project lesson for later reviews.

Ask another reviewer

Ask another reviewer picks an installed agent that did not build the change. It reviews one file or all files, edits nothing and stops after 8 minutes.

Approve

Approve the whole change in the page header, also when its agent has stopped. Your approval always saves, even when the code moved after the checks or a recheck is running.

ApproveApproves the change and never pushes. The conversation stays open for merge, deploy and tweaks.

Pull requestPushes the task's branch and opens GitHub's page with the title and description filled in. You create the pull request there. Needs gh.

After you approve

Ask your agent to merge, push, deploy or run end-to-end tests; each still needs your request.

Verify shows	What you do
Not merged yet	Merge as usual. Merged on the web? Pull the base branch. While no pull request is open, Mark as merged works too
1 change since your approval	Your agent committed a tweak. Press View the change, then Approve change in the header. With an open pull request, your merge accepts it
Merged into main	The task is in Shipped. New work starts with Start a follow-up

QualityLayer recognizes local merges, including squash and rebase, and pull requests it opened on GitHub. For work built directly on main, only that task's fixes count (details).