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.

Layer	What happens
Outer Oz cloud run	Must already have computer use enabled (computer_use: true / --computer-use / computer_use_enabled: true). Factory implement workflows set this on the parent run.
Parent / orchestrator	Delegates GUI work through the platform computer_use capability with a concrete task and expected evidence.
Permission	request_computer_use is emitted automatically when the computer-use subagent starts. Parents must not call it, simulate it, or document fake tool calls for it.
Computer-use subagent	Native prompt already covers GUI actions, proactive start_recording / stop_recording, report_screenshot, and forbids ffmpeg / screen-capture CLIs. Do not re-teach capture plumbing or shell out to recorders.

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.

Evidence requirements

For every meaningful UI flow:

1. Native Oz video artifact — produced inside the computer-use session via platform recording. Required unless the subagent reports that recording failed; quote that failure.
2. Durable Oz links — include https://oz.warp.dev/runs/<run-id> (or https://oz.staging.warp.dev/runs/<run-id> on staging). Never app.warp.dev or /run/ (singular).
3. Reported screenshots — supplementary keyframes via the subagent's report_screenshot path; useful, not a substitute for video on multi-step flows.
4. PR / issue write-up — status, story checklist outcomes, Oz run link(s), and pointers to the native video/screenshot artifacts on the Oz run. Prefer platform PR artifact helpers (e.g. get_artifacts_for_pull_request_description) when available so managed screenshot/video markdown is embedded. Do not invent gh --attach video uploads.

Screenshots-only is allowed only when recording was attempted and failed, with the error quoted, or when the check is a single static state with no meaningful motion.

A verification that never delegated to computer_use on a computer-use-enabled run is incomplete.

Screenshot captions (required on GitHub)

Whenever a screenshot is posted back to a GitHub issue or PR — including platform-managed evidence blocks, PR body sections, issue comments, and any other evidence summary — put a concise caption immediately below each screenshot that states:

1. The UI state or test case being verified (e.g. idle preview, in-flight submit, settled error)
2. What the screenshot demonstrates relative to the acceptance check (e.g. overlay present with spinner; overlay cleared)

Apply captions for managed markdown (e.g. ![…](…) from artifact helpers) and for any hand-written evidence summary. Prefer short one-liners under each image; do not dump long prose. If the platform helper only supplies alt text, still add an explicit caption line under the image in the issue/PR write-up when you control that text.

Do not invent unsupported upload commands to satisfy captions. Captions travel with whatever evidence path the platform already supports.

Report shape

Behavior verification:
- Mode / change type / channel(s) / fan-out
- Status / issue-PR / branch-ref
- PRODUCT.md stories: n passed / failed / blocked / not run
- Oz run: https://oz.warp.dev/runs/<id>
- Evidence: native video (required for flows) + captioned screenshots (supplementary)
- Findings / next step

reproduce statuses: confirmed | partially confirmed | not reproduced | blocked verify statuses: verified | partially verified | not verified | blocked

Guardrails

• Delegate GUI work through computer_use; parents do not click through unless the user explicitly asks
• Outer run must have computer use enabled; do not substitute generic remote children
• Do not call request_computer_use or parent-level recording APIs
• No ffmpeg or external recorders
• Native Oz video required for meaningful UI flows; screenshots supplement
• Every GitHub-posted screenshot needs a concise caption (state/case + what it shows)
• Durable Oz run/artifact links on issue and PR write-ups; no fake GitHub binary-attach of Oz recordings
• Features are first-class; PRODUCT.md drives coverage when present
• Bounded fan-out; no secrets in prompts, screenshots, or reports
• No claim of verification without evidence or an explicit blocker

Optional verify-behavior-local may specialize setup/surface/fan-out only — not weaken evidence, privacy, captions, or this contract.