关于 scenario-report
scenario-report 提供提交 Scenario 错误报告和变更请求的流程，面向需要反馈问题的用户。重点包括收集可复现证据、清除敏感信息、检查重复报告，以及公开发布前取得批准。
主要功能
- 01区分错误报告与变更请求
- 02收集调用、错误和诊断信息
- 03清除敏感账户数据
- 04搜索重复报告
- 05撰写可复现的问题详情
- 06公开发布前征求批准
适用场景
- 01报告可复现的模型运行故障
- 02提交 Scenario 功能变更请求
- 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] 作为私密替代方式，让用户自行选择。
有两点限制。公开问题一经发布便会永久保留，因此要先删除敏感信息，并且只有在用户批准确切文本后才能发布。 读者无法访问用户的账户，因此报告必须包含从外部复现问题所需的全部信息。
有关连接和核心生成循环，请参阅此仓库中的 scenario skill。如果此处提到的同级 skill 不在你可用的 skills
中，请让用户安装它（npx skills add scenario-labs/skills --skill <name>）；如果是无人值守的情况，则根据工具架构继续处理，并指出这一缺失。
账户、账单、额度、配额、登录和安全问题绝不能发布为公开问题：请发送至 [email protected]，或通过应用内支持联系，网址为 app.scenario.com。
快速参考
| 步骤 | 操作 |
|---|---|
| 分类 | 判定为错误或变更请求，每次只处理一个问题 |
| 收集 | 失败的调用、原样错误信息，以及该会话中的 diagnostics_run |
| 删除敏感信息 | 清除身份信息和机密；涉及团队或项目 ID 时先询问 |
| 查重 | 搜索未关闭和已关闭的问题；如有匹配项则发表评论 |
| 起草 | 填写所有字段，并将推测明确标注为推测 |
| 批准 | 展示最终文本，只有得到肯定答复后才发布 |
| 发布 | 使用 GitHub 工具、预填链接或电子邮件 |
起草前删除敏感信息
绝不能包含 API 密钥或令牌、来自 asset_download 的签名 URL（该 URL 是凭证）、账户邮箱或姓名、包含用户名的本地路径，或用户未同意公开的未发布美术作品、提示词和模型名称。
团队和项目 ID 可用于识别账户，因此默认应删除。只有在 ID 会影响诊断时（例如 Forbidden 或作用域错误，或只有一个团队能看到某个模型）才询问是否包含：告知用户你准备发布的 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，以及 search 能否通过 public=true 找到该模型、发送给 model_run 的确切 parameters、原样错误信息、UTC 时间戳和至少一个 trace ID。若用简短的公开提示词替代机密提示词，请注明这一点。若模型仅对团队可见，请说明读者应使用公开的同类模型进行复现。
示例：纹理放大任务一直无法完成
- 在失败的会话中运行
diagnostics_run，仅保留上文列出的字段和 trace 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、trace ID、时间戳。 - 向用户展示完整文本，只有得到肯定答复后才发布。
提交
- 使用 GitHub 工具时：搜索
repo:scenario-labs/skills，检查是否有重复问题，然后创建 issue，并添加bug或enhancement标签；正文中的标题应与表单标题一致。 - 仅使用浏览器时：构建
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 不匹配的参数会被静默丢弃）。用户勾选确认框并提交。URL 超过约 8000 个字符后会返回 414：请删除evidence。 - 通过电子邮件提交：发送至
[email protected]，主题为[bug] <title>或[change request] <title>，正文以带标签的行填写相同字段。任何未包含在公开 issue 中的信息（团队 ID、项目 ID、账号电子邮件）都可以安全地通过此方式发送。
常见错误
- 粘贴完整的
diagnostics_run输出，从而泄露团队和项目列表。 - 公开无人要求提供的团队或项目 ID，或索要诊断并不需要的 ID。
- 使用“生成功能坏了”之类的标题：应指出具体界面、症状和发生条件。
- 在一个 issue 中报告三个问题：每个问题都需要单独的复现步骤，并分别关闭。
- 报告假设（“API 已宕机”）而不是观察结果。先写观察结果，最后再写假设，并标明它是假设。