Back to Details

fusion-skill-self-report-bug

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Self-report Fusion Skill Bugs

自动上报Fusion Skill Bugs

When to use

使用场景

Use this skill when a Fusion skill workflow fails and you need a consistent, triage-ready bug report draft. Treat this as the default failure handoff for any 
fusion-*
skill execution.
Typical triggers:
  • "a fusion-* skill failed"
  • "this skill run failed"
  • "self-report this skill error"
  • "create a bug from this workflow failure"
  • "capture this automation failure for triage"
当Fusion skill工作流失败，且你需要一份一致的、可用于分类处理的bug报告草稿时，使用此技能。将其作为所有
fusion-*
技能执行失败后的默认故障交接方式。
典型触发词：
  • "fusion-*技能执行失败"
  • "此技能运行失败"
  • "自动上报此技能错误"
  • "从此工作流失败创建bug"
  • "捕获此自动化故障以供分类处理"

When not to use

不适用场景

Do not use this skill for:
  • Feature requests or roadmap planning
  • General implementation tasks without observed failure
  • Publishing GitHub changes without explicit user confirmation
请勿将此技能用于：
  • 功能请求或路线图规划
  • 未观测到失败的常规实现任务
  • 未获得用户明确确认的GitHub变更发布

Required inputs

必要输入

Collect before drafting:
  • Target repository for the bug report (default: 
    equinor/fusion-skills
    )
  • Failing command or workflow step
  • Environment context (OS/shell/runtime/tooling versions if available)
  • Observed output/error evidence
  • Reproduction signal (exact steps or best-effort notes)
  • Optional parent issue number for linking
在起草报告前需收集：
  • bug报告的目标仓库（默认：
    equinor/fusion-skills
    ）
  • 失败的命令或工作流步骤
  • 环境上下文（若有，包括操作系统/Shell/运行时/工具版本）
  • 观测到的输出/错误证据
  • 复现说明（精确步骤或尽力记录的笔记）
  • 可选的关联父议题编号

Instructions

操作步骤

  1. Detect or confirm failure intent.
    • If failure context is missing, ask for command used, expected behavior, actual behavior, and key error output.
  2. Capture failure context.
    • Normalize context into: command, environment, observed error/output, reproducibility, and impact.
  3. Draft locally first.
    • Write 
      .tmp/BUG-skill-failure-<context>.md
      using 
      assets/issue-templates/skill-workflow-failure-bug.md
      .
    • Include reproducible steps and explicit observed/expected behavior.
  4. Propose issue metadata.
    • Recommend issue type: 
      Bug
      .
    • Recommend labels for reliability/automation triage (for example 
      bug
      , 
      automation
      , 
      reliability
      ), then validate labels against the target repository before mutation.
    • Ask assignee preference (
      @me
      , specific user, or unassigned).
  5. Offer optional relationship linking.
    • If parent issue is provided, prepare to link the new bug as a sub-issue after issue creation.
  6. Ask explicit publish confirmation.
    • Do not run any GitHub mutation until the user explicitly confirms publish.
  7. Mutate only after confirmation.
    • Create issue via MCP issue mutation.
    • Apply labels/assignee.
    • If parent issue was provided, link as sub-issue.
  8. If confirmation is not provided, stop after draft.
    • Return status 
      No GitHub state changes made
      .
  1. 检测或确认故障上报意图。
    • 若缺失故障上下文，询问使用的命令、预期行为、实际行为以及关键错误输出。
  2. 捕获故障上下文。
    • 将上下文标准化为：命令、环境、观测到的错误/输出、可复现性以及影响。
  3. 先本地创建草稿。
    • 使用
      assets/issue-templates/skill-workflow-failure-bug.md
      模板，生成
      .tmp/BUG-skill-failure-<context>.md
      文件。
    • 包含可复现步骤以及明确的观测/预期行为。
  4. 提出议题元数据建议。
    • 建议议题类型：
      Bug
      。
    • 建议用于可靠性/自动化分类处理的标签（例如
      bug
      、
      automation
      、
      reliability
      ），在执行操作前需先验证这些标签在目标仓库中是否存在。
    • 询问负责人偏好（
      @me
      、特定用户或不指定负责人）。
  5. 提供可选的关联议题链接。
    • 若提供了父议题，准备在新bug议题创建后将其链接为子议题。
  6. 请求明确的发布确认。
    • 在用户明确确认发布前，不得对GitHub执行任何操作。
  7. 仅在确认后执行操作。
    • 通过MCP议题操作创建议题。
    • 应用标签/指定负责人。
    • 若提供了父议题，将其链接为子议题。
  8. 若未获得确认，在创建草稿后停止操作。
    • 返回状态：
      未对GitHub状态进行任何更改
      。

Expected output

预期输出

Return:
  • Draft bug report file path under 
    .tmp/
  • Captured failure-context summary (command, environment, observed output)
  • Proposed title/body and reproduction steps
  • Proposed issue type + labels + assignee plan
  • Optional parent issue linking plan
  • Explicit status: 
    Awaiting publish confirmation
    or 
    No GitHub state changes made
  • Created issue URL/number only after confirmed mutation
返回：
  • .tmp/
    目录下的草稿bug报告文件路径
  • 捕获的故障上下文摘要（命令、环境、观测到的输出）
  • 建议的标题/正文以及复现步骤
  • 建议的议题类型 + 标签 + 负责人方案
  • 可选的父议题链接方案
  • 明确状态：
    等待发布确认
    或
    未对GitHub状态进行任何更改
  • 仅在确认操作后返回创建的议题URL/编号

Safety & constraints

安全与约束

Never:
  • Perform GitHub create/edit/comment/close actions without explicit confirmation
  • Claim failure evidence that was not provided or observed
  • Request or expose secrets/credentials
Always:
  • Keep draft-first behavior
  • Prefer minimal reproducible detail over long narrative
  • Validate label existence in the target repository before applying
禁止：
  • 在未获得明确确认的情况下执行GitHub的创建/编辑/评论/关闭操作
  • 声称未提供或未观测到的故障证据
  • 请求或泄露机密/凭据
必须：
  • 坚持先创建草稿的行为
  • 优先选择最小可复现细节而非冗长描述
  • 在应用标签前验证目标仓库中是否存在该标签