reproduce-bug-report

バグ報告の再現

現在のコンテキストが、GitHub の Issue、サポートレポート、Linear のチケット、または画面上のアプリの動作を通じて再現できる可能性がある特定のバグを説明するユーザープロンプトである場合に、このスキルを使用してください。主な対象は、画面録画（またはスクリーンショット）によって問題をより具体的に示せる、UI、描画、ウィンドウ表示、設定、エディター、ターミナル表示、オンボーディング、その他のインタラクティブなバグです。

ユーザーから明示的に依頼されていない限り、親エージェントはローカルで UI バグを手動再現しようとしないでください。コンピューター操作を有効にした状態で、1 つ以上の Oz クラウドエージェントを起動し、該当アプリの実行、操作、視覚的な証拠の取得を行わせてください。

親エージェントのワークフロー

1. バグ報告を注意深く読み、次の情報を抽出します。
   • 報告された動作
   • 期待される動作
   • 再現手順（記載されている場合）
   • 関連する場合は、OS、アプリのバージョン／ビルド／チャンネル、シェル、機能フラグ、アカウントの状態、その他の環境上の制約
   • 再現経路を絞り込める添付スクリーンショット、動画、ログ、コメント
2. このスキルが適用されるか判断します。
   • UI で確認できるバグ、操作上のバグ、描画／レイアウトのバグ、オンボーディングのバグ、画面録画（またはスクリーンショット）が有用なバグには、このスキルを使用してください。
   • プロンプトで視覚的な再現が明示的に求められていない限り、バックエンド、CI、ビルド、依存関係、テキストのみのコードに関する問題には使用しないでください。
   • 報告の再現に認証情報、非公開のアカウント状態、または再現環境では利用できない別の機能が必要な場合は、推測せず、その制約を明確に報告してください。
3. 再現経路が明確な場合は、コンピューター操作を有効にした Oz クラウドエージェントを 1 つ起動します。
4. 再現経路が複数考えられる場合は、1 回の run_agents バッチで複数の Oz クラウドエージェントを起動します。次のように、それぞれに異なる仮説や環境の条件を割り当てます。
   • OS やデスクトップ環境の違い
   • 初回起動の新規状態と、初期化済みのローカル状態
   • Stable ビルドと Dev ビルド
   • 新規設定と既存設定
   • シェル、プロンプト、ペインの配置、設定切り替えの違い
5. 手順が不完全な場合は、コードベースの知識を活用して、あり得るアプリの状態を提案し、その調査を各子エージェントに割り当てます。元の報告者の環境について事実を捏造しないでください。
6. 要約する前に、すべての子エージェントからの報告を待ちます。再現を確認、部分的に再現、再現できず、阻害要因、未検証の仮説に区別してください。

バージョンとアプリのセットアップ

• 適切に実行できる成果物がある場合は、報告された正確なアプリのバージョン／ビルド／チャンネルでの再現を優先してください。
• 報告者により近い成果物をインストールできる場合、入手可能な最新ビルドに黙って置き換えないでください。
• リポジトリ固有のガイダンスで許可され、報告者の環境により近い場合は、ソースからのビルドより、リリース済みまたはパッケージ済みの実行可能な成果物を優先してください。
• 正確なバージョン／ビルドを見つけられない、またはインストールできない場合は、何を試したかを説明してその旨を明確に報告し、調査の継続に有用な場合に限り、妥当な範囲で最も近い代替手段を使用してください。
• 要求された報告者のバージョン、インストールしたテスト用バージョン、成果物の入手元、代替手段を選んだ場合はその判断を、マニフェストと最終レポートに記録してください。

リポジトリ固有のガイダンス

対象のリポジトリに関連スキル 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

同じ手順を繰り返すだけの子エージェントは追加しないでください。ユーザーから特定のモデルを指定されていない限り、model_id は省略してください。

子エージェント共通のプロンプト

すべての子エージェントに以下の共通指示を渡し、その後に子エージェント固有の再現経路または仮説を追加してください。

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>