Reproduce Bug Report

# Reproduce bug report

Use this skill when the current context is a GitHub issue, support report, Linear ticket, or user prompt describing a specific bug that may be reproduced through visible application behavior. It is primarily for UI, rendering, windowing, settings, editor, terminal-display, onboarding, or other interactive bugs where screenshots or recordings make the result more actionable.

The parent agent should not try to manually reproduce the UI bug locally unless the user explicitly asks. Launch one or more Oz cloud agents with computer use enabled so they can run the relevant app, interact with it, and capture visual evidence.

## Parent workflow

1. Read the bug report carefully and extract:
   - reported behavior
   - expected behavior
   - reproduction steps, if provided
   - OS, app version/build/channel, shell, feature flags, account state, or other environment constraints when relevant
   - attached screenshots, videos, logs, or comments that narrow the repro path
2. Decide whether this skill applies:
   - Use it for UI-visible bugs, interaction bugs, rendering/layout bugs, onboarding bugs, and bugs where screenshot evidence would be useful.
   - Do not use it for purely backend, CI, build, dependency, or text-only code issues unless the prompt specifically asks for visual reproduction.
   - If the report requires credentials, private account state, or another capability not available to the repro environment, report that constraint clearly instead of guessing.
3. If the reproduction path is straightforward, launch one Oz cloud agent with computer use.
4. If there are multiple plausible repro paths, launch several Oz cloud agents in one `run_agents` batch. Give each child a distinct hypothesis or environment variant, such as:
   - different OS or desktop environment
   - fresh first-run state vs an already-initialized local state
   - stable vs dev build
   - fresh settings vs existing settings
   - different shells, prompts, pane layouts, or settings toggles
5. If steps are incomplete, use codebase knowledge to propose likely app states and assign children to investigate those states. Do not invent facts about the original reporter's environment.
6. Wait for all children to report before summarizing. Distinguish confirmed reproduction, partial reproduction, non-reproduction, blockers, and untested hypotheses.

## Version and app setup

- Prefer reproducing against the exact app version/build/channel reported by the user when a suitable runnable artifact exists.
- Do not silently substitute the latest available build when a closer reporter-matched artifact can be installed.
- Prefer a released or packaged runnable artifact over a source build when that better matches the reporter's environment and the repository-specific guidance allows it.
- If the exact version/build cannot be found or installed, report that clearly, explain what was attempted, and use the closest justified fallback only when it is useful for continuing the investigation.
- Record the requested reporter version, the installed test version, the artifact source, and any fallback decision in the manifest and final report.

## Repository-specific guidance

The consuming repository may ship a companion `reproduce-bug-report-local` skill. When that companion is available or referenced in the prompt, read it and apply its repository-specific scope, app setup, environment, and workflow guidance as supplemental instructions. The local companion may narrow scope or specialize setup, but it should not redefine the evidence, artifact, reporting, or safety expectations in this core skill.

Use a `run_agents` call shaped like this:

```text
summary: Launching O