domain-analyzer

# 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図の自動生成、レイアウト最適化
   - 出力: