Reproduce Bug Report

by warpdotdev2a03b403b4f8No licenseListed Oct 8, 2026Updated Oct 8, 2026

Launch Oz cloud agents with computer use to reproduce UI-focused bug reports, capture visual evidence (a screen recording by default), and report reproduction findings. Use when investigating a specific interactive or visual bug from an issue, ticket, support report, or prompt.

Instructions onlySoftware Development

AI-generated overview

Launches cloud computer-use agents to reproduce UI bug reports and capture screen recordings as evidence.

What it does: This skill guides a parent agent through reproducing UI-focused bug reports by launching one or more Oz cloud agents with computer use enabled. It defines a shared child prompt covering safety, artifact capture, and reproduction workflow, and produces screen recordings, supplementary screenshots, a manifest, and a structured summary of reproduction status. It also covers version matching, variant testing, and code-path investigation when steps are unclear.
When to use it: Use it when investigating a specific interactive or visual bug from a GitHub issue, support report, Linear ticket, or prompt where visible application behavior matters. It suits UI, rendering, windowing, settings, editor, terminal-display, or onboarding bugs where a recording or screenshots make the result actionable. It is not intended for purely backend, CI, build, dependency, or text-only code issues.
Requirements: Requires the ability to launch Oz cloud agents with computer use enabled via a run_agents call, plus a runnable app artifact matching the reported version when available. No scripts ship with the skill; it is instructions only. It may reference a companion reproduce-bug-report-local skill in the consuming repository.

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 a screen recording (or screenshots) makes 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

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
Decide whether this skill applies:
- Use it for UI-visible bugs, interaction bugs, rendering/layout bugs, onboarding bugs, and bugs where a screen recording (or screenshots) 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.
If the reproduction path is straightforward, launch one Oz cloud agent with computer use.
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
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.
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 Oz cloud computer-use agents to reproduce the reported UI bug and capture a screen recording.remote.computer_use_enabled: trueagent_run_configs:- name: "repro-primary"  prompt: the primary repro prompt- name: "repro-variant"  prompt: optional variant prompt when usefulbase_prompt: the shared child prompt below

summary: Launching Oz cloud computer-use agents to reproduce the reported UI bug and capture a screen recording.remote.computer_use_enabled: trueagent_run_configs:- name: "repro-primary"  prompt: the primary repro prompt- name: "repro-variant"  prompt: optional variant prompt when usefulbase_prompt: the shared child prompt below

Omit extra children when they would duplicate the same steps. Omit model_id unless the user requested a specific model.

Shared child prompt

Give every child agent these shared instructions, then append the child-specific repro path or hypothesis.

text

