Skip to main content
The verify command spawns a fresh verifier subagent that has not participated in building or evidence packing. The verifier’s source of truth is the current repository state and the results of checks it reruns now — not the builder’s chat narrative or prior session context.
The verifier must be a fresh session or fresh subagent. It must not modify production code and must not edit the evidence bundle to make it appear more complete.

​
Parent prompt

Copy this prompt verbatim when delegating to the verifier subagent. Replace <TASK_ID> with the actual task identifier. 
You are a strict fresh-session verifier for TASK_ID <TASK_ID>. You are not the implementer.

Read in this order:
1. .agent/tasks/<TASK_ID>/spec.md
2. .agent/tasks/<TASK_ID>/evidence.md
3. .agent/tasks/<TASK_ID>/evidence.json

Then independently inspect the current codebase and rerun verification.
Source of truth is the current repository state and current command results, not prior chat claims.
Use the currently available verification surface directly. If browser or MCP tools are available and relevant, use them rather than narrowing yourself to code reading alone.

Write:
- .agent/tasks/<TASK_ID>/verdict.json

If overall verdict is not PASS, also write:
- .agent/tasks/<TASK_ID>/problems.md

Rules:
- PASS an AC only if it is proven in the current codebase now
- FAIL if contradicted, broken, or incomplete
- UNKNOWN if it cannot be verified locally
- Overall PASS only if every AC PASS
- Do not modify production code
- Do not edit the evidence bundle

`problems.md` requirements for each non-PASS AC:
- criterion id and text
- status
- why it is not proven
- minimal reproduction steps
- expected vs actual
- affected files
- smallest safe fix
- corrective hint in 1-3 sentences

Return only:
- overall_verdict
- created files
- one-line reason for each non-PASS AC

​
What the verifier reads

1

spec.md

The frozen acceptance criteria. The verifier uses these as the standard against which the current codebase is judged.
2

evidence.md and evidence.json

The builder’s evidence bundle. The verifier reads these to understand what was claimed, then independently reruns the same checks to confirm or refute the claims.
3

Current codebase

The verifier inspects the repository state directly and reruns verification commands. Browser or MCP tools should be used if available and relevant.

​
What the verifier writes

verdict.json

Always written, regardless of outcome. Contains the overall verdict and per-AC statuses with reasons.

problems.md

Written only when the overall verdict is not PASS. Contains structured remediation information for each failing criterion.

​
problems.md requirements

For every AC that is not PASS, problems.md must include a dedicated section containing:
​
criterion id and text
string
required
The AC1, AC2, … label and the full criterion text from spec.md.
​
status
string
required
FAIL or UNKNOWN.
​
why it is not proven
string
required
Explanation of what evidence is missing, contradicted, or unverifiable.
​
minimal reproduction steps
string
required
The smallest sequence of commands or actions that reproduce the failure.
​
expected vs actual
string
required
The expected behavior or state versus what was observed.
​
affected files
string
required
File paths relevant to the failure.
​
smallest safe fix
string
required
The minimal change that would satisfy this criterion without regressing others.
​
corrective hint
string
required
1–3 sentences guiding the fixer toward the correct solution.

​
Hard boundaries

Must not modify

Any production code file. The verifier is a reader and judge only.

Must not edit

The evidence bundle. Patching evidence to make it look complete is a hard violation.
After a fix run, always spawn a new fresh verifier. The same verifier session must not be reused for subsequent verification passes.

Build docs developers (and LLMs) love

Get started for freeTalk to us