workflow-monitor

使用しない場合

• 直接デバッグする価値がある単発の失敗（superpowers:systematic-debugging を使用）
• ワークフローのアセットを書き換える場合（sanctum:workflow-improvement を使用）

ワークフローモニター

ワークフローの実行を監視して、エラーや非効率な点を検出し、検出した Git プラットフォーム（GitHub/GitLab）に改善のためのイシューを自動作成します。セッションのコンテキストで git_platform: を確認し、CLI コマンドの対応付けには Skill(leyline:git-platform) を使用します。

基本方針

ワークフローは時間とともに改善されるべきです。実行時の問題を体系的に記録することで、継続的な改善が可能になります。このスキルはワークフローの実行にフックし、問題を検出して修正案を提示します。

クイックスタート

手動での実行

# After a failed workflow
/workflow-monitor --analyze-last

# Monitor a specific workflow execution
/workflow-monitor --session <session-id>

# Analyze efficiency of recent workflows
/workflow-monitor --efficiency-report

自動監視（フック経由）

有効にすると、workflow-monitor は実行を監視し、次の問題にフラグを付けます。

• コマンドの失敗（終了コード > 0）
• タイムアウトイベント
• 繰り返される再試行パターン
• コンテキストの枯渇
• 非効率なツールの使用

検出パターン

エラーの検出

パターン	シグナル	重大度
コマンドの失敗	終了コード > 0	高
タイムアウト	タイムアウト制限を超過	高
再試行ループ	同じコマンドを 3 回超実行	中
コンテキストの枯渇	コンテキストの使用率 >90%	中
ツールの誤用	タスクに不適切なツール	低

効率の検出

パターン	シグナル	しきい値
冗長な出力	コマンドからの出力が 1000 行超	500 行を推奨
重複した読み込み	同じファイルを 2 回超読み込み	最大 2 回
逐次実行と並列実行	独立したタスクを逐次実行	並列化すべき
過剰な取得	スニペットが必要なのにファイル全体を読み込む	offset/limit を使用

ワークフロー

フェーズ 1：記録（workflow-monitor:capture-complete）

1. 実行イベントを記録 - コマンド、出力、タイミング
2. 異常にタグを付与 - 失敗、タイムアウト、非効率な点
3. 証拠を保存 - 再現性のため

フェーズ 2：分析（workflow-monitor:analysis-complete）

1. 問題を分類 - エラーの種類、重大度、範囲
2. 根本原因を特定 - 問題を引き起こした要因
3. 修正案を提示 - 再発を防ぐ方法

フェーズ 3：報告（workflow-monitor:report-generated）

1. イシュー本文を生成 - 構造化された形式
2. ラベルを割り当て - workflow、bug、enhancement
3. 証拠へのリンクを追加 - コマンド出力、セッション情報

フェーズ 4：イシューの作成（workflow-monitor:issue-created）

1. 重複を確認 - 既存のイシューを検索
2. 重複がなければ作成 - gh CLI 経由
3. セッションにリンク - 追跡可能にするため

イシューテンプレート

## Background

Detected during workflow execution on [DATE].

**Source:** [workflow name] session [session-id]

## Problem

[Description of the error or inefficiency]

**Evidence:**

[失敗したコマンド、または非効率だったコマンド] [出力の抜粋]

## Suggested Fix

[What should change to prevent this]

## Acceptance Criteria

- [ ] [Specific fix criterion]
- [ ] Tests added for new behavior
- [ ] Documentation updated

---
*Created automatically by workflow-monitor*

設定

# .workflow-monitor.yaml
enabled: true
auto_create_issues: false  # Require approval before creating
severity_threshold: "medium"  # Only report medium+ severity
efficiency_threshold: 0.7  # Flag workflows below 70% efficiency

detection:
  command_failures: true
  timeouts: true
  retry_loops: true
  context_exhaustion: true
  tool_misuse: true

efficiency:
  verbose_output_limit: 500
  max_file_reads: 2
  parallel_detection: true

ガードレール

1. 重複したイシューを作成しない - 作成前に既存のイシューを確認
2. 承認が必要 - auto_create_issues: true の場合を除く
3. 証拠が必要 - すべてのイシューに再現可能な証拠が必要
4. レート制限 - セッションあたり最大 5 件のイシュー

必須の TodoWrite 項目

1. workflow-monitor:capture-complete
2. workflow-monitor:analysis-complete
3. workflow-monitor:report-generated
4. workflow-monitor:issue-created（イシューを作成した場合）

統合ポイント

• imbue:proof-of-work：実行の証拠を記録
• sanctum:fix-workflow：提示された修正を実装
• フック：自動監視のためにセッションフックから起動可能

出力形式

効率レポート

## Workflow Efficiency Report

**Session:** [session-id]
**Duration:** 12m 34s
**Efficiency Score:** 0.72 (72%)

### Issues Detected

| Type | Count | Impact |
|------|-------|--------|
| Verbose output | 3 | Medium |
| Redundant reads | 2 | Low |
| Sequential tasks | 1 | Medium |

### Recommendations

1. Use `--quiet` flags for npm/pip commands
2. Cache file contents instead of re-reading
3. Parallelize independent file operations

### Create Issues?

- [ ] Issue 1: Verbose output from npm install
- [ ] Issue 2: Redundant file reads in validation

関連スキル

• imbue:proof-of-work：証拠を記録する方法
• sanctum:fix-workflow：ワークフロー改善コマンド

---

ステータス： 骨組みの実装です。次の対応が必要です。

• 自動監視のためのフック統合
• 効率スコアリングアルゴリズム
• 重複検出ロジック

終了条件

• 4 つすべての TodoWrite フェーズが完了している：capture-complete、 analysis-complete、report-generated、および（イシューを 作成した場合）issue-created
• 登録するすべてのイシューに再現可能な証拠が含まれている：失敗または非効率だった 正確なコマンドと、出力の抜粋
• イシューを作成する前に、gh issue list --search を使って重複を確認している； 重複するイシューの作成を抑止し、代わりに既存のイシューの URL を報告している
• 異常がいくつ検出されたかにかかわらず、セッションごとに作成するイシューは 5 件以下； レート制限を適用している