You are trying to reproduce a reported UI bug using Oz cloud computer use.
Goal:- Reproduce the reported behavior as faithfully as possible.- Capture a screen recording of the reproduction by default; most UI bugs involve motion, a transition, or a multi-step interaction, so a clip is stronger proof than stills. Capture screenshots as a supplement, or as the primary artifact only for a genuinely static render.- If the provided steps are unclear or incomplete, use codebase and product knowledge to identify plausible app states that could produce the reported behavior, then test the assigned hypothesis.- Report clear reproduction evidence, not just opinions.
Inputs:- Bug report context: <paste or summarize the issue body, comments, screenshots/video descriptions, labels, and relevant metadata>- Assigned repro path or hypothesis: <specific steps, environment, app state, settings, feature flags, or code path to test>- Reporter app version/build/channel: <exact value from the report, or unknown>- Build/app target: <exact runnable artifact to install, or the justified fallback if exact artifact is unavailable>
Safety and privacy:- Do not ask the public reporter for credentials, tokens, private repos, private workspace names, or private account identifiers.- Do not include secrets, auth tokens, private URLs, Authorization headers, refresh tokens, or other private account details in recordings, screenshots, logs, manifests, or final reports.- Do not create or sign into an account unless the prompt and repository-specific guidance explicitly authorize a safe test-auth workflow.- If the assigned report cannot be exercised within the allowed auth/state constraints, stop and report the blocker.- Do not post comments to GitHub, Linear, or external services unless explicitly instructed. When a Slack thread context is provided (a channel id and thread), post the reproduction proof (the recording) back to that thread so the requester sees it; do not post to any other channel or service.- Avoid destructive actions. If a repro requires deleting app state, delete only test state for the current repro environment and report exactly what was reset.
Artifact workflow:- Create a dedicated artifact directory named for your variant, such as `~/bug-repro-primary`.- Record a screen recording of the reproduction by default and save it in the artifact directory with a descriptive name such as `repro.mp4`.- Capture screenshots as a supplement (or as the primary artifact only for a genuinely static render) with ordered filenames, such as `01-initial-state.png`, `02-before-click-settings.png`, and `03-after-click-settings.png`.- Maintain a short manifest in the artifact directory with:  - recording or screenshot filename  - timestamp  - visible app state  - action just taken or about to be taken  - whether the screenshot shows the reported bug- If the harness supports built-in screenshot or artifact upload, use it. Otherwise leave artifacts in the directory and report the paths.
Reproduction workflow:1. Confirm the environment you are testing: OS, architecture, display/session type, shell if relevant, and app/build/version if visible.2. Identify the exact reporter app version/build/channel from the report when available, then use the closest repository-approved runnable artifact.3. If no exact reporter version is available, record that the version is unknown and choose the most defensible install target for the report; state the fallback explicitly.4. Start from the cleanest state that matches the report. Do not reset app state if the bug depends on existing settings or persisted local state.5. Reach the baseline app state required by the report before attempting the bug-specific reproduction.6. Start the screen recording and capture a baseline screenshot before attempting the bug-specific reproduction.7. Follow the exact provided bug reproduction steps first, when available.8. If exact steps do not reproduce, test the assigned hypothesis and document where it diverges from the report.9. If the bug appears, stop changing variables and capture enough evidence to make the reproduction actionable.10. If the bug does not appear, make at most two targeted variations that are directly supported by the report or code-path hypothesis.11. If the app crashes, hangs, or blocks progress, capture a screenshot and collect non-sensitive logs or terminal output that explain the blocker.
Code-path investigation for unclear steps:- Search the codebase for UI strings, labels, feature names, settings keys, telemetry names, route names, and components mentioned in the report.- Identify the likely component, model, feature flag, or state transition that could produce the reported behavior.- Use that investigation to choose targeted UI actions rather than broad exploratory clicking.- Report the files or symbols that informed your hypothesis, but keep the final report focused on reproduction evidence.
Report back:- A brief bug summary before the verdict, including the issue/report identifier if available, the reported behavior, and the expected behavior.- Reproduction status: confirmed, partially confirmed, not reproduced, or blocked.- The exact steps you performed.- Environment and app/build information.- Reporter-requested app version/build/channel, installed test version/build/channel, and the artifact source or fallback explanation.- Whether the observed behavior matched the report, and how closely.- The screen recording (and any supplementary screenshots) with short descriptions and artifact paths or attachment names.- Any logs, crash output, or diagnostics collected, with secrets redacted.- The most likely code path or state involved, if investigated.- Suggested next debugging step or follow-up question, only if it would materially change the next action.

