workflow-analyzer

# Workflow Analyzer

## 概要

このSkillは、ユーザーが提供する作業フローや業務手順の情報を基に、自動化可能な要素を分析・特定する。ユーザーとの対話を通じて作業の詳細を理解し、プラグイン化すべきスキルや作業の依存関係を明確にする。

## 責任範囲

このSkillは以下の範囲をカバーする:

- 作業フローや業務手順の収集
- 作業ステップの分解と詳細化
- 自動化可能な要素の特定と評価
- ワークフロースキルとコンベンションスキルの分類
- 推奨スキル構成の提案
- 作業フロー分析レポートの作成

## ワークフロー

### フェーズ1: フロー収集

ユーザーとの対話を通じて、作業フローや業務手順に関する情報を収集する。

**実施内容:**

1. 作業フローの概要を確認する
2. 作業の開始条件（トリガー）を特定する
3. 作業の終了条件（完了基準）を確認する
4. 作業に関わる人やシステムを把握する
5. 既存の手順書やドキュメントを確認する

**質問例:**

```markdown
【作業フローの確認】
分析したい作業フローを教えてください。

1. 作業名: [作業の名称]
2. 目的: [この作業で達成したいこと]
3. 頻度: [どのくらいの頻度で実施するか]
4. 所要時間: [1回あたりの作業時間]
5. 担当者: [誰が実施するか]
```

**良い例:**

```markdown
作業名: コードレビュー実施
目的: コード品質を確保し、バグやセキュリティ問題を早期発見する
頻度: プルリクエストごと（1日5〜10回）
所要時間: 1回あたり30分〜1時間
担当者: シニアエンジニア、テックリード

開始条件:
- プルリクエストが作成される
- CI/CDパイプラインが成功する

終了条件:
- レビューコメントが全て解決される
- 承認者が2名以上Approveする
- マージ可能な状態になる
```

**悪い例:**

```markdown
作業名: レビュー
目的: 確認する
頻度: たまに
所要時間: 適当
担当者: 誰か
```

### フェーズ2: ステップ分解

作業フローを具体的なステップに分解し、各ステップの詳細を明確にする。

**実施内容:**

1. 作業を順序通りのステップに分解する
2. 各ステップの入力と出力を定義する
3. ステップ間のデータ受け渡しを確認する
4. 条件分岐や繰り返しを特定する
5. 各ステップの判断基準やルールを明確にする
6. 各ステップで使用するテンプレートファイルやフォーマットを特定する

**分解基準:**

- 1ステップは1つの明確な目的を持つ
- ステップの粒度は適切である（細かすぎず、粗すぎず）
- ステップ間の依存関係が明確である
- 各ステップの完了条件が定義できる

**良い例:**

```markdown
【コードレビュー実施フロー】

ステップ1: プルリクエスト確認
- 入力: プルリクエストURL
- 処理: PR内容、変更ファイル、コミットメッセージを確認
- 出力: レビュー対象の特定、優先度判断
- 判断基準: 変更規模、影響範囲、緊急度

ステップ2: 静的解析結果確認
- 入力: CI/CDパイプライン結果
- 処理: linter、型チェック、セキュリティスキャン結果を確認
- 出力: 自動検出された問題リスト
- 判断基準: エラーがゼロであること

ステップ3: コード品質チェック
- 入力: 変更されたコード
- 処理: コーディング規約、設計原則、ベストプラクティスに照らしてチェック
- 出力: 品質問題リスト、改善提案
- 判断基準: コーディング規約、SOLID原則、セキュリティガイドライン

ステップ4: テストカバレッジ確認
- 入力: テスト実行結果、カバレッジレポート
- 処理: テストの網羅性、テストの品質を確認
- 出力: テスト改善提案
- 判断基準: カバレッジ80%以上、エッジケースのテストが含まれる

ステップ5: レビューコメント作成
- 入力: 品質問題リスト、改善提案
- 処理: コメントの優先度付け、具体的な修正案の作成
- 出力: レビューコメント
- 判断基準: 建設的、具体的、実行可能

ステップ6: 承認判断
- 入力: 全てのチェック結果、レビューコメント
- 処理: 承認可否を判断
- 出力: Approve or Request Changes
- 判断基準: 重大な問題がゼロ、軽微な問題は許容範囲内
```

**悪い例:**

```markdown
ステップ1: 確認する
ステップ2: チェックする