Verify
This skill decides when a change may be called done. It asks for evidence from the running result, not from a passing build.
A build is not evidence
A typecheck, a lint pass or a green build does not show that a visual or behavioural change works. Saying "fixed" without opening the result is a finding. Opening it and reporting an imperfect result is not.
Run it after any change to UI or behaviour, before replying "done". Run it at once when the user says "still", "nothing changed" or "test it yourself". What to change belongs to scope. Matching an outside app belongs to match.
1. See the problem first
Open the app, the page or the output and find the symptom before editing. Use the browser, a screenshot or computer use. Editing from the description alone is verify-reproduce-first. When you cannot reach the running result, say what blocks you.
2. Look where the user will look
Reload, or confirm hot reload applied, then look at the same place. A build pass offered as proof is verify-build-is-not-proof. Click every control you added once. A control with no effect is verify-click-new-controls.
Look at the whole surface, not only the line you edited. Scroll to both ends and open each state the change touches. Checking only the edited element is verify-whole-surface.
3. Find the cause on a repeat report
When the user reports the same problem again, stop adjusting the same value. Diff against the last commit where it worked, read the computed style or search for the cause. A third guess at one property is verify-root-cause-on-repeat.
4. Report what you saw
Say what you checked, how and where the user can see it: the route, the window, the menu path or the folder. "It should work now" is verify-say-where. Open the result for the user when you can. A bare output path is verify-open-the-result.
Name anything you could not check and why. "Done" with an unchecked item is verify-name-the-gap.
The pair
Every check is a pair. The broken line sits beside the line that replaces it.
| Rule | Broken | Replacement |
|---|---|---|
verify-reproduce-first |
Editing from the bug report alone | Open the screen, see the bug, then edit |
verify-build-is-not-proof |
"Typecheck passes, so it is fixed" | "Reloaded Settings and the toggle now persists" |
verify-click-new-controls |
A new "Add Condition" button with no handler | Click it once and see a row appear |
verify-whole-surface |
Checking the edited row only | The whole panel, scrolled to both ends |
verify-root-cause-on-repeat |
A third tweak to the same padding |
Diff against the last working commit, then fix |
verify-say-where |
"It should work now" | "Open Library, right-click a save, choose Hide" |
verify-open-the-result |
~/Downloads/clips printed in the reply |
The folder opened for the user |
verify-name-the-gap |
"Done" while export was never run | "Not verified: export, it needs a signed build" |
Reporting
Severity. HIGH is "done" with no look at the running result, or a new control that does nothing. MEDIUM is a repeat report met with another guess, or a reply with no place to see the change. LOW is a checked change whose reply omits how it was checked.
Format. One finding per root cause, citing the request when no file applies:
file:line - [rule-id] what is wrong
request 2 - [rule-id] what is wrong
Then a Rule | Count | Severity summary. Block when any HIGH remains, Approve otherwise. Never Approve a change you did not open. Mark every check you could not run as Not verified.