@majiayu000/workflow-analyzer

---
name: workflow-analyzer
description: 作業フローや手順を分析し、自動化可能な要素を特定する。ワークフロー分析時、自動化検討時、業務プロセス改善時、またはユーザーが作業フロー分析、自動化要素、業務手順、プロセス最適化に言及した際に使用する。
---

# 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: チェックする
ステップ3: 終わり
```

### フェーズ3: 自動化分析

各ステップを分析し、自動化可能性を評価する。

**実施内容:**

1. 各ステップの自動化可能性を評価する
2. 自動化の難易度を判定する
3. 自動化による効果を見積もる
4. 手作業が必要な部分を特定する
5. 自動化の優先順位を付ける

**評価基準:**

- **自動化可能性**: 高/中/低
  - 高: 明確なルールがあり、判断が機械的
  - 中: ある程度のルールがあるが、一部判断が必要
  - 低: 人間の経験や直感が必要
- **自動化難易度**: 容易/中程度/困難
  - 容易: 既存ツールやAPIで実現可能
  - 中程度: カスタム実装が必要だが実現可能
  - 困難: 技術的制約があり実現が難しい
- **自動化効果**: 高/中/低
  - 高: 時間削減が大きい、ミス削減効果が高い
  - 中: 一定の効果がある
  - 低: 効果が限定的

**良い例:**

```markdown
【自動化分析結果】

ステップ1: プルリクエスト確認
- 自動化可能性: 高
- 自動化難易度: 容易
- 自動化効果: 中
- 理由: GitHub APIで情報取得可能、基本的な分析は自動化できる
- 手作業部分: 優先度の最終判断（レビュー者の経験に基づく）

ステップ2: 静的解析結果確認
- 自動化可能性: 高
- 自動化難易度: 容易
- 自動化効果: 高
- 理由: CI/CD結果の取得と解析は完全自動化可能
- 手作業部分: なし

ステップ3: コード品質チェック
- 自動化可能性: 中
- 自動化難易度: 中程度
- 自動化効果: 高
- 理由: コーディング規約チェックは自動化可能だが、設計原則の評価は難しい
- 手作業部分: アーキテクチャレビュー、設計の妥当性判断

ステップ4: テストカバレッジ確認
- 自動化可能性: 高
- 自動化難易度: 容易
- 自動化効果: 高
- 理由: カバレッジレポートの解析は完全自動化可能
- 手作業部分: テストの品質評価（テストが適切かどうか）

ステップ5: レビューコメント作成
- 自動化可能性: 中
- 自動化難易度: 中程度
- 自動化効果: 中
- 理由: 定型的なコメントは自動生成可能、建設的なコメントは難しい
- 手作業部分: 具体的な修正提案、コンテキストに応じたアドバイス

ステップ6: 承認判断
- 自動化可能性: 中
- 自動化難易度: 中程度
- 自動化効果: 低
- 理由: ルールベースの判断は可能だが、最終承認は人間が行うべき
- 手作業部分: 最終的な承認判断
```

**悪い例:**

```markdown
全部自動化できる
```

### フェーズ4: スキル分類

自動化可能な要素をワークフロースキルとコンベンションスキルに分類する。

**実施内容:**

1. 作業手順をワークフロースキル候補として分類する
2. 規約やガイドラインをコンベンションスキル候補として分類する
3. 各スキルの責任範囲を定義する
4. スキル間の依存関係を整理する
5. 必要なテンプレートファイルと対応するスキルの関係を特定する
6. スキルの粒度を調整する

**分類基準:**

- **ワークフロースキル**: 具体的な作業手順を定義する
  - 入力、処理、出力が明確
  - ステップが順序立てられている
  - チェックリストや検証項目がある
- **コンベンションスキル**: 規約やガイドラインを定義する
  - ルールや基準が明確
  - 良い例/悪い例が示せる
  - チェックリストで検証可能

**良い例:**

```markdown
【スキル分類結果】

ワークフロースキル候補:

1. pull-request-analyzer
   - 責任範囲: プルリクエストの内容を分析し、レビュー対象を特定する
   - 入力: プルリクエストURL
   - 出力: レビュー対象の特定、優先度判断、変更サマリー
   - 依存: なし

2. static-analysis-checker
   - 責任範囲: CI/CD静的解析結果を確認し、問題を抽出する
   - 入力: CI/CDパイプライン結果
   - 出力: 問題リスト、重要度分類
   - 依存: なし

3. code-quality-reviewer
   - 責任範囲: コード品質をチェックし、改善提案を作成する
   - 入力: 変更されたコード、コーディング規約
   - 出力: 品質問題リスト、改善提案
   - 依存: coding-conventions

4. test-coverage-analyzer
   - 責任範囲: テストカバレッジを確認し、テスト改善提案を作成する
   - 入力: テスト実行結果、カバレッジレポート
   - 出力: カバレッジ分析結果、テスト改善提案
   - 依存: なし

5. review-comment-generator
   - 責任範囲: レビューコメントを生成し、優先度付けを行う
   - 入力: 品質問題リスト、改善提案
   - 出力: レビューコメント
   - 依存: review-comment-guidelines

コンベンションスキル候補:

1. coding-conventions
   - 責任範囲: コーディング規約（命名規則、フォーマット、ベストプラクティス）を定義
   - カテゴリ: 命名規則、コードレイアウト、設計原則
   - 良い例/悪い例: あり

2. review-comment-guidelines
   - 責任範囲: レビューコメントのガイドライン（建設的、具体的、実行可能）を定義
   - カテゴリ: コメントの書き方、優先度付け、フィードバックの伝え方
   - 良い例/悪い例: あり
