Initial commit
This commit is contained in:
410
skills/domain-analyzer/SKILL.md
Normal file
410
skills/domain-analyzer/SKILL.md
Normal file
@@ -0,0 +1,410 @@
|
||||
---
|
||||
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つの明確な作業フローを持つものはスキルにする
|
||||
|
||||
## ベストプラクティス
|
||||
|
||||
- 業務領域の理解には十分な時間をかける(急がず丁寧に)
|
||||
- ユーザーとの対話を重視し、推測や仮定を避ける
|
||||
- 機能は小さく分解し、単一責任の原則に従う
|
||||
- 要素分類は明確な基準に基づいて行う
|
||||
- 推奨構成は実装の優先順位を明示する
|
||||
- 業務領域分析レポートは後続フェーズで参照できるようにする
|
||||
|
||||
## チェックリスト
|
||||
|
||||
### 情報収集完了時
|
||||
|
||||
- [ ] 業務領域の概要が明確になっている
|
||||
- [ ] プラグイン化の目的が明確になっている
|
||||
- [ ] 対象ユーザーが特定されている
|
||||
- [ ] 現在の課題や問題点が把握されている
|
||||
- [ ] 期待される効果や成果が確認されている
|
||||
|
||||
### 領域分析完了時
|
||||
|
||||
- [ ] 業務の特徴が整理されている
|
||||
- [ ] 技術的制約が特定されている
|
||||
- [ ] ビジネス的制約が特定されている
|
||||
- [ ] 前提条件や依存関係が把握されている
|
||||
- [ ] 既存ツールやプロセスとの関係が確認されている
|
||||
|
||||
### 機能抽出完了時
|
||||
|
||||
- [ ] 業務の各ステップが分解されている
|
||||
- [ ] 自動化可能な作業が特定されている
|
||||
- [ ] 手作業が必要な部分が明確になっている
|
||||
- [ ] 各機能の入力と出力が定義されている
|
||||
- [ ] ドキュメント生成機能で使用するテンプレートファイルが特定されている
|
||||
- [ ] 機能間の依存関係が整理されている
|
||||
- [ ] 機能の粒度が適切である(単一責任の原則)
|
||||
|
||||
### 要素分類完了時
|
||||
|
||||
- [ ] エージェント候補が特定されている
|
||||
- [ ] ワークフロースキル候補が特定されている
|
||||
- [ ] コンベンションスキル候補が特定されている
|
||||
- [ ] コマンド候補が特定されている
|
||||
- [ ] 要素間の依存関係が整理されている
|
||||
- [ ] 分類基準が明確である
|
||||
|
||||
### 推奨提示完了時
|
||||
|
||||
- [ ] 推奨プラグイン構成が明確に提示されている
|
||||
- [ ] 各要素の役割が説明されている
|
||||
- [ ] 実装の優先順位が付けられている
|
||||
- [ ] 次のステップが案内されている
|
||||
- [ ] ユーザーの承認を得ている
|
||||
|
||||
### 最終確認
|
||||
|
||||
- [ ] 必要な機能リストが作成されている
|
||||
- [ ] 推奨エージェント/スキル/コマンド候補が提示されている
|
||||
- [ ] 業務領域分析レポートが作成されている
|
||||
- [ ] すべてのアウトプットが明確で理解しやすい
|
||||
- [ ] ユーザーが次のステップに進める状態になっている
|
||||
Reference in New Issue
Block a user