reproduce-bug-report

复现 Bug 报告

当当前上下文是 GitHub issue、支持请求、Linear 工单，或描述了可通过可见应用行为复现的特定 Bug 的用户提示时，请使用此技能。此技能主要适用于 UI、渲染、窗口管理、设置、编辑器、终端显示、新手引导或其他交互类 Bug；录屏（或截图）能让结果更具可操作性。

除非用户明确要求，否则父 Agent 不应尝试在本地手动复现 UI Bug。请启动一个或多个启用了计算机操作功能的 Oz 云 Agent，让它们运行相关应用、进行交互并采集可视证据。

父 Agent 工作流

1. 仔细阅读 Bug 报告并提取以下信息：
   • 报告中描述的行为
   • 预期行为
   • 复现步骤（如有提供）
   • 相关的操作系统、应用版本/构建版本/发布渠道、Shell、功能标志、账户状态或其他环境限制
   • 有助于缩小复现路径的附件截图、视频、日志或评论
2. 判断此技能是否适用：
   • 适用于 UI 可见 Bug、交互 Bug、渲染/布局 Bug、新手引导 Bug，以及录屏（或截图）会有帮助的 Bug。
   • 不适用于纯后端、CI、构建、依赖项或纯文本代码问题，除非提示特别要求进行可视化复现。
   • 如果报告要求使用复现环境无法提供的凭据、私有账户状态或其他能力，请明确说明此限制，不要猜测。
3. 如果复现路径明确，启动一个启用了计算机操作功能的 Oz 云 Agent。
4. 如果存在多条合理的复现路径，请在一次 run_agents 批处理中启动多个 Oz 云 Agent。为每个 Agent 指定不同的假设或环境变体，例如：
   • 不同的操作系统或桌面环境
   • 全新首次运行状态 vs 已初始化的本地状态
   • 稳定版 vs 开发版构建
   • 全新设置 vs 现有设置
   • 不同的 Shell、提示词、窗格布局或设置开关
5. 如果步骤不完整，请利用代码库知识提出可能的应用状态，并指派子 Agent 调查这些状态。不要编造报告者原本使用环境的事实。
6. 等待所有子 Agent 汇报后再进行总结。区分已确认复现、部分复现、未复现、阻碍因素和未经测试的假设。

版本与应用设置

• 如果有合适且可运行的构件，优先使用与用户报告的应用版本/构建版本/发布渠道完全一致的版本进行复现。
• 如果能安装更接近报告者环境的构件，不要悄然改用最新的可用构建版本。
• 如果已发布或打包的可运行构件更符合报告者的环境，且仓库特定指南允许使用，则优先使用该构件，而非从源码构建。
• 如果无法找到或安装确切的版本/构建版本，请明确说明，解释已尝试的操作；仅在有助于继续调查时，才使用最接近且有充分依据的替代版本。
• 请在清单和最终报告中记录用户要求的版本、已安装的测试版本、构件来源以及任何回退决策。

仓库特定指南

使用此技能的仓库可能附带 reproduce-bug-report-local 技能。若有此配套技能或提示中提及，请阅读并将其仓库特定的范围、应用设置、环境和工作流指南作为补充指令。配套技能可缩小范围或细化设置，但不应重新定义此核心技能对证据、构件、报告或安全性的要求。

使用如下形式调用 run_agents：

summary: Launching Oz cloud computer-use agents to reproduce the reported UI bug and capture a screen recording.
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 会重复相同步骤，则省略。除非用户指定特定模型，否则省略 model_id。

共享子 Agent 提示词

向每个子 Agent 提供以下共享指令，然后追加该子 Agent 特定的复现路径或假设。

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 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 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 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.

成功标准

成功使用此技能后，应产生：

• 已确认的复现，附有屏幕录制（以及适用时的截图）和准确步骤；或者范围明确的未复现结果，并列出经过测试的假设。
• 清晰的可视证据文件路径或附件。
• 简洁总结已测试和未测试的变体。
• 足够的环境详情，以便工程师重复测试。
• 不泄露机密、凭据、私人账户详情或不必要的公开评论。

总结格式

子任务完成后，请按以下结构总结：

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>