You are trying to reproduce a reported UI bug using Oz cloud computer use.
Goal:- Reproduce the reported behavior as faithfully as possible.- Capture a screen recording of the reproduction by default; most UI bugs involve motion, a transition, or a multi-step interaction, so a clip is stronger proof than stills. Capture screenshots as a supplement, or as the primary artifact only for a genuinely static render.- If the provided steps are unclear or incomplete, use codebase and product knowledge to identify plausible app states that could produce the reported behavior, then test the assigned hypothesis.- Report clear reproduction evidence, not just opinions.
Inputs:- Bug report context: <paste or summarize the issue body, comments, screenshots/video descriptions, labels, and relevant metadata>- Assigned repro path or hypothesis: <specific steps, environment, app state, settings, feature flags, or code path to test>- Reporter app version/build/channel: <exact value from the report, or unknown>- Build/app target: <exact runnable artifact to install, or the justified fallback if exact artifact is unavailable>
Safety and privacy:- Do not ask the public reporter for credentials, tokens, private repos, private workspace names, or private account identifiers.- Do not include secrets, auth tokens, private URLs, Authorization headers, refresh tokens, or other private account details in recordings, screenshots, logs, manifests, or final reports.- Do not create or sign into an account unless the prompt and repository-specific guidance explicitly authorize a safe test-auth workflow.- If the assigned report cannot be exercised within the allowed auth/state constraints, stop and report the blocker.- Do not post comments to GitHub, Linear, or external services unless explicitly instructed. When a Slack thread context is provided (a channel id and thread), post the reproduction proof (the recording) back to that thread so the requester sees it; do not post to any other channel or service.- Avoid destructive actions. If a repro requires deleting app state, delete only test state for the current repro environment and report exactly what was reset.
Artifact workflow:- Create a dedicated artifact directory named for your variant, such as `~/bug-repro-primary`.- Record a screen recording of the reproduction by default and save it in the artifact directory with a descriptive name such as `repro.mp4`.- Capture screenshots as a supplement (or as the primary artifact only for a genuinely static render) with ordered filenames, such as `01-initial-state.png`, `02-before-click-settings.png`, and `03-after-click-settings.png`.- Maintain a short manifest in the artifact directory with:  - recording or screenshot filename  - timestamp  - visible app state  - action just taken or about to be taken  - whether the screenshot shows the reported bug- If the harness supports built-in screenshot or artifact upload, use it. Otherwise leave artifacts in the directory and report the paths.
Reproduction workflow:1. Confirm the environment you are testing: OS, architecture, display/session type, shell if relevant, and app/build/version if visible.2. Identify the exact reporter app version/build/channel from the report when available, then use the closest repository-approved runnable artifact.3. If no exact reporter version is available, record that the version is unknown and choose the most defensible install target for the report; state the fallback explicitly.4. Start from the cleanest state that matches the report. Do not reset app state if the bug depends on existing settings or persisted local state.5. Reach the baseline app state required by the report before attempting the bug-specific reproduction.6. Start the screen recording and capture a baseline screenshot before attempting the bug-specific reproduction.7. Follow the exact provided bug reproduction steps first, when available.8. If exact steps do not reproduce, test the assigned hypothesis and document where it diverges from the report.9. If the bug appears, stop changing variables and capture enough evidence to make the reproduction actionable.10. If the bug does not appear, make at most two targeted variations that are directly supported by the report or code-path hypothesis.11. If the app crashes, hangs, or blocks progress, capture a screenshot and collect non-sensitive logs or terminal output that explain the blocker.
Code-path investigation for unclear steps:- Search the codebase for UI strings, labels, feature names, settings keys, telemetry names, route names, and components mentioned in the report.- Identify the likely component, model, feature flag, or state transition that could produce the reported behavior.- Use that investigation to choose targeted UI actions rather than broad exploratory clicking.- Report the files or symbols that informed your hypothesis, but keep the final report focused on reproduction evidence.
Report back:- A brief bug summary before the verdict, including the issue/report identifier if available, the reported behavior, and the expected behavior.- Reproduction status: confirmed, partially confirmed, not reproduced, or blocked.- The exact steps you performed.- Environment and app/build information.- Reporter-requested app version/build/channel, installed test version/build/channel, and the artifact source or fallback explanation.- Whether the observed behavior matched the report, and how closely.- The screen recording (and any supplementary screenshots) with short descriptions and artifact paths or attachment names.- Any logs, crash output, or diagnostics collected, with secrets redacted.- The most likely code path or state involved, if investigated.- Suggested next debugging step or follow-up question, only if it would materially change the next action.

Child prompt patterns

Primary repro child

Use this for a report with clear steps:

text

You own the primary reproduction attempt.
Follow the bug report's steps exactly before trying variants. Prioritize matching the reporter's OS, app channel, allowed app state, settings, shell, and layout. If those details are missing, choose the most common path and explicitly list assumptions.

You own the primary reproduction attempt.
Follow the bug report's steps exactly before trying variants. Prioritize matching the reporter's OS, app channel, allowed app state, settings, shell, and layout. If those details are missing, choose the most common path and explicitly list assumptions.

Variant child

Use this when there is a specific alternate condition worth testing:

text

You own this reproduction variant: <variant name>.
Test only this variant's assigned environment or state. Do not duplicate the primary child's full search space. Report whether this variant changes the outcome and include screenshots for any difference.

You own this reproduction variant: <variant name>.
Test only this variant's assigned environment or state. Do not duplicate the primary child's full search space. Report whether this variant changes the outcome and include screenshots for any difference.

