Back to Details

reproduce-bug-report

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Reproduce bug report

重现Bug报告

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.
当当前上下文为GitHub issue、支持报告、Linear工单或描述了可通过应用可见行为重现的特定Bug的用户请求时，使用此Skill。它主要适用于UI、渲染、窗口、设置、编辑器、终端显示、新手引导或其他可通过截图/录屏让结果更具可操作性的交互类Bug。
父Agent不应尝试在本地手动重现UI Bug，除非用户明确要求。启动一个或多个启用计算机使用权限的Oz云Agent，使其运行相关应用、与之交互并捕获可视化证据。

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.
  1. 仔细阅读Bug报告并提取以下信息：
    • 报告的行为
    • 预期行为
    • 若有提供，重现步骤
    • 相关的操作系统、应用版本/构建/渠道、Shell、功能标志、账户状态或其他环境约束
    • 可缩小重现路径范围的附加截图、视频、日志或评论
  2. 判断是否适用此Skill：
    • 适用于UI可见Bug、交互Bug、渲染/布局Bug、新手引导Bug，以及截图证据能发挥作用的Bug。
    • 除非请求明确要求可视化重现，否则不适用于纯后端、CI、构建、依赖或纯文本代码问题。
    • 若报告需要凭据、私有账户状态或重现环境不具备的其他能力，应清晰报告该约束，而非猜测。
  3. 若重现路径清晰，启动一个启用计算机使用权限的Oz云Agent。
  4. 若存在多种合理的重现路径，在一个
    run_agents
    批次中启动多个Oz云Agent。为每个子Agent分配不同的假设或环境变体，例如：
    • 不同的操作系统或桌面环境
    • 全新首次运行状态 vs 已初始化的本地状态
    • 稳定版 vs 开发版构建
    • 全新设置 vs 现有设置
    • 不同的Shell、提示符、面板布局或设置开关
  5. 若步骤不完整，利用代码库知识提出可能的应用状态，并分配子Agent调查这些状态。不得编造原报告者环境的相关事实。
  6. 等待所有子Agent汇报后再进行总结。区分已确认重现、部分重现、未重现、阻塞点和未测试的假设。

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 collect screenshots.
remote.computer_use_enabled: true
agent_run_configs:
- name: "repro-primary"
  prompt: the primary repro prompt
- name: "repro-variant"
  prompt: optional variant prompt when useful
base_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.
使用此Skill的仓库可能附带
reproduce-bug-report-local
Skill。当该配套Skill可用或在请求中被引用时，阅读并应用其仓库特定的范围、应用设置、环境和工作流指南作为补充说明。本地配套Skill可能缩小范围或专门化设置，但不得重新定义此核心Skill中的证据、制品、报告或安全预期。
使用如下格式的
run_agents
调用：
text
summary: Launching Oz cloud computer-use agents to reproduce the reported UI bug and collect screenshots.
remote.computer_use_enabled: true
agent_run_configs:
- name: "repro-primary"
  prompt: the primary repro prompt
- name: "repro-variant"
  prompt: optional variant prompt when useful
base_prompt: the shared child prompt below
当子Agent步骤重复时，省略多余的子Agent。除非用户请求特定模型，否则省略
model_id
。

Shared child prompt

共享子Agent提示词

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 screenshots before and after each meaningful interaction.
- 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, or refresh tokens in 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, Slack, or external services unless explicitly instructed.
- 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`.
- Save screenshots 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:
  - 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. Capture the 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.
- Screenshot list 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.
为每个子Agent提供以下共享指令，然后附加子Agent特定的重现路径或假设。
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 screenshots before and after each meaningful interaction.
- 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, or refresh tokens in 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, Slack, or external services unless explicitly instructed.
- 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`.
- Save screenshots 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:
  - 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. Capture the 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.
- Screenshot list 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

子Agent提示词模板

Primary repro child

主重现子Agent

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.
适用于步骤清晰的报告：
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.

Variant child

变体子Agent

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.
适用于存在值得测试的特定替代条件的场景：
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.

Code-path hypothesis child

代码路径假设子Agent

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.
适用于重现步骤缺失或模糊的场景：
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.

Success criteria

成功标准

A successful use of this skill produces:
  • A confirmed reproduction with screenshots 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.
成功使用此Skill需达成以下结果：
  • 附带截图和精确步骤的已确认重现，或具备已测试假设的范围明确的未重现结果。
  • 可视化证据的清晰制品路径或附件。
  • 简明总结已测试和未测试的变体。
  • 足够的环境细节，供工程师重复测试。
  • 无泄露的密钥、凭据、私有账户信息或不必要的公开评论。

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>
子Agent完成后，按以下结构总结：
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>