--- name: domain-analyzer description: ユーザーの業務領域や目的を分析し、必要な機能を抽出する。プラグイン企画時、業務分析時、機能要件定義時、またはユーザーが業務領域分析、ドメイン分析、機能抽出、プラグイン設計に言及した際に使用する。 --- # Domain Analyzer ## 概要 このSkillは、ユーザーが提供する業務領域や目的の情報を基に、プラグイン化に必要な機能を分析・抽出する。ユーザーとの対話を通じて業務の本質を理解し、自動化すべき作業や必要なプラグイン要素を特定する。 ## 責任範囲 このSkillは以下の範囲をカバーする: - ユーザーの業務領域や目的の理解 - 業務の特徴・制約・前提条件の把握 - 自動化可能な機能の抽出 - 機能のカテゴリ分類と優先順位付け - 推奨エージェント・スキル・コマンドの提案 - 業務領域分析レポートの作成 ## ワークフロー ### フェーズ1: 情報収集 ユーザーとの対話を通じて、業務領域や目的に関する基本情報を収集する。 **実施内容:** 1. 業務領域の概要を確認する 2. プラグイン化の目的を明確にする 3. 対象ユーザー（利用者）を特定する 4. 現在の課題や問題点を把握する 5. 期待される効果や成果を確認する **質問例:** ```markdown 【業務領域の確認】 プラグイン化したい業務領域を教えてください。以下のどれに近いですか？ 1. 開発プロセス（要件定義、設計、実装、テストなど） 2. ドキュメント作成（技術文書、仕様書、マニュアルなど） 3. データ処理（分析、変換、集計など） 4. その他（具体的に教えてください） ``` **良い例:** ```markdown 業務領域: データベース設計 目的: データベーススキーマ設計を効率化し、設計品質を向上させる 対象ユーザー: バックエンド開発者、データベースエンジニア 課題: 手作業でのER図作成に時間がかかり、正規化の検証が不十分 期待効果: 設計時間を50%削減し、正規化ルール違反をゼロにする ``` **悪い例:** ```markdown 業務領域: いろいろなこと 目的: 便利にしたい 対象ユーザー: みんな 課題: よくわからない 期待効果: 良くなる ``` ### フェーズ2: 領域分析 収集した情報を基に、業務領域の特徴や制約を分析する。 **実施内容:** 1. 業務の特徴を整理する 2. 技術的制約を特定する 3. ビジネス的制約を特定する 4. 前提条件や依存関係を把握する 5. 既存ツールやプロセスとの関係を確認する **分析観点:** - 業務の複雑度（シンプル/標準/複雑） - 自動化の難易度（容易/中程度/困難） - 必要な専門知識のレベル（基本/中級/上級） - 対象範囲の広さ（狭い/中程度/広い） **良い例:** ```markdown 【分析結果】 業務の特徴: - データベース設計は段階的なプロセス（概念設計 → 論理設計 → 物理設計） - 正規化ルールや命名規則など、明確な規約が存在する - ER図やテーブル定義書など、複数の成果物が必要 技術的制約: - データベース製品（MySQL, PostgreSQL, SQL Serverなど）により構文が異なる - 既存データベースとの互換性を考慮する必要がある ビジネス的制約: - 設計変更のコストが高いため、初期段階での品質確保が重要 - チーム内での設計レビューが必須 ``` **悪い例:** ```markdown 【分析結果】 業務の特徴: 複雑 制約: いろいろある ``` ### フェーズ3: 機能抽出 業務領域から、プラグインとして実装すべき機能を抽出する。 **実施内容:** 1. 業務の各ステップを分解する 2. 自動化可能な作業を特定する 3. 手作業が必要な部分を明確にする 4. 各機能の入力と出力を定義する 5. 機能間の依存関係を整理する **抽出基準:** - 繰り返し実施される作業 - 明確なルールやパターンがある作業 - 検証や品質チェックが必要な作業 - ドキュメント生成が必要な作業 - テンプレートファイルを使用する作業（ドキュメント生成、フォーム入力、定型文作成など） **良い例:** ```markdown 【抽出された機能】 1. エンティティ定義の収集 - 入力: ユーザーからの要求、既存システムの情報 - 処理: エンティティの特定、属性の定義、関連の整理 - 出力: エンティティ一覧、属性リスト 2. 正規化の実施 - 入力: エンティティ定義 - 処理: 第1正規形〜第3正規形への変換、正規化ルール検証 - 出力: 正規化されたテーブル定義 3. ER図の生成 - 入力: 正規化されたテーブル定義 - 処理: ER図の自動生成、レイアウト最適化 - 出力: ER図（Mermaid形式） 4. テーブル定義書の作成 - 入力: テーブル定義、制約情報 - 処理: 定義書フォーマットへの変換 - 出力: テーブル定義書（Markdown形式） - テンプレート: table-definition-template.md（テーブル名、カラム定義、インデックス、制約の記述フォーマット） 5. DDLスクリプトの生成 - 入力: テーブル定義、対象データベース製品 - 処理: データベース製品別のDDL生成 - 出力: CREATE TABLE文、制約定義 ``` **悪い例:** ```markdown 【抽出された機能】 1. データベースを作る 2. 便利にする 3. 良くする ``` ### フェーズ4: 要素分類 抽出した機能を、エージェント・スキル・コマンドに分類する。 **実施内容:** 1. 責任範囲の広い機能をエージェント候補として分類する 2. 具体的な作業手順をスキル候補として分類する 3. エージェントとスキルの組み合わせをコマンド候補として分類する 4. 規約やガイドラインをコンベンションスキル候補として分類する 5. 必要なテンプレートファイルと対応するスキルの関係を特定する 6. 要素間の依存関係を整理する **分類基準:** - **エージェント**: 特定フェーズや領域全体に対する責任を持つ - **スキル（ワークフロー）**: 具体的な作業手順を定義する - **スキル（コンベンション）**: 規約やガイドラインを定義する - **コマンド**: エージェントとスキルを組み合わせて実行可能にする **良い例:** ```markdown 【分類結果】 エージェント候補: - database-design-agent: データベース設計全体に対する責任を持つ ワークフロースキル候補: - entity-definition-collector: エンティティ定義を収集する - normalization-processor: 正規化を実施する - er-diagram-generator: ER図を生成する - table-definition-writer: テーブル定義書を作成する - ddl-script-generator: DDLスクリプトを生成する コンベンションスキル候補: - database-naming-conventions: データベース命名規則 - normalization-rules: 正規化ルール コマンド候補: - design-database: データベース設計全体を実行（全スキルを順次実行） - generate-schema: スキーマ定義のみを生成（一部スキルを実行） ``` **悪い例:** ```markdown 【分類結果】 エージェント: データベース スキル: いろいろ コマンド: 実行 ``` ### フェーズ5: 推奨提示 分類結果を基に、推奨されるプラグイン構成をユーザーに提示する。 **実施内容:** 1. 推奨されるエージェント構成を提示する 2. 推奨されるスキル構成を提示する 3. 推奨されるコマンド構成を提示する 4. 実装の優先順位を提案する 5. 次のステップ（各要素の詳細設計）を案内する **提示形式:** ```markdown 【推奨プラグイン構成】 プラグイン名: database-design-plugin エージェント (1個): - database-design-agent: データベース設計全体に対する責任を持つ スキル (7個): ワークフロースキル: - entity-definition-collector: エンティティ定義を収集する - normalization-processor: 正規化を実施する - er-diagram-generator: ER図を生成する - table-definition-writer: テーブル定義書を作成する - ddl-script-generator: DDLスクリプトを生成する コンベンションスキル: - database-naming-conventions: データベース命名規則 - normalization-rules: 正規化ルール コマンド (2個): - design-database: データベース設計全体を実行 - generate-schema: スキーマ定義のみを生成 【実装優先順位】 優先度1（必須）: - database-design-agent - entity-definition-collector - normalization-processor - database-naming-conventions - normalization-rules 優先度2（推奨）: - er-diagram-generator - table-definition-writer - design-database コマンド 優先度3（オプション）: - ddl-script-generator - generate-schema コマンド ``` **良い例:** 推奨構成が明確で、各要素の役割が説明されており、優先順位が付けられている。 **悪い例:** ```markdown 【推奨プラグイン構成】 いろいろ作る ``` ## アウトプット このスキルは以下を生成する: - **必要な機能リスト**: 抽出された機能の一覧（入力・処理・出力を含む） - **推奨エージェント/スキル/コマンド候補**: プラグイン要素の推奨構成 - **テンプレートファイルリスト**: ドキュメント生成機能で使用するテンプレートファイルの一覧（配置先を含む） - **業務領域分析レポート**: 業務の特徴、制約、前提条件をまとめたドキュメント ## 想定されるエラーと対処法 ### エラー1: 業務領域が曖昧 **検出例:** ```markdown 業務領域: いろいろなこと ``` **対処法:** - 具体的な業務名や作業内容を確認する - 既存の業務プロセスやドキュメントを参照する - ユーザーに具体例を尋ねる ### エラー2: 機能の粒度が不適切 **検出例:** ```markdown 機能: データベース全体を作成する ``` **対処法:** - 機能を小さなステップに分解する - 各ステップの入力と出力を明確にする - 1つの機能は1つの明確な目的を持つようにする ### エラー3: 要素分類が不明確 **検出例:** エージェントとスキルの区別が曖昧で、どちらに分類すべきか不明確。 **対処法:** - エージェントは「責任範囲」、スキルは「具体的な作業手順」と区別する - 複数のスキルをまとめる役割はエージェントにする - 1つの明確な作業フローを持つものはスキルにする ## ベストプラクティス - 業務領域の理解には十分な時間をかける（急がず丁寧に） - ユーザーとの対話を重視し、推測や仮定を避ける - 機能は小さく分解し、単一責任の原則に従う - 要素分類は明確な基準に基づいて行う - 推奨構成は実装の優先順位を明示する - 業務領域分析レポートは後続フェーズで参照できるようにする ## チェックリスト ### 情報収集完了時 - [ ] 業務領域の概要が明確になっている - [ ] プラグイン化の目的が明確になっている - [ ] 対象ユーザーが特定されている - [ ] 現在の課題や問題点が把握されている - [ ] 期待される効果や成果が確認されている ### 領域分析完了時 - [ ] 業務の特徴が整理されている - [ ] 技術的制約が特定されている - [ ] ビジネス的制約が特定されている - [ ] 前提条件や依存関係が把握されている - [ ] 既存ツールやプロセスとの関係が確認されている ### 機能抽出完了時 - [ ] 業務の各ステップが分解されている - [ ] 自動化可能な作業が特定されている - [ ] 手作業が必要な部分が明確になっている - [ ] 各機能の入力と出力が定義されている - [ ] ドキュメント生成機能で使用するテンプレートファイルが特定されている - [ ] 機能間の依存関係が整理されている - [ ] 機能の粒度が適切である（単一責任の原則） ### 要素分類完了時 - [ ] エージェント候補が特定されている - [ ] ワークフロースキル候補が特定されている - [ ] コンベンションスキル候補が特定されている - [ ] コマンド候補が特定されている - [ ] 要素間の依存関係が整理されている - [ ] 分類基準が明確である ### 推奨提示完了時 - [ ] 推奨プラグイン構成が明確に提示されている - [ ] 各要素の役割が説明されている - [ ] 実装の優先順位が付けられている - [ ] 次のステップが案内されている - [ ] ユーザーの承認を得ている ### 最終確認 - [ ] 必要な機能リストが作成されている - [ ] 推奨エージェント/スキル/コマンド候補が提示されている - [ ] 業務領域分析レポートが作成されている - [ ] すべてのアウトプットが明確で理解しやすい - [ ] ユーザーが次のステップに進める状態になっている