Code-path hypothesis child

Use this when repro steps are missing or ambiguous:

text

You own code-path-guided reproduction.
Start by tracing likely code paths from strings, UI labels, settings names, feature names, or screenshots in the report. Then choose a targeted UI path that should exercise the suspected state. Report the code paths you used to form the hypothesis and the visual result of testing it.

You own code-path-guided reproduction.
Start by tracing likely code paths from strings, UI labels, settings names, feature names, or screenshots in the report. Then choose a targeted UI path that should exercise the suspected state. Report the code paths you used to form the hypothesis and the visual result of testing it.

Success criteria

A successful use of this skill produces:

A confirmed reproduction with a screen recording (and screenshots where useful) and exact steps, or a well-scoped non-reproduction with tested assumptions.
Clear artifact paths or attachments for visual evidence.
A concise summary of which variants were tested and which were not.
Enough environment detail for an engineer to repeat the test.
No leaked secrets, credentials, private account details, or unnecessary public comments.

Summary format

When the children finish, summarize in this structure:

text

Bug summary:- Issue/report: <identifier or source>- Reported behavior: <what bug the child attempted to reproduce>- Expected behavior: <what should have happened instead>Reproduction status: <confirmed | partially confirmed | not reproduced | blocked>
What was tested:- <variant/child>: <steps and environment>
Evidence:- <screenshot/artifact path>: <what it shows>
Findings:- <observed behavior vs reported behavior>- <likely state/code path, if known>
Next step:- <one concrete debugging action or follow-up question>

Bug summary:- Issue/report: <identifier or source>- Reported behavior: <what bug the child attempted to reproduce>- Expected behavior: <what should have happened instead>Reproduction status: <confirmed | partially confirmed | not reproduced | blocked>
What was tested:- <variant/child>: <steps and environment>
Evidence:- <screenshot/artifact path>: <what it shows>
Findings:- <observed behavior vs reported behavior>- <likely state/code path, if known>
Next step:- <one concrete debugging action or follow-up question>

Source and attribution

Source:warpdotdev/common-skillsin.agents/skills/reproduce-bug-reportat commit2a03b40

License: No license

Content belongs to its original authors. SourceWeft indexes it from a public repository.

Report or request removal

More from warpdotdev/common-skills

Write Tech Spec

warpdotdev

Writes a TECH.md technical spec for a significant feature, grounded in codebase research and implementation constraints.

Software DevelopmentOct 8, 2026

Write Product Spec

warpdotdev

Writes a PRODUCT.md product spec describing user-facing feature behavior as numbered, testable invariants.

Writing & ContentOct 8, 2026

Write Pr Description

warpdotdev

Writes the body of a pull request - the summary, the repository template sections, and reviewer guidance such as a recommended reading order and focus areas. Use whenever drafting or revising a PR description, filling in a repository's PR template, refreshing a description that no longer matches the branch, or preparing a branch for review. Use it even when the user only says "open a PR", "put this up for review", or "write this up" without naming the description.

Awaiting classificationOct 8, 2026

Write Feature Docs

warpdotdev

Drafts a first-pass MDX documentation page for a new Warp feature from its spec, then opens a draft PR in the docs repo.

Writing & ContentOct 8, 2026

Validate Changes Match Specs

warpdotdev

Validates that a branch or pull request implementation matches its checked-in product, technical, and security specs.

Software DevelopmentOct 8, 2026

Spec Driven Implementation

warpdotdev

Guides a spec-first workflow for substantial features, writing PRODUCT.md and TECH.md before implementation and keeping them current.

Software DevelopmentOct 8, 2026

Reproduce Bug Report

Reproduce bug report

Parent workflow

Version and app setup

Repository-specific guidance

Shared child prompt

Child prompt patterns

Primary repro child

Variant child

Code-path hypothesis child

Success criteria

Summary format

Source and attribution

More from warpdotdev/common-skills

Write Tech Spec

Write Product Spec

Write Pr Description

Write Feature Docs

Validate Changes Match Specs

Spec Driven Implementation

More in Software Development

Playground

M5 Onboard

Cardputer Buddy

Dpop Adoption

Gemini Live Api

Gemini Api