scenario-report について
scenario-reportは、Scenarioの不具合報告や変更リクエストを作成する手順をまとめたスキルです。問題を報告する人向けに、再現可能な証拠の収集、機密情報の削除、重複確認、公開前の承認を重視しています。
主な機能
- 01不具合と変更リクエストの分類
- 02呼び出し・エラー・診断情報の収集
- 03アカウント情報などの秘匿
- 04重複報告の検索
- 05再現可能な報告内容の作成
- 06公開前の承認取得
活用シーン
- 01再現可能なモデル実行の失敗を報告
- 02Scenarioの機能変更を提案
- 03アカウントや請求の問題を非公開で相談
MCP 対応
このスキルは`diagnostics_run`、`search`、`model_run`などScenarioのワークフローやツールを使い、報告用の証拠を集めます。GitHubへの公開報告と非公開のサポート窓口を説明しますが、MCPサーバーは提供しません。
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/インストール後、Claude Code で/scenario-reportを入力して読み込まれたか確認します。
詳細
Scenario のバグと変更リクエストの報告
概要
公開トラッカー：https://github.com/scenario-labs/skills/issues、フォームは bug.yml と
change-request.yml です。非公開の代替手段として [email protected] を提示し、ユーザーに
選んでもらいます。
制約が2つあります。公開された issue は削除できないため、まず機密情報を削除し、ユーザーが正確な文面を 承認してから投稿します。読み手はユーザーのアカウントにアクセスできないため、外部から再現するのに 必要な情報をすべてレポートに含める必要があります。
接続と生成の基本的なループについては、このリポジトリの scenario スキルを参照してください。ここに
記載されている兄弟スキルが利用可能なスキルにない場合は、ユーザーにインストールを依頼してください
（npx skills add scenario-labs/skills --skill <name>）。無人で進める場合は、ツールのスキーマに基づいて
作業し、不足しているスキルがあることを明記してください。
アカウント、請求、クレジット、クォータ、サインイン、セキュリティに関する問題は、公開 issue に
投稿しないでください。[email protected] またはアプリ内サポート（app.scenario.com）に
問い合わせてもらいます。
クイックリファレンス
| 手順 | 実施内容 |
|---|---|
| 分類 | バグまたは変更リクエストに分類し、1件につき1つの問題を扱います |
| 情報収集 | 失敗した呼び出し、エラーの原文、そのセッションの diagnostics_run を取得します |
| 機密情報の削除 | 個人情報とシークレットを削除します。チーム ID やプロジェクト ID は事前に確認します |
| 重複確認 | オープンとクローズ済みの issue を検索し、一致するものがあればコメントします |
| 下書き | すべてのフィールドに記入し、推測は推測と明記します |
| 承認 | 最終文面を提示し、はいと返答された場合のみ投稿します |
| 投稿 | GitHub ツール、入力済み URL、またはメールを使います |
下書きの前に機密情報を削除する
API キーやトークン、asset_download の署名付き URL（認証情報です）、アカウントのメールアドレスや名前、
ユーザー名を含むローカルパス、ユーザーが公開に同意していない未公開のアート、プロンプト、モデル名は
絶対に含めないでください。
チーム ID とプロジェクト ID はアカウントを特定できるため、デフォルトでは削除します。診断に影響する 場合（Forbidden またはスコープのエラー、1つのチームだけが閲覧できるモデルなど）に限り、ユーザーに 確認してください。投稿する ID を引用し、明確な「はい」以外はすべて「いいえ」として扱います。 その情報を伝えるにはメールがより適しています。
diagnostics_run は最も有力な証拠であると同時に、最も情報漏えいの危険が大きいものです。
self_test.detail にはユーザーが所属するすべてのチームやプロジェクトが列挙される場合があり、
tenant からアカウントを特定できる場合があります。そのレポートからコピーするのは、
version、endpoint、auth_type、self_test.layer、self_test.latencyMs、generated_at、
および confirmed_trace_ids と candidate_trace_ids の下にある ID だけにしてください。
レポートのその他の情報は一切含めないでください。
ジョブ、アセット、モデルの ID は、レポートをサーバー側のリクエストと照合するためのものです。 ユーザーの同意を得てから含めてください。署名付きダウンロード URL は絶対に含めないでください。
再現可能にする
モデル ID と、public=true を指定した search でそのモデルが見つかるかどうか、model_run に送信した
parameters の正確な内容、エラーの原文、UTC のタイムスタンプ、少なくとも1つのトレース ID を
記載してください。機密性の高いプロンプトは短い公開プロンプトに置き換え、その旨を明記します。
モデルがチーム限定公開の場合はその旨を記載し、読み手が公開相当モデルで再現できるようにします。
具体例：完了しないテクスチャのアップスケール
- 失敗したセッションで
diagnostics_runを実行し、上記のフィールドとトレース ID だけを残します。 - 失敗した呼び出しをもう一度実行します。引数、応答の原文、UTC の時刻を記録します。
searchで アップスケーラーが公開されているか確認し、読み手も実行できるようにします。次にトラッカーを オープンとクローズ済みの両方からjobs_wait pendingで検索します。 - 下書きを作成します。タイトル：
jobs_wait keeps returning the same texture upscale job in pending_job_ids for 20 minutes。 手順：引数を含めてmodel_schema_get、model_run、繰り返し実行したjobs_waitの各呼び出しを 記載します。期待される結果：ジョブが完了するか、失敗します。実際の結果：statusがin_progressのままで、pending_job_idsが変わりません。証拠：ジョブ ID、トレース ID、タイムスタンプ。 - 完全な文面をユーザーに提示し、はいと返答された場合のみ投稿します。
投稿
- GitHub ツールを使う場合：
repo:scenario-labs/skillsを検索して重複を確認してから、本文でフォームの見出しを踏襲し、bugまたはenhancementのラベルを付けて issue を作成します。 - ブラウザーのみの場合：
https://github.com/scenario-labs/skills/issues/new?template=bug.yml&summary=...&repro=...を組み立て、各値をパーセントエンコードします。パラメーター名はフォームのフィールド ID です：summary、area、repro、expected、actual、evidence、env、frequency。変更リクエストではtemplate=change-request.ymlに切り替え、problem、area、today、proposal、impactを使います（選択したフォームのフィールド ID と一致しないパラメーターは黙って破棄されます）。ユーザーが確認ボックスにチェックを入れて送信します。約 8000 文字を超えると URL は 414 を返すため、evidenceを削除します。 - メールの場合：
[email protected]宛てに、件名を[bug] <title>または[change request] <title>とし、同じフィールドをラベル付きの行で記載した本文を送ります。公開 issue では伏せたチーム ID、プロジェクト ID、アカウントのメールアドレスは、安全にここで送信できます。
よくある間違い
- チームとプロジェクトの一覧が漏れる
diagnostics_runの出力全体を貼り付ける。 - 求められていないチーム ID やプロジェクト ID を公開する、または診断に不要な ID を尋ねる。
- 「generation is broken」のようなタイトルにする：対象箇所、症状、発生条件を明記します。
- 1 つの issue に 3 つの問題をまとめる：それぞれに個別の再現手順とクローズが必要です。
- 観察内容ではなく仮説（「API が停止している」）を報告する。まず観察内容を示し、仮説は最後に仮説として明記します。