Step 1 of 4
Define the verifier with hard read-only constraints
Constraints in the tool pool, not just the prompt.
Create the verification agent definition. Tool pool: remove edit/write/file-creation tools entirely - the constraint must be structural, so a verifier that decides to 'just fix it' physically cannot; allow read, search, and command execution (it must run builds and tests). Prompt: state the role ('verify, never repair'), the evidence rule (every claim needs the command run and output observed), and the verdict format. Add a critical reminder mechanism that re-injects the read-only constraint every user turn - long verification sessions are exactly where agents forget their role. Permission mode: command execution should surface to the parent's approval flow rather than running silently. Verify the constraint by asking a test instance to fix a trivial bug: it must refuse and report instead.
Expected after this step
A verifier agent whose tool pool enforces read-only and whose constraints self-refresh.
Should not happen
- ✕The verifier 'fixes' issues it finds, silently becoming a second implementer
- ✕Checks reported as passed with no command output - verification theater
- ✕Happy-path-only testing that is fooled by the first 80% looking right
- ✕The implementer summarizes the task for the verifier, laundering away the failed requirements
Verify before continuing
Do not move on until every check is true. The complete button stays locked until then.
Do not continue if…
- !The verifier 'fixes' issues it finds, silently becoming a second implementer
- !Checks reported as passed with no command output - verification theater
- !Happy-path-only testing that is fooled by the first 80% looking right
- !The implementer summarizes the task for the verifier, laundering away the failed requirements
If the AI messes this up
Use this when the AI fakes progress or breaks the feature. It forces a real fix.
The verifier edited a file through a shell command. Command execution is a write path too: route its commands through your security pipeline with write-operations gated, or run verification in a disposable worktree so any mutation is contained and detectable.