mcpField
F
fusion-skill-self-report-bug

fusion-skill-self-report-bug

github.com/equinorエージェントワークフロー770 回インストール
リポジトリ

fusion-skill-self-report-bug について

Fusionスキルのワークフロー失敗をトリアージ用の不具合草案にまとめる非推奨スキルです。公開には明示的な確認を求め、現在は `fusion-skills` の `warden` エージェントに置き換えられています。

主な機能

  1. 01コマンド、環境、エラーの証拠を収集
  2. 02再現手順と影響を整理
  3. 03まず `.tmp/` に草案を作成
  4. 04課題種別、ラベル、担当者を提案
  5. 05公開前に明示的な確認を要求

活用シーン

  1. 01失敗したFusionスキル実行の不具合草案作成
  2. 02トリアージ用の自動化失敗の記録

MCP 対応

明示的な確認後にMCP経由で課題を作成・変更できます。確認がなければGitHubの状態は変更しません。

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/equinor/fusion-skills --skill fusion-skill-self-report-bug

インストール後、Claude Code で/fusion-skill-self-report-bugを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

CHANGELOG.md
assets/
README.md
assets/issue-templates/
skill-workflow-failure-bug.md

詳細

2026-03-21 に非推奨となりました。 このスキルは fusion-skills の warden エージェントに置き換えられました。このエージェントにはバグ報告ワークフロー全体が組み込まれており、フラストレーションの兆候の事前検出とスキルの問題点の検査機能も追加されています。代わりに fusion-skills を使用してください。

インストール：npx -y skills add equinor/fusion-skills fusion-skills

Fusion スキルのバグを自己報告する

使用するタイミング

Fusion スキルのワークフローが失敗し、一貫性があり、トリアージですぐに使えるバグ報告の草案が必要な場合に、このスキルを使用してください。 fusion-* スキルの実行が失敗した場合は、これをデフォルトの失敗引き継ぎ方法として扱ってください。

典型的なきっかけ：

  • 「fusion-* スキルが失敗した」
  • 「このスキルの実行に失敗した」
  • 「このスキルのエラーを自己報告して」
  • 「このワークフローの失敗からバグを起票して」
  • 「この自動化の失敗をトリアージ用に記録して」

使用しないタイミング

次の目的では、このスキルを使用しないでください：

  • 機能リクエストやロードマップの計画
  • 失敗が確認されていない一般的な実装タスク
  • ユーザーの明示的な確認なしに GitHub の変更を公開すること

必須入力

草案を作成する前に、次の情報を収集してください：

  • バグ報告の対象リポジトリ（デフォルト：equinor/fusion-skills）
  • 失敗したコマンドまたはワークフローの手順
  • 環境のコンテキスト（利用可能な場合は OS／シェル／ランタイム／ツールのバージョン）
  • 観測された出力やエラーの証拠
  • 再現に関する情報（正確な手順、または可能な範囲でのメモ）
  • リンク用の親 issue 番号（任意）

手順

  1. 失敗の意図を検出または確認します。
    • 失敗のコンテキストが不足している場合は、使用したコマンド、期待される動作、実際の動作、主なエラー出力を尋ねます。
  2. 失敗のコンテキストを記録します。
    • コンテキストを、コマンド、環境、観測されたエラー／出力、再現性、影響に整理します。
  3. まずローカルで草案を作成します。
    • assets/issue-templates/skill-workflow-failure-bug.md を使用して .tmp/BUG-skill-failure-<context>.md を作成します。
    • 再現手順と、観測された動作／期待される動作を明記します。
  4. issue のメタデータを提案します。
    • issue の種類として Bug を推奨します。
    • 信頼性／自動化のトリアージ用ラベル（例：bug、automation、reliability）を提案し、変更を行う前に対象リポジトリでラベルを確認します。
    • 担当者の希望（@me、特定のユーザー、または未割り当て）を尋ねます。
  5. 任意の関連付けを提案します。
    • 親 issue が指定されている場合は、issue 作成後に新しいバグをサブ issue としてリンクする準備をします。
  6. 公開について明示的な確認を求めます。
    • ユーザーが公開を明示的に確認するまで、GitHub の変更操作を実行しないでください。
  7. 確認後にのみ変更を行います。
    • MCP の issue 変更機能を使用して issue を作成します。
    • ラベル／担当者を設定します。
    • 親 issue が指定されている場合は、サブ issue としてリンクします。
  8. 確認が得られない場合は、草案の作成後に停止します。
    • ステータス No GitHub state changes made を返します。

期待される出力

次を返します：

  • .tmp/ 配下のバグ報告草案ファイルのパス
  • 記録した失敗コンテキストの概要（コマンド、環境、観測された出力）
  • 提案するタイトル／本文と再現手順
  • 提案する issue の種類、ラベル、担当者の方針
  • 親 issue へのリンク計画（任意）
  • 明示的なステータス：Awaiting publish confirmation または No GitHub state changes made
  • 確認後に変更を行った場合のみ、作成した issue の URL／番号

安全性と制約

次のことは決して行わないでください：

  • 明示的な確認なしに GitHub の作成／編集／コメント／クローズ操作を実行する
  • 提供または観測されていない失敗の証拠を主張する
  • シークレットや認証情報を要求または公開する

必ず次を守ってください：

  • まず草案を作成する
  • 長い説明より、必要最小限の再現可能な情報を優先する
  • 適用する前に、対象リポジトリにラベルが存在することを確認する

コメント

Markdown 対応