| name | workflow-analyzer |
| description | 作業フローや手順を分析し、自動化可能な要素を特定する。ワークフロー分析時、自動化検討時、業務プロセス改善時、またはユーザーが作業フロー分析、自動化要素、業務手順、プロセス最適化に言及した際に使用する。 |
Workflow Analyzer
概要
このSkillは、ユーザーが提供する作業フローや業務手順の情報を基に、自動化可能な要素を分析・特定する。ユーザーとの対話を通じて作業の詳細を理解し、プラグイン化すべきスキルや作業の依存関係を明確にする。
責任範囲
このSkillは以下の範囲をカバーする:
- 作業フローや業務手順の収集
- 作業ステップの分解と詳細化
- 自動化可能な要素の特定と評価
- ワークフロースキルとコンベンションスキルの分類
- 推奨スキル構成の提案
- 作業フロー分析レポートの作成
ワークフロー
フェーズ1: フロー収集
ユーザーとの対話を通じて、作業フローや業務手順に関する情報を収集する。
実施内容:
- 作業フローの概要を確認する
- 作業の開始条件（トリガー）を特定する
- 作業の終了条件（完了基準）を確認する
- 作業に関わる人やシステムを把握する
- 既存の手順書やドキュメントを確認する
質問例:
【作業フローの確認】
分析したい作業フローを教えてください。
1. 作業名: [作業の名称]
2. 目的: [この作業で達成したいこと]
3. 頻度: [どのくらいの頻度で実施するか]
4. 所要時間: [1回あたりの作業時間]
5. 担当者: [誰が実施するか]
良い例:
作業名: コードレビュー実施
目的: コード品質を確保し、バグやセキュリティ問題を早期発見する
頻度: プルリクエストごと（1日5〜10回）
所要時間: 1回あたり30分〜1時間
担当者: シニアエンジニア、テックリード
開始条件:
- プルリクエストが作成される
- CI/CDパイプラインが成功する
終了条件:
- レビューコメントが全て解決される
- 承認者が2名以上Approveする
- マージ可能な状態になる
悪い例:
作業名: レビュー
目的: 確認する
頻度: たまに
所要時間: 適当
担当者: 誰か
フェーズ2: ステップ分解
作業フローを具体的なステップに分解し、各ステップの詳細を明確にする。
実施内容:
- 作業を順序通りのステップに分解する
- 各ステップの入力と出力を定義する
- ステップ間のデータ受け渡しを確認する
- 条件分岐や繰り返しを特定する
- 各ステップの判断基準やルールを明確にする
- 各ステップで使用するテンプレートファイルやフォーマットを特定する
分解基準:
- 1ステップは1つの明確な目的を持つ
- ステップの粒度は適切である（細かすぎず、粗すぎず）
- ステップ間の依存関係が明確である
- 各ステップの完了条件が定義できる
良い例:
【コードレビュー実施フロー】
ステップ1: プルリクエスト確認
- 入力: プルリクエストURL
- 処理: PR内容、変更ファイル、コミットメッセージを確認
- 出力: レビュー対象の特定、優先度判断
- 判断基準: 変更規模、影響範囲、緊急度
ステップ2: 静的解析結果確認
- 入力: CI/CDパイプライン結果
- 処理: linter、型チェック、セキュリティスキャン結果を確認
- 出力: 自動検出された問題リスト
- 判断基準: エラーがゼロであること
ステップ3: コード品質チェック
- 入力: 変更されたコード
- 処理: コーディング規約、設計原則、ベストプラクティスに照らしてチェック
- 出力: 品質問題リスト、改善提案
- 判断基準: コーディング規約、SOLID原則、セキュリティガイドライン
ステップ4: テストカバレッジ確認
- 入力: テスト実行結果、カバレッジレポート
- 処理: テストの網羅性、テストの品質を確認
- 出力: テスト改善提案
- 判断基準: カバレッジ80%以上、エッジケースのテストが含まれる
ステップ5: レビューコメント作成
- 入力: 品質問題リスト、改善提案
- 処理: コメントの優先度付け、具体的な修正案の作成
- 出力: レビューコメント
- 判断基準: 建設的、具体的、実行可能
ステップ6: 承認判断
- 入力: 全てのチェック結果、レビューコメント
- 処理: 承認可否を判断
- 出力: Approve or Request Changes
- 判断基準: 重大な問題がゼロ、軽微な問題は許容範囲内
悪い例:
ステップ1: 確認する
ステップ2: チェックする
ステップ3: 終わり
フェーズ3: 自動化分析
各ステップを分析し、自動化可能性を評価する。
実施内容:
- 各ステップの自動化可能性を評価する
- 自動化の難易度を判定する
- 自動化による効果を見積もる
- 手作業が必要な部分を特定する
- 自動化の優先順位を付ける
評価基準:
- 自動化可能性: 高/中/低
- 高: 明確なルールがあり、判断が機械的
- 中: ある程度のルールがあるが、一部判断が必要
- 低: 人間の経験や直感が必要
- 自動化難易度: 容易/中程度/困難
- 容易: 既存ツールやAPIで実現可能
- 中程度: カスタム実装が必要だが実現可能
- 困難: 技術的制約があり実現が難しい
- 自動化効果: 高/中/低
- 高: 時間削減が大きい、ミス削減効果が高い
- 中: 一定の効果がある
- 低: 効果が限定的
良い例:
【自動化分析結果】
ステップ1: プルリクエスト確認
- 自動化可能性: 高
- 自動化難易度: 容易
- 自動化効果: 中
- 理由: GitHub APIで情報取得可能、基本的な分析は自動化できる
- 手作業部分: 優先度の最終判断（レビュー者の経験に基づく）
ステップ2: 静的解析結果確認
- 自動化可能性: 高
- 自動化難易度: 容易
- 自動化効果: 高
- 理由: CI/CD結果の取得と解析は完全自動化可能
- 手作業部分: なし
ステップ3: コード品質チェック
- 自動化可能性: 中
- 自動化難易度: 中程度
- 自動化効果: 高
- 理由: コーディング規約チェックは自動化可能だが、設計原則の評価は難しい
- 手作業部分: アーキテクチャレビュー、設計の妥当性判断
ステップ4: テストカバレッジ確認
- 自動化可能性: 高
- 自動化難易度: 容易
- 自動化効果: 高
- 理由: カバレッジレポートの解析は完全自動化可能
- 手作業部分: テストの品質評価（テストが適切かどうか）
ステップ5: レビューコメント作成
- 自動化可能性: 中
- 自動化難易度: 中程度
- 自動化効果: 中
- 理由: 定型的なコメントは自動生成可能、建設的なコメントは難しい
- 手作業部分: 具体的な修正提案、コンテキストに応じたアドバイス
ステップ6: 承認判断
- 自動化可能性: 中
- 自動化難易度: 中程度
- 自動化効果: 低
- 理由: ルールベースの判断は可能だが、最終承認は人間が行うべき
- 手作業部分: 最終的な承認判断
悪い例:
全部自動化できる
フェーズ4: スキル分類
自動化可能な要素をワークフロースキルとコンベンションスキルに分類する。
実施内容:
- 作業手順をワークフロースキル候補として分類する
- 規約やガイドラインをコンベンションスキル候補として分類する
- 各スキルの責任範囲を定義する
- スキル間の依存関係を整理する
- 必要なテンプレートファイルと対応するスキルの関係を特定する
- スキルの粒度を調整する
分類基準:
- ワークフロースキル: 具体的な作業手順を定義する
- 入力、処理、出力が明確
- ステップが順序立てられている
- チェックリストや検証項目がある
- コンベンションスキル: 規約やガイドラインを定義する
- ルールや基準が明確
- 良い例/悪い例が示せる
- チェックリストで検証可能
良い例:
【スキル分類結果】
ワークフロースキル候補:
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
- 責任範囲: レビューコメントのガイドライン（建設的、具体的、実行可能）を定義
- カテゴリ: コメントの書き方、優先度付け、フィードバックの伝え方
- 良い例/悪い例: あり
悪い例:
スキル: レビュー全部
フェーズ5: 推奨提示
分類結果を基に、推奨されるスキル構成をユーザーに提示する。
実施内容:
- 推奨されるワークフロースキル構成を提示する
- 推奨されるコンベンションスキル構成を提示する
- スキルの実行順序を明示する
- 実装の優先順位を提案する
- 次のステップ（各スキルの詳細設計）を案内する
提示形式:
【推奨スキル構成】
ワークフロースキル (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%の時間削減
良い例:
推奨構成が明確で、各スキルの役割、実行順序、優先順位が説明されており、自動化効果も示されている。
悪い例:
スキルをいくつか作る
アウトプット
このスキルは以下を生成する:
- 自動化可能な要素リスト: 各ステップの自動化可能性評価（自動化可能性、難易度、効果）
- 推奨スキル構成: ワークフロースキルとコンベンションスキルの推奨構成
- テンプレートファイルリスト: 各ステップで使用するテンプレートファイルの一覧（配置先を含む）
- 作業フロー分析レポート: 作業フローの特徴、ボトルネック、自動化効果をまとめたドキュメント
想定されるエラーと対処法
エラー1: ステップ分解が粗すぎる
検出例:
ステップ1: レビューする
ステップ2: 終わり
対処法:
- 各ステップをさらに細かく分解する
- 1ステップは1つの明確な目的を持つようにする
- 入力と出力を明確にする
エラー2: 自動化可能性の評価が不明確
検出例:
自動化可能性: たぶんできる
対処法:
- 明確な評価基準（高/中/低）を使用する
- 評価の理由を具体的に記述する
- 手作業が必要な部分を明示する
エラー3: スキルの粒度が不適切
検出例:
スキルが大きすぎる、または小さすぎる。
対処法:
- 1スキルは1つの明確な責任を持つようにする
- スキルが大きすぎる場合は分割する
- スキルが小さすぎる場合は統合する
- スキル粒度規約に従う
ベストプラクティス
- 作業フローは実際の作業者にヒアリングして収集する
- ステップ分解は細かすぎず、粗すぎず適切な粒度にする
- 自動化分析は客観的な基準で評価する
- スキル分類は明確な基準に基づいて行う
- 推奨構成は実装の優先順位を明示する
- 自動化効果を定量的に示す（時間削減率など）
チェックリスト
フロー収集完了時
ステップ分解完了時
自動化分析完了時
スキル分類完了時
推奨提示完了時
最終確認
