Verify Behavior

Verify behavior

Prove or disprove visible product behavior for bugs and greenfield features. Parents (triage, implementation, review) invoke this instead of driving the UI themselves.

Modes

• reproduce — does the reported bug still happen on baseline? (usually default branch; triage)
• verify — does the implemented change match expected behavior? (features and fixes; implementation/review)

Infer if unnamed: issue-only → reproduce; implementation/PR branch → verify.

Platform contract (do not invent alternatives)

Oz computer use is a dedicated capability, not a generic remote child and not a set of parent-callable capture APIs.

Never:

• Call or invent direct request_computer_use, start_recording, or stop_recording from the parent LLM
• Launch generic run_agents remote children as a substitute for computer_use
• Build custom recorder pipelines (ffmpeg, x11grab, avfoundation, Playwright video, etc.)
• Claim gh ... --attach can upload Oz videos to GitHub (it cannot reliably attach native Oz recordings)

When to use / skip

Use for UI, browser, desktop, mobile, or other interactive behavior where visual proof helps.

Skip pure backend/CI/text-only work, or when credentials/state are unavailable (report the blocker). If this skill file is missing, parents continue without visual verification.

PRODUCT.md coverage

When PRODUCT.md exists it is the primary source of stories and acceptance criteria:

1. Read it (parent path, specs/<issue-slug>/PRODUCT.md, or issue/PR links).
2. Build a checklist of exercisable user-facing stories. Newer issue comments win on conflict.
3. reproduce: stories tied to the failure + path to reach it. verify: all in-scope stories (or one assigned story if fanning out).
4. No PRODUCT.md → derive stories from the issue.

Parent workflow

1. Collect mode, issue/PR, branch/ref, setup commands/URLs, surface hints, PRODUCT.md path/excerpts, and expected behavior.
2. Skip if not visually observable; report why.
3. Confirm the current Oz run has computer use enabled. If it does not and you cannot enable it, stop with an explicit blocker — do not fake verification.
4. For each verification unit (full checklist, or one story when fanning out), delegate once to the dedicated computer_use capability with a task that includes:
   • Mode (reproduce | verify)
   • Branch/ref and app setup
   • Exact story/repro path and acceptance checks
   • Instruction to exercise the critical path end-to-end
   • Expected evidence: native session video of the meaningful UI flow (subagent records proactively) plus reported screenshots of key states
   • Instruction to return observations and steps, not a vague pass/fail monologue
5. Multi-story verify: fan out bounded parallel computer_use delegations (about 4–6), one key independent story each; stay single-delegation for reproduce, one story, sequential stories, or scarce credentials.
6. Aggregate statuses: confirmed / partially confirmed / not reproduced / verified / partially verified / not verified / blocked.
7. Fold evidence into triage comments, PR bodies, or review.json. Do not claim behavioral verification without evidence or an explicit blocker.

Delegation task shape

Mode: verify | reproduce
Branch/ref: <implementation head or baseline>
Setup: <install/start commands or URL>
Story or repro: <one checklist item or full path>
Checks: <what must be visibly true>
Evidence required:
- Native Oz computer-use recording of the critical interactive path
- Reported screenshots for baseline, key action, and outcome states
Return: steps taken, observations per check, blockers, artifact/run references

Prefer browser-oriented interaction when the product is a pure web app and the environment provides browser automation inside computer use; prefer full desktop computer use for native surfaces, OS dialogs, or multi-window flows. Record Channel: browser | desktop | hybrid and a one-line why in the parent summary.