```

**悪い例:**

```markdown
スキル: レビュー全部
```

### フェーズ5: 推奨提示

分類結果を基に、推奨されるスキル構成をユーザーに提示する。

**実施内容:**

1. 推奨されるワークフロースキル構成を提示する
2. 推奨されるコンベンションスキル構成を提示する
3. スキルの実行順序を明示する
4. 実装の優先順位を提案する
5. 次のステップ（各スキルの詳細設計）を案内する

**提示形式:**

```markdown
【推奨スキル構成】

ワークフロースキル (5個):
- pull-request-analyzer: プルリクエストの内容を分析し、レビュー対象を特定する
- static-analysis-checker: CI/CD静的解析結果を確認し、問題を抽出する
- code-quality-reviewer: コード品質をチェックし、改善提案を作成する
- test-coverage-analyzer: テストカバレッジを確認し、テスト改善提案を作成する
- review-comment-generator: レビューコメントを生成し、優先度付けを行う

コンベンションスキル (2個):
- coding-conventions: コーディング規約を定義
- review-comment-guidelines: レビューコメントのガイドラインを定義

【実行順序】

1. pull-request-analyzer (並列実行可能)
2. static-analysis-checker (並列実行可能)
3. code-quality-reviewer (coding-conventionsに依存)
4. test-coverage-analyzer (並列実行可能)
5. review-comment-generator (review-comment-guidelinesに依存)

【実装優先順位】

優先度1（必須）:
- coding-conventions
- pull-request-analyzer
- static-analysis-checker
- code-quality-reviewer

優先度2（推奨）:
- test-coverage-analyzer
- review-comment-guidelines
- review-comment-generator

【自動化効果見積もり】

現状: 1回あたり30分〜1時間（手作業）
自動化後: 1回あたり10分〜15分（自動+人間の最終判断）
削減効果: 約60%〜75%の時間削減
```

**良い例:**

推奨構成が明確で、各スキルの役割、実行順序、優先順位が説明されており、自動化効果も示されている。

**悪い例:**

```markdown
スキルをいくつか作る
```

## アウトプット

このスキルは以下を生成する:

- **自動化可能な要素リスト**: 各ステップの自動化可能性評価（自動化可能性、難易度、効果）
- **推奨スキル構成**: ワークフロースキルとコンベンションスキルの推奨構成
- **テンプレートファイルリスト**: 各ステップで使用するテンプレートファイルの一覧（配置先を含む）
- **作業フロー分析レポート**: 作業フローの特徴、ボトルネック、自動化効果をまとめたドキュメント

## 想定されるエラーと対処法

### エラー1: ステップ分解が粗すぎる

**検出例:**

```markdown
ステップ1: レビューする
ステップ2: 終わり
```

**対処法:**

- 各ステップをさらに細かく分解する
- 1ステップは1つの明確な目的を持つようにする
- 入力と出力を明確にする

### エラー2: 自動化可能性の評価が不明確

**検出例:**

```markdown
自動化可能性: たぶんできる
```

**対処法:**

- 明確な評価基準（高/中/低）を使用する
- 評価の理由を具体的に記述する
- 手作業が必要な部分を明示する

### エラー3: スキルの粒度が不適切

**検出例:**

スキルが大きすぎる、または小さすぎる。

**対処法:**

- 1スキルは1つの明確な責任を持つようにする
- スキルが大きすぎる場合は分割する
- スキルが小さすぎる場合は統合する
- スキル粒度規約に従う

## ベストプラクティス

- 作業フローは実際の作業者にヒアリングして収集する
- ステップ分解は細かすぎず、粗すぎず適切な粒度にする
- 自動化分析は客観的な基準で評価する
- スキル分類は明確な基準に基づいて行う
- 推奨構成は実装の優先順位を明示する
- 自動化効果を定量的に示す（時間削減率など）

## チェックリスト

### フロー収集完了時

- [ ] 作業フローの概要が明確になっている
- [ ] 作業の開始条件（トリガー）が特定されている
- [ ] 作業の終了条件（完了基準）が確認されている
- [ ] 作業に関わる人やシステムが把握されている
- [ ] 既存の手順書やドキュメントが確認されている

### ステップ分解完了時

- [ ] 作業が順序通りのステップに分解されている
- [ ] 各ステップの入力と出力が定義されている
- [ ] ステップ間のデータ受け渡しが確認されている
- [ ] 条件分岐や繰り返しが特定されている
- [ ] 各ステップの判断基準やルールが明確になっている
- [ ] 各ステップで使用するテンプレートファイルやフォーマットが特定されている
- [ ] ステップの粒度が適切である

### 自動化分析完了時

- [ ] 各ステップの自動化可能性が評価されている
- [ ] 自動化の難易度が判定されている
- [ ] 自動化による効果が見積もられている
- [ ] 手作業が必要な部分が特定されている
- [ ] 自動化の優先順位が付けられている
- [ ] 評価基準が明確である

### スキル分類完了時

- [ ] ワークフロースキル候補が特定されている
- [ ] コンベンションスキル候補が特定されている
- [ ] 各スキルの責任範囲が定義されている
- [ ] スキル間の依存関係が整理されている
- [ ] 必要なテンプレートファイルと対応するスキルの関係が特定されている
- [ ] スキルの粒度が適切である

### 推奨提示完了時

- [ ] 推奨スキル構成が明確に提示されている
- [ ] スキルの実行順序が明示されている
- [ ] 実装の優先順位が提案されている
- [ ] 自動化効果が定量的に示されている
- [ ] 次のステップが案内されている
- [ ] ユーザーの承認を得ている

### 最終確認

- [ ] 自動化可能な要素リストが作成されている
- [ ] 推奨スキル構成が提示されている
- [ ] 作業フロー分析レポートが作成されている
- [ ] すべてのアウトプットが明確で理解しやすい
- [ ] ユーザーが次のステップに進める状態になっている