verify-criteria

When to use

Call this skill whenever a task had an explicit acceptanceCriteria: [...] list from the user — and an artifact exists that might satisfy them. Examples:

• Coding task: "has booking button", "mobile-friendly", "shows hours"
• Marketing task: "under 125 chars", "mentions the discount"
• Design task: "works in monochrome", "readable at 16px"
• Research task: "cites at least 3 sources", "covers competitor pricing"

What you do

For each criterion, judge strictly:

• passed: true — you can directly verify it from the artifact
• passed: false — you can directly verify it fails
• passed: null — you cannot tell from available information

Be conservative. Never mark passed: true without direct evidence. "Probably fine" is null, not true. "Likely broken" is null, not false. This is the only way the output earns trust.

Use whatever tools make sense to actually check:

• Artifact is a URL → Bash curl -I, Bash agent-browser navigate ... snapshot
• Artifact is a text blob → just read and reason
• Artifact is a file on disk → Read tool
• Criterion mentions specific behavior (e.g. "form submits") → actually
exercise it via agent-browser or curl

Output format

Return JSON exactly like this on your final message (no other text after):

{
  "checks": [
    {"name": "<criterion verbatim>", "passed": true,  "note": "<1-sentence evidence>"},
    {"name": "<criterion verbatim>", "passed": false, "note": "<1-sentence evidence>"},
    {"name": "<criterion verbatim>", "passed": null,  "note": "<why you can't tell>"}
  ]
}

Keep each note to one short sentence with concrete evidence ("found Book at /" or "no h1 tag in returned HTML").

What NOT to do

• Don't reinterpret the criteria loosely. "Shows hours" means hours are
actually rendered — not that the word "hours" appears somewhere.
• Don't skip criteria you find vague. Mark them passed: null and say
"criterion too vague to verify automatically" in the note.
• Don't pass/fail criteria you weren't given. Only judge what's asked.