Initial commit
This commit is contained in:
Zhongwei Li
294
skills/agent-generator/SKILL.md
Normal file
294
skills/agent-generator/SKILL.md
Normal file
@@ -0,0 +1,294 @@
|
||||
---
|
||||
name: agent-generator
|
||||
description: ユーザーの責任範囲定義から、Agentのマークダウンファイルを生成する。エージェント作成時、プラグイン要素生成時、またはユーザーがエージェント定義、責任範囲、Agent生成、エージェントドキュメントに言及した際に使用する。
|
||||
---
|
||||
|
||||
# Agent Generator
|
||||
|
||||
## 概要
|
||||
|
||||
このSkillは、ユーザーが提供する責任範囲や対象フェーズの情報を基に、Agentのマークダウンファイルを生成する。ユーザーとの対話を通じて必要な情報を収集し、標準化されたエージェントのドキュメントを作成する。
|
||||
|
||||
## 責任範囲
|
||||
|
||||
このSkillは以下の範囲をカバーする:
|
||||
|
||||
- 既存エージェントの確認と重複チェック
|
||||
- ユーザーとの対話による責任範囲情報の収集
|
||||
- 対象フェーズや役割の明確化
|
||||
- エージェントファイルの生成
|
||||
- プラグインアーキテクチャ規約の遵守確認
|
||||
- markdownlint検証の実施
|
||||
- ユーザーフィードバックの収集と反映
|
||||
|
||||
## ワークフロー
|
||||
|
||||
### フェーズ1: 既存エージェント確認
|
||||
|
||||
エージェント生成前に、既存のエージェントを確認し、重複を避ける。
|
||||
|
||||
**実施内容:**
|
||||
|
||||
1. プラグインディレクトリ内の既存エージェントを確認する
|
||||
2. 作成予定のエージェントと同じ責任範囲のエージェントが存在しないか確認する
|
||||
3. 作成予定のエージェント内容と重複する記述が他のエージェントに含まれていないか確認する
|
||||
4. 既存エージェントで代用できる場合はユーザーに提案する
|
||||
5. 重複が避けられない場合は、どの内容を削除すべきかユーザーと確認する
|
||||
|
||||
**確認対象:**
|
||||
|
||||
- プラグインディレクトリ内のagentsディレクトリ内のドキュメント
|
||||
|
||||
**質問例:**
|
||||
|
||||
```markdown
|
||||
【既存エージェント確認】
|
||||
プラグインディレクトリ内の既存エージェントを確認しました。
|
||||
以下のエージェントと責任範囲が重複する可能性があります：
|
||||
|
||||
- [既存エージェント名]: [既存エージェントの説明]
|
||||
|
||||
作成予定のエージェントから、これらの重複内容を除外してよろしいですか？
|
||||
```
|
||||
|
||||
**既存エージェントで代用可能な場合:**
|
||||
|
||||
```markdown
|
||||
【確認】
|
||||
作成予定のエージェントと同じ責任範囲のエージェントが既に存在します：
|
||||
- [既存エージェント名]: [既存エージェントの説明]
|
||||
|
||||
既存エージェントで十分な場合は、新規作成は不要です。
|
||||
それでも新規作成が必要ですか？必要な場合は、既存エージェントとの違いを教えてください。
|
||||
```
|
||||
|
||||
### フェーズ2: 情報収集
|
||||
|
||||
ユーザーとの対話を通じて、エージェントに必要な情報を収集する。
|
||||
|
||||
**実施内容:**
|
||||
|
||||
1. エージェントの目的と役割を確認する
|
||||
2. 責任範囲内の項目を把握する
|
||||
3. 責任範囲外の項目を把握する
|
||||
4. 対象フェーズや役割を明確にする
|
||||
5. 注意事項として記述すべき内容を確認する
|
||||
6. 使用可能なツール（tools）を確認する
|
||||
7. 表示色（color）の希望を確認する
|
||||
8. ユーザーとの対話時は、明確なタイトル付き質問、複数選択肢の提示、推奨オプションの明示を行う
|
||||
|
||||
**質問例:**
|
||||
|
||||
```markdown
|
||||
【責任範囲の確認】
|
||||
このエージェントが担当する責任範囲を確認します。以下のどの範囲ですか？
|
||||
|
||||
1. 特定フェーズ全体（要件定義、設計、実装など）【推奨】
|
||||
2. 特定領域全体（セキュリティ、パフォーマンス、品質管理など）
|
||||
3. 複数フェーズにまたがる横断的な役割
|
||||
```
|
||||
|
||||
### フェーズ3: コンテンツ生成
|
||||
|
||||
収集した情報を基に、エージェントファイルのコンテンツを生成する。
|
||||
|
||||
**実施内容:**
|
||||
|
||||
1. フロントマター（name, description, tools, model, color）を作成する
|
||||
2. 役割セクションを記述する
|
||||
3. 責任範囲を定義する（責任範囲内と責任範囲外に分けて記述）
|
||||
4. 注意事項を記述する
|
||||
|
||||
**フロントマターの作成:**
|
||||
|
||||
```markdown
|
||||
---
|
||||
name: エージェント名（ケバブケース、例: requirements-agent）
|
||||
description: エージェントの簡潔な説明（1行、50文字以内）
|
||||
tools: 使用可能な外部ツール（例: "*", "Read", "Write", "Bash"など）
|
||||
model: inherit（通常はinherit、特定のモデルを指定する場合のみ変更）
|
||||
color: 表示色（例: blue, green, redなど）
|
||||
---
|
||||
```
|
||||
|
||||
**役割の記述:**
|
||||
|
||||
- エージェントの目的と役割を明確に記述する
|
||||
- 担当する責任範囲の概要を説明する
|
||||
- 簡潔に1〜2段落で記述する
|
||||
|
||||
**責任範囲の定義:**
|
||||
|
||||
責任範囲は「責任範囲内」と「責任範囲外」の2つのサブセクションに分けて記述する。
|
||||
|
||||
**責任範囲内:**
|
||||
|
||||
- 太字の見出しと説明を組み合わせた形式で記述する
|
||||
- 「**[項目名]:** [説明]」の形式を使用する
|
||||
- 3〜5項目程度を記述する
|
||||
- エージェントが担当する具体的な範囲を明確にする
|
||||
|
||||
**責任範囲外:**
|
||||
|
||||
- 同様に太字の見出しと説明を組み合わせた形式で記述する
|
||||
- エージェントが担当しない範囲を明確にする
|
||||
- 混同しやすい範囲や誤解されやすい点を記述する
|
||||
- 2〜3項目程度を記述する
|
||||
|
||||
**注意事項の記述:**
|
||||
|
||||
- エージェントを使用する際の注意点を箇条書きで記述する
|
||||
- 制約事項、前提条件、重要な指針などを含める
|
||||
- 3〜5項目程度を記述する
|
||||
|
||||
**プラグインアーキテクチャ規約の遵守:**
|
||||
|
||||
生成するエージェントは、プラグインアーキテクチャ規約に従う必要がある（独立性の原則、汎用性の原則など）。
|
||||
|
||||
**重要な制約:**
|
||||
|
||||
- 他のエージェント、スキル、コマンドを参照しない
|
||||
- 固有名詞を含めない
|
||||
- 具体的なワークフローは記述しない（それはスキルの役割）
|
||||
- 責任範囲の定義に集中する
|
||||
|
||||
**重複最小化の確認:**
|
||||
|
||||
既存エージェントと重複する内容が含まれていないかを確認し、エージェント固有の内容のみを記述する。
|
||||
|
||||
### フェーズ4: 検証
|
||||
|
||||
生成したコンテンツを検証し、品質を確保する。
|
||||
|
||||
**実施内容:**
|
||||
|
||||
1. 設計原則の遵守を確認する
|
||||
2. markdownlint検証を実施する
|
||||
3. テンプレート構造の整合性を確認する
|
||||
4. ユーザーにプレビューを提示する
|
||||
5. フィードバックを収集する
|
||||
6. 必要に応じて修正する
|
||||
|
||||
**プラグインアーキテクチャ規約の確認:**
|
||||
|
||||
- プラグインアーキテクチャ規約に従っている
|
||||
- 既存エージェントと重複する内容が含まれていない
|
||||
- 他の要素（エージェント、スキル、コマンド）を参照していない
|
||||
- 固有名詞が使用されていない
|
||||
- 具体的なワークフローが含まれていない
|
||||
|
||||
## アウトプット
|
||||
|
||||
このスキルは以下を生成する:
|
||||
|
||||
- **エージェントファイル**: エージェントの定義ファイル（ファイル名＝エージェント名（ケバブケース））
|
||||
- フロントマター（name, description, tools, model, color）
|
||||
- 役割
|
||||
- 責任範囲（責任範囲内、責任範囲外）
|
||||
- 注意事項
|
||||
|
||||
## 想定されるエラーと対処法
|
||||
|
||||
### エラー1: 責任範囲が曖昧
|
||||
|
||||
**検出例:**
|
||||
|
||||
```markdown
|
||||
このエージェントは、いろいろな作業を担当する
|
||||
```
|
||||
|
||||
**対処法:**
|
||||
|
||||
- 具体的な表現を使用する（要件定義フェーズ全体、セキュリティ領域全体など）
|
||||
- 責任範囲を明確に列挙する
|
||||
- 「〜に対する責任を持つ」という表現を使用する
|
||||
|
||||
### エラー2: 具体的なワークフローが含まれている
|
||||
|
||||
**検出例:**
|
||||
|
||||
```markdown
|
||||
## ワークフロー
|
||||
|
||||
1. ユーザーから要件をヒアリングする
|
||||
2. 要件を整理する
|
||||
3. 要件定義書を作成する
|
||||
```
|
||||
|
||||
**対処法:**
|
||||
|
||||
- ワークフローは削除する（それはスキルの役割）
|
||||
- 責任範囲の定義に集中する
|
||||
- 「要件定義フェーズ全体に対する責任を持つ」という表現に置き換える
|
||||
|
||||
### エラー3: 他の要素を参照している
|
||||
|
||||
**検出例:**
|
||||
|
||||
```markdown
|
||||
このエージェントは、requirements-structurer スキルを使用して要件を整理する
|
||||
```
|
||||
|
||||
**対処法:**
|
||||
|
||||
- 他の要素への参照を削除する
|
||||
- 汎用的な表現に置き換える（「要件を整理する責任を持つ」など）
|
||||
|
||||
## ベストプラクティス
|
||||
|
||||
- 責任範囲は3〜5項目に抑える（多すぎると複雑になる）
|
||||
- 具体的なワークフローは記述しない（それはスキルの役割）
|
||||
- 他の要素（エージェント、スキル、コマンド）を参照しない
|
||||
- 固有名詞を使用しない
|
||||
- markdownlint検証は必ず実施する
|
||||
- ユーザーフィードバックを反映して改善する
|
||||
|
||||
## チェックリスト
|
||||
|
||||
### 既存エージェント確認完了時
|
||||
|
||||
- [ ] プラグインディレクトリ内の既存エージェントを確認した
|
||||
- [ ] 同じ責任範囲のエージェントが存在しないことを確認した
|
||||
- [ ] 重複する内容が他のエージェントに含まれていないことを確認した
|
||||
- [ ] 既存エージェントで代用できない理由が明確である
|
||||
- [ ] 重複する内容を除外する方針を決定した
|
||||
|
||||
### 情報収集完了時
|
||||
|
||||
- [ ] エージェントの目的と役割が明確になっている
|
||||
- [ ] 責任範囲内の項目を把握している
|
||||
- [ ] 責任範囲外の項目を把握している
|
||||
- [ ] 対象フェーズや役割が明確になっている
|
||||
- [ ] 注意事項として記述すべき内容が確認されている
|
||||
- [ ] 使用可能なツール（tools）が確認されている
|
||||
|
||||
### コンテンツ生成完了時
|
||||
|
||||
- [ ] フロントマター（name, description, tools, model, color）が記述されている
|
||||
- [ ] 役割が簡潔に記述されている
|
||||
- [ ] 責任範囲内が明確に定義されている（3〜5項目）
|
||||
- [ ] 責任範囲外が明確に定義されている（2〜3項目）
|
||||
- [ ] 注意事項が記述されている（3〜5項目）
|
||||
- [ ] 太字の見出しと説明の形式が正しく使用されている
|
||||
- [ ] プラグインアーキテクチャ規約に従っている
|
||||
- [ ] 既存エージェントと重複する内容が含まれていない
|
||||
- [ ] 他の要素（エージェント、スキル、コマンド）を参照していない
|
||||
- [ ] 固有名詞が使用されていない
|
||||
- [ ] 具体的なワークフローが含まれていない
|
||||
|
||||
### 検証完了時
|
||||
|
||||
- [ ] プラグインアーキテクチャ規約の遵守を確認した
|
||||
- [ ] markdownlint検証を実施した（エラーなし）
|
||||
- [ ] テンプレート構造の整合性を確認した
|
||||
- [ ] ユーザーにプレビューを提示した
|
||||
- [ ] フィードバックを収集した
|
||||
- [ ] 必要な修正を完了した
|
||||
|
||||
### 最終確認
|
||||
|
||||
- [ ] エージェントファイルが生成されている
|
||||
- [ ] すべてのセクションが適切に記述されている
|
||||
- [ ] プラグインアーキテクチャ規約が遵守されている
|
||||
- [ ] markdownlint検証に合格している
|
||||
- [ ] ユーザーの承認を得ている
|
||||
29
skills/agent-generator/templates/agent-template.md
Normal file
29
skills/agent-generator/templates/agent-template.md
Normal file
@@ -0,0 +1,29 @@
|
||||
---
|
||||
name: [名前]
|
||||
description: [説明]
|
||||
tools: [使用可能な外部ツール]
|
||||
model: inherit
|
||||
color: [表示色]
|
||||
---
|
||||
# [エージェント名]
|
||||
|
||||
## 役割
|
||||
|
||||
[役割を記述]
|
||||
|
||||
## 責任範囲
|
||||
|
||||
### 責任範囲内
|
||||
|
||||
- **[項目1]:** [説明]
|
||||
- **[項目2]:** [説明]
|
||||
|
||||
### 責任範囲外
|
||||
|
||||
- **[項目1]:** [説明]
|
||||
- **[項目2]:** [説明]
|
||||
|
||||
## 注意事項
|
||||
|
||||
- [注意事項1]
|
||||
- [注意事項2]
|
||||
390
skills/command-generator/SKILL.md
Normal file
390
skills/command-generator/SKILL.md
Normal file
@@ -0,0 +1,390 @@
|
||||
---
|
||||
name: command-generator
|
||||
description: エージェントとスキルの組み合わせから、Commandのマークダウンファイルを生成する。コマンド作成時、スラッシュコマンド定義時、またはユーザーがCommand生成、スラッシュコマンド、コマンド定義、実行フローに言及した際に使用する。
|
||||
---
|
||||
|
||||
# Command Generator
|
||||
|
||||
## 概要
|
||||
|
||||
このSkillは、ユーザーが提供するエージェント、スキル、実行フローの情報を基に、Commandのマークダウンファイルを生成する。ユーザーとの対話を通じて必要な情報を収集し、標準化されたコマンドのドキュメントを作成する。
|
||||
|
||||
## 責任範囲
|
||||
|
||||
このSkillは以下の範囲をカバーする:
|
||||
|
||||
- 既存コマンドの確認と重複チェック
|
||||
- ユーザーとの対話によるコマンド情報の収集
|
||||
- 使用するエージェントとスキルの明確化
|
||||
- 実行フローとデータ受け渡しの定義
|
||||
- 成果物の出力先とファイル構成の定義
|
||||
- コマンドファイルの生成
|
||||
- プラグインアーキテクチャ規約の遵守確認
|
||||
- markdownlint検証の実施
|
||||
- ユーザーフィードバックの収集と反映
|
||||
|
||||
## ワークフロー
|
||||
|
||||
### フェーズ1: 既存コマンド確認
|
||||
|
||||
コマンド生成前に、既存のコマンドを確認し、重複を避ける。
|
||||
|
||||
**実施内容:**
|
||||
|
||||
1. プラグインディレクトリ内の既存コマンドを確認する
|
||||
2. 作成予定のコマンドと同じ機能のコマンドが存在しないか確認する
|
||||
3. 作成予定のコマンド内容と重複する記述が他のコマンドに含まれていないか確認する
|
||||
4. 既存コマンドで代用できる場合はユーザーに提案する
|
||||
5. 重複が避けられない場合は、どの内容を削除すべきかユーザーと確認する
|
||||
|
||||
**確認対象:**
|
||||
|
||||
- プラグインディレクトリ内のcommandsディレクトリ内のドキュメント
|
||||
|
||||
**質問例:**
|
||||
|
||||
```markdown
|
||||
【既存コマンド確認】
|
||||
プラグインディレクトリ内の既存コマンドを確認しました。
|
||||
以下のコマンドと機能が重複する可能性があります：
|
||||
|
||||
- [既存コマンド名]: [既存コマンドの説明]
|
||||
|
||||
作成予定のコマンドから、これらの重複内容を除外してよろしいですか？
|
||||
```
|
||||
|
||||
**既存コマンドで代用可能な場合:**
|
||||
|
||||
```markdown
|
||||
【確認】
|
||||
作成予定のコマンドと同じ機能のコマンドが既に存在します：
|
||||
- [既存コマンド名]: [既存コマンドの説明]
|
||||
|
||||
既存コマンドで十分な場合は、新規作成は不要です。
|
||||
それでも新規作成が必要ですか？必要な場合は、既存コマンドとの違いを教えてください。
|
||||
```
|
||||
|
||||
### フェーズ2: 情報収集
|
||||
|
||||
ユーザーとの対話を通じて、コマンドに必要な情報を収集する。
|
||||
|
||||
**実施内容:**
|
||||
|
||||
1. コマンドの目的と機能を確認する
|
||||
2. 使用するエージェントを特定する
|
||||
3. 使用するスキルを特定する
|
||||
4. スキルの実行順序を確認する
|
||||
5. スキル間のデータ受け渡しを確認する
|
||||
6. 成果物の出力先とファイル構成を確認する
|
||||
7. 前提条件や制約事項を確認する
|
||||
8. ユーザーとの対話時は、明確なタイトル付き質問、複数選択肢の提示、推奨オプションの明示を行う
|
||||
|
||||
**質問例:**
|
||||
|
||||
```markdown
|
||||
【使用するエージェントの確認】
|
||||
このコマンドが使用するエージェントを確認します。以下のどれですか？
|
||||
|
||||
1. 特定のエージェント（要件定義、設計、実装など）【推奨】
|
||||
2. 複数のエージェント（フェーズをまたぐ場合）
|
||||
3. エージェントなし（スキルのみ実行）
|
||||
```
|
||||
|
||||
```markdown
|
||||
【実行フローの確認】
|
||||
スキルの実行順序を確認します。以下のどの方式ですか？
|
||||
|
||||
1. 順次実行（スキルを1つずつ順番に実行）【推奨】
|
||||
2. 並列実行（複数のスキルを同時に実行）
|
||||
3. 条件分岐あり（条件によって実行するスキルが変わる）
|
||||
```
|
||||
|
||||
### フェーズ3: コンテンツ生成
|
||||
|
||||
収集した情報を基に、コマンドファイルのコンテンツを生成する。
|
||||
|
||||
**実施内容:**
|
||||
|
||||
1. フロントマター（name, description）を作成する
|
||||
2. 概要セクションを記述する
|
||||
3. 使用するエージェントを記述する
|
||||
4. 使用するスキルをリスト化する
|
||||
5. 実行フローを記述する
|
||||
6. 成果物のセクションを記述する
|
||||
7. チェックリストを作成する（該当する場合）
|
||||
|
||||
**フロントマターの作成:**
|
||||
|
||||
```markdown
|
||||
---
|
||||
name: コマンド名（ケバブケース、例: requirements, design）
|
||||
description: コマンドの簡潔な説明（1行、50文字以内）
|
||||
---
|
||||
```
|
||||
|
||||
**概要の記述:**
|
||||
|
||||
- コマンドの目的と機能を明確に記述する
|
||||
- どのフェーズで使用するかを説明する
|
||||
- 簡潔に1〜2段落で記述する
|
||||
|
||||
**使用するエージェントの記述:**
|
||||
|
||||
- コマンドが使用するエージェントを明記する
|
||||
- エージェントの役割を簡潔に説明する
|
||||
|
||||
**使用するスキルの記述:**
|
||||
|
||||
- コマンドが使用するスキルをリスト化する
|
||||
- 各スキルの役割を簡潔に説明する
|
||||
- 実行順序がわかるようにする
|
||||
|
||||
**実行フローの記述:**
|
||||
|
||||
- スキルの実行順序を明確に記述する
|
||||
- 各ステップで使用するスキルを明示的にリスト化する
|
||||
- 条件分岐がある場合はその条件を明記する
|
||||
- 番号付きリストを活用する
|
||||
|
||||
**重要: 実行フローでのスキル参照方法:**
|
||||
|
||||
各ステップで使用するスキルは、以下の形式で明示的にリスト化する。括弧書きでスキルを参照してはいけない。
|
||||
|
||||
良い例:
|
||||
|
||||
```markdown
|
||||
## 実行フロー
|
||||
|
||||
1. plugin-development-agentが以下のスキルを使用して、既存エージェントを確認し、重複を避ける
|
||||
- agent-generator（エージェント確認）
|
||||
- plugin-architecture-convention（アーキテクチャ規約遵守）
|
||||
|
||||
2. plugin-development-agentが以下のスキルを使用して、ユーザーとの対話を通じて情報を収集する
|
||||
- agent-generator（情報収集）
|
||||
- interaction-guidelines（対話パターン）
|
||||
|
||||
3. plugin-development-agentが以下のスキルを使用して、コンテンツを生成する
|
||||
- agent-generator（コンテンツ生成）
|
||||
- element-definition-convention（定義ルール遵守）
|
||||
```
|
||||
|
||||
悪い例（使用してはいけない形式）:
|
||||
|
||||
```markdown
|
||||
## 実行フロー
|
||||
|
||||
1. plugin-development-agentがagent-generatorスキルを使用して、既存エージェントを確認し、重複を避ける（plugin-architecture-conventionに従う）
|
||||
2. plugin-development-agentがagent-generatorスキルを使用して、ユーザーとの対話を通じて情報を収集する（interaction-guidelinesに従う）
|
||||
```
|
||||
|
||||
**理由:**
|
||||
|
||||
- 括弧書き形式では、agent-generatorスキルが他のスキルを参照しているように見える
|
||||
- スキルの独立性原則に反する可能性がある
|
||||
- コマンドが依存関係を管理する責任が不明確になる
|
||||
|
||||
**成果物の記述:**
|
||||
|
||||
- コマンド実行後の出力先を明記する
|
||||
- ファイル構成を記述する
|
||||
- ファイルの内容を簡潔に説明する
|
||||
|
||||
**チェックリストの作成（該当する場合）:**
|
||||
|
||||
- コマンド実行前のチェックリスト
|
||||
- コマンド実行後のチェックリスト
|
||||
- 具体的で検証可能な項目を記述する
|
||||
|
||||
**プラグインアーキテクチャ規約の遵守:**
|
||||
|
||||
生成するコマンドは、プラグインアーキテクチャ規約に従う必要がある（依存関係の管理、汎用性の原則など）。
|
||||
|
||||
**重要な制約:**
|
||||
|
||||
- コマンドが依存関係を管理する責任を持つ
|
||||
- 固有名詞を含めない
|
||||
- エージェントとスキルの組み合わせを明確に定義する
|
||||
- 成果物の出力先を具体的に記述する
|
||||
|
||||
**重複最小化の確認:**
|
||||
|
||||
既存コマンドと重複する内容が含まれていないかを確認し、コマンド固有の内容のみを記述する。
|
||||
|
||||
### フェーズ4: 検証
|
||||
|
||||
生成したコンテンツを検証し、品質を確保する。
|
||||
|
||||
**実施内容:**
|
||||
|
||||
1. 設計原則の遵守を確認する
|
||||
2. markdownlint検証を実施する
|
||||
3. テンプレート構造の整合性を確認する
|
||||
4. ユーザーにプレビューを提示する
|
||||
5. フィードバックを収集する
|
||||
6. 必要に応じて修正する
|
||||
|
||||
**プラグインアーキテクチャ規約の確認:**
|
||||
|
||||
- プラグインアーキテクチャ規約に従っている
|
||||
- 既存コマンドと重複する内容が含まれていない
|
||||
- 依存関係が明確に定義されている
|
||||
- 固有名詞が使用されていない
|
||||
- エージェントとスキルの組み合わせが明確である
|
||||
|
||||
## アウトプット
|
||||
|
||||
このスキルは以下を生成する:
|
||||
|
||||
- **コマンドファイル**: コマンドの定義ファイル（ファイル名＝コマンド名（ケバブケース））
|
||||
- フロントマター（name, description）
|
||||
- 概要
|
||||
- 使用するエージェント
|
||||
- 使用するスキル
|
||||
- 実行フロー
|
||||
- 成果物
|
||||
- チェックリスト（該当する場合）
|
||||
|
||||
## 想定されるエラーと対処法
|
||||
|
||||
### エラー1: 使用するスキルが曖昧
|
||||
|
||||
**検出例:**
|
||||
|
||||
```markdown
|
||||
このコマンドは、いくつかのスキルを使用する
|
||||
```
|
||||
|
||||
**対処法:**
|
||||
|
||||
- 使用するスキルを具体的にリスト化する
|
||||
- 各スキルの役割を明記する
|
||||
- 実行順序を明確にする
|
||||
|
||||
### エラー2: 実行フローが不明確
|
||||
|
||||
**検出例:**
|
||||
|
||||
```markdown
|
||||
## 実行フロー
|
||||
|
||||
スキルを実行する
|
||||
```
|
||||
|
||||
**対処法:**
|
||||
|
||||
- スキルの実行順序を番号付きで記述する
|
||||
- 各ステップで使用するスキルを明示的にリスト化する
|
||||
- 条件分岐がある場合はその条件を記述する
|
||||
|
||||
### エラー3: 実行フローで括弧書きでスキルを参照している
|
||||
|
||||
**検出例:**
|
||||
|
||||
```markdown
|
||||
## 実行フロー
|
||||
|
||||
1. plugin-development-agentがagent-generatorスキルを使用して、既存エージェントを確認し、重複を避ける（plugin-architecture-conventionに従う）
|
||||
2. plugin-development-agentがagent-generatorスキルを使用して、ユーザーとの対話を通じて情報を収集する（interaction-guidelinesに従う）
|
||||
```
|
||||
|
||||
**問題点:**
|
||||
|
||||
- agent-generatorスキルが他のスキルを参照しているように見える
|
||||
- スキルの独立性原則に反する可能性がある
|
||||
- コマンドが依存関係を管理する責任が不明確になる
|
||||
|
||||
**対処法:**
|
||||
|
||||
各ステップで使用するスキルを明示的にリスト化する:
|
||||
|
||||
```markdown
|
||||
## 実行フロー
|
||||
|
||||
1. plugin-development-agentが以下のスキルを使用して、既存エージェントを確認し、重複を避ける
|
||||
- agent-generator（エージェント確認）
|
||||
- plugin-architecture-convention（アーキテクチャ規約遵守）
|
||||
|
||||
2. plugin-development-agentが以下のスキルを使用して、ユーザーとの対話を通じて情報を収集する
|
||||
- agent-generator（情報収集）
|
||||
- interaction-guidelines（対話パターン）
|
||||
```
|
||||
|
||||
### エラー4: 成果物の出力先が曖昧
|
||||
|
||||
**検出例:**
|
||||
|
||||
```markdown
|
||||
## 成果物
|
||||
|
||||
ドキュメントを生成する
|
||||
```
|
||||
|
||||
**対処法:**
|
||||
|
||||
- 具体的なファイルパスを記述する
|
||||
- ファイル構成を明記する
|
||||
- ファイルの内容を簡潔に説明する
|
||||
|
||||
## ベストプラクティス
|
||||
|
||||
- 使用するスキルは3〜5個程度に抑える（多すぎると複雑になる）
|
||||
- 実行フローは明確で理解しやすくする
|
||||
- **実行フローでは各ステップで使用するスキルを明示的にリスト化する（括弧書きで参照しない）**
|
||||
- 成果物の出力先を具体的に記述する
|
||||
- チェックリストは具体的で検証可能な項目にする
|
||||
- コマンドが全てのスキルの依存関係を管理する責任を持つことを明確にする
|
||||
- markdownlint検証は必ず実施する
|
||||
- ユーザーフィードバックを反映して改善する
|
||||
|
||||
## チェックリスト
|
||||
|
||||
### 既存コマンド確認完了時
|
||||
|
||||
- [ ] プラグインディレクトリ内の既存コマンドを確認した
|
||||
- [ ] 同じ機能のコマンドが存在しないことを確認した
|
||||
- [ ] 重複する内容が他のコマンドに含まれていないことを確認した
|
||||
- [ ] 既存コマンドで代用できない理由が明確である
|
||||
- [ ] 重複する内容を除外する方針を決定した
|
||||
|
||||
### 情報収集完了時
|
||||
|
||||
- [ ] コマンドの目的と機能が明確になっている
|
||||
- [ ] 使用するエージェントが特定されている
|
||||
- [ ] 使用するスキルが特定されている
|
||||
- [ ] スキルの実行順序が確認されている
|
||||
- [ ] スキル間のデータ受け渡しが確認されている
|
||||
- [ ] 成果物の出力先とファイル構成が確認されている
|
||||
- [ ] 前提条件や制約事項が確認されている
|
||||
|
||||
### コンテンツ生成完了時
|
||||
|
||||
- [ ] フロントマター（name, description）が記述されている
|
||||
- [ ] 概要が簡潔に記述されている
|
||||
- [ ] 使用するエージェントが明記されている
|
||||
- [ ] 使用するスキルがリスト化されている
|
||||
- [ ] 実行フローが明確に記述されている
|
||||
- [ ] 実行フローで各ステップが使用するスキルが明示的にリスト化されている
|
||||
- [ ] 実行フローで括弧書きでスキルを参照していない
|
||||
- [ ] 成果物の出力先とファイル構成が記述されている
|
||||
- [ ] チェックリストが作成されている（該当する場合）
|
||||
- [ ] プラグインアーキテクチャ規約に従っている
|
||||
- [ ] 既存コマンドと重複する内容が含まれていない
|
||||
- [ ] 依存関係が明確に定義されている
|
||||
- [ ] 固有名詞が使用されていない
|
||||
|
||||
### 検証完了時
|
||||
|
||||
- [ ] プラグインアーキテクチャ規約の遵守を確認した
|
||||
- [ ] markdownlint検証を実施した（エラーなし）
|
||||
- [ ] テンプレート構造の整合性を確認した
|
||||
- [ ] ユーザーにプレビューを提示した
|
||||
- [ ] フィードバックを収集した
|
||||
- [ ] 必要な修正を完了した
|
||||
|
||||
### 最終確認
|
||||
|
||||
- [ ] コマンドファイルが生成されている
|
||||
- [ ] すべてのセクションが適切に記述されている
|
||||
- [ ] プラグインアーキテクチャ規約が遵守されている
|
||||
- [ ] markdownlint検証に合格している
|
||||
- [ ] ユーザーの承認を得ている
|
||||
46
skills/command-generator/templates/command-template.md
Normal file
46
skills/command-generator/templates/command-template.md
Normal file
@@ -0,0 +1,46 @@
|
||||
---
|
||||
name: [コマンド名]
|
||||
description: [説明]
|
||||
---
|
||||
|
||||
# [コマンド名]
|
||||
|
||||
## 概要
|
||||
|
||||
[コマンドの目的と機能を記述]
|
||||
|
||||
## 使用するエージェント
|
||||
|
||||
- **[エージェント名]:** [エージェントの役割]
|
||||
|
||||
## 使用するスキル
|
||||
|
||||
1. **[スキル名1]:** [スキルの役割]
|
||||
2. **[スキル名2]:** [スキルの役割]
|
||||
3. **[スキル名3]:** [スキルの役割]
|
||||
|
||||
## 実行フロー
|
||||
|
||||
1. [エージェント名]が以下のスキルを使用して、[作業内容1]を実行する
|
||||
- [スキル名1]（[役割1]）
|
||||
- [スキル名2]（[役割2]）
|
||||
|
||||
2. [エージェント名]が以下のスキルを使用して、[作業内容2]を実行する
|
||||
- [スキル名3]（[役割3]）
|
||||
- [スキル名4]（[役割4]）
|
||||
|
||||
3. [エージェント名]が以下のスキルを使用して、[作業内容3]を実行する
|
||||
- [スキル名5]（[役割5]）
|
||||
|
||||
## 成果物
|
||||
|
||||
**出力先:**
|
||||
|
||||
- `[ファイルパス1]`: [ファイルの説明]
|
||||
- `[ファイルパス2]`: [ファイルの説明]
|
||||
|
||||
**ファイル構成:**
|
||||
|
||||
```text
|
||||
[ディレクトリ構造]
|
||||
```
|
||||
287
skills/convention-skill-generator/SKILL.md
Normal file
287
skills/convention-skill-generator/SKILL.md
Normal file
@@ -0,0 +1,287 @@
|
||||
---
|
||||
name: convention-skill-generator
|
||||
description: ユーザーの規約・ガイドラインから、Convention Skillのマークダウンファイルを生成する。規約スキル作成時、ガイドライン文書化時、またはユーザーがConvention Skill、コーディング規約、ガイドライン定義、標準化に言及した際に使用する。
|
||||
---
|
||||
|
||||
# Convention Skill Generator
|
||||
|
||||
## 概要
|
||||
|
||||
このSkillは、ユーザーが提供する規約・ガイドライン情報を基に、Convention Skillのマークダウンファイル（SKILL.md）を生成する。ユーザーとの対話を通じて必要な情報を収集し、適切なテンプレートを選択して、標準化されたコンベンションスキルのドキュメントを作成する。
|
||||
|
||||
## 責任範囲
|
||||
|
||||
このSkillは以下の範囲をカバーする:
|
||||
|
||||
- 既存スキルの確認と重複チェック
|
||||
- ユーザーとの対話による規約・ガイドライン情報の収集
|
||||
- 規約のカテゴリ分類と整理
|
||||
- 良い例/悪い例の作成支援
|
||||
- テンプレート（simple版/full版）の選択
|
||||
- SKILL.mdファイルの生成
|
||||
- プラグインアーキテクチャ規約の遵守確認
|
||||
- markdownlint検証の実施
|
||||
- ユーザーフィードバックの収集と反映
|
||||
|
||||
## ワークフロー
|
||||
|
||||
### フェーズ1: 既存スキル確認
|
||||
|
||||
スキル生成前に、既存のスキルを確認し、重複を避ける。
|
||||
|
||||
**実施内容:**
|
||||
|
||||
1. プラグインディレクトリ内の既存スキルを確認する
|
||||
2. 作成予定のスキルと同じ目的のスキルが存在しないか確認する
|
||||
3. 作成予定のスキル内容と重複する記述が他のスキルに含まれていないか確認する
|
||||
4. 既存スキルで代用できる場合はユーザーに提案する
|
||||
5. 重複が避けられない場合は、どの内容を削除すべきかユーザーと確認する
|
||||
|
||||
**確認対象:**
|
||||
|
||||
- プラグインディレクトリ内のskillsディレクトリ内のドキュメント
|
||||
|
||||
**質問例:**
|
||||
|
||||
```markdown
|
||||
【既存スキル確認】
|
||||
プラグインディレクトリ内の既存スキルを確認しました。
|
||||
以下のスキルと内容が重複する可能性があります：
|
||||
|
||||
- [既存スキル名]: [既存スキルの説明]
|
||||
|
||||
作成予定のスキルから、これらの重複内容を除外してよろしいですか？
|
||||
```
|
||||
|
||||
**既存スキルで代用可能な場合:**
|
||||
|
||||
```markdown
|
||||
【確認】
|
||||
作成予定のスキルと同じ目的のスキルが既に存在します：
|
||||
- [既存スキル名]: [既存スキルの説明]
|
||||
|
||||
既存スキルで十分な場合は、新規作成は不要です。
|
||||
それでも新規作成が必要ですか？必要な場合は、既存スキルとの違いを教えてください。
|
||||
```
|
||||
|
||||
### フェーズ2: 情報収集
|
||||
|
||||
ユーザーとの対話を通じて、コンベンションスキルに必要な情報を収集する。
|
||||
|
||||
**実施内容:**
|
||||
|
||||
1. スキルの目的と対象範囲を確認する
|
||||
2. 規約・ガイドラインの全体像を把握する
|
||||
3. カテゴリ分類の可能性を検討する
|
||||
4. 良い例/悪い例の必要性を確認する
|
||||
5. チェックリストの粒度を確認する
|
||||
6. ユーザーとの対話時は、明確なタイトル付き質問、複数選択肢の提示、推奨オプションの明示を行う
|
||||
|
||||
### フェーズ3: テンプレート選択
|
||||
|
||||
収集した情報を基に、適切なテンプレート（simple版/full版）を選択する。
|
||||
|
||||
**実施内容:**
|
||||
|
||||
1. スキルの複雑度を評価する
|
||||
2. テンプレートの選択肢（simple版/full版）を提示する
|
||||
3. 推奨テンプレートを明示してユーザーに確認する
|
||||
|
||||
**テンプレート選択基準:**
|
||||
|
||||
- simple版: カテゴリが2〜3個程度のシンプルな規約
|
||||
- full版: カテゴリが4個以上の複雑な規約、良い例/悪い例が必要
|
||||
|
||||
### フェーズ4: コンテンツ生成
|
||||
|
||||
選択したテンプレートを基に、SKILL.mdファイルのコンテンツを生成する。
|
||||
|
||||
**実施内容:**
|
||||
|
||||
1. フロントマター（name, description）を作成する
|
||||
2. 概要セクションを記述する
|
||||
3. 責任範囲を定義する
|
||||
4. 基本方針を記述する（該当する場合）
|
||||
5. カテゴリ別の規約を記述する
|
||||
6. 良い例/悪い例を記述する（full版の場合）
|
||||
7. チェックリストを作成する
|
||||
|
||||
**フロントマターの作成:**
|
||||
|
||||
```markdown
|
||||
---
|
||||
name: スキル名（ケバブケース、例: coding-conventions）
|
||||
description: スキルの簡潔な説明（1行、50文字以内）
|
||||
---
|
||||
```
|
||||
|
||||
**概要の記述:**
|
||||
|
||||
- スキルの目的を明確に記述する
|
||||
- 定義する規約・ガイドラインの範囲を説明する
|
||||
- 簡潔に1〜2段落で記述する
|
||||
|
||||
**責任範囲の定義:**
|
||||
|
||||
- 箇条書きで3〜5項目を記述する
|
||||
- 「〜の定義」「〜のガイドライン」「〜のルール」のような表現を使用する
|
||||
- スキルがカバーする範囲を明確にする
|
||||
|
||||
**カテゴリ別の規約記述:**
|
||||
|
||||
各カテゴリに以下を含める:
|
||||
|
||||
- カテゴリ名（例: 命名規則、コードレイアウト）
|
||||
- カテゴリの説明（1〜2行）
|
||||
- 具体的なルール（箇条書き）
|
||||
- 良い例/悪い例（full版の場合）
|
||||
|
||||
**良い例/悪い例の作成（full版の場合）:**
|
||||
|
||||
```markdown
|
||||
良い例:
|
||||
|
||||
```language
|
||||
[推奨される記述例]
|
||||
```
|
||||
|
||||
悪い例:
|
||||
|
||||
```language
|
||||
[避けるべき記述例]
|
||||
```
|
||||
```
|
||||
|
||||
**チェックリストの作成:**
|
||||
|
||||
- カテゴリごとのチェックリスト
|
||||
- 最終確認チェックリスト
|
||||
- 具体的で検証可能な項目を記述する
|
||||
|
||||
**プラグインアーキテクチャ規約の遵守:**
|
||||
|
||||
生成するスキルは、プラグインアーキテクチャ規約に従う必要がある（独立性の原則、汎用性の原則、単一責任の原則など）。
|
||||
|
||||
**重複最小化の確認:**
|
||||
|
||||
既存スキルと重複する内容が含まれていないかを確認し、スキル固有の内容のみを記述する。
|
||||
|
||||
### フェーズ5: 検証
|
||||
|
||||
生成したコンテンツを検証し、品質を確保する。
|
||||
|
||||
**実施内容:**
|
||||
|
||||
1. 設計原則の遵守を確認する
|
||||
2. markdownlint検証を実施する
|
||||
3. テンプレート構造の整合性を確認する
|
||||
4. ユーザーにプレビューを提示する
|
||||
5. フィードバックを収集する
|
||||
6. 必要に応じて修正する
|
||||
|
||||
**プラグインアーキテクチャ規約の確認:**
|
||||
|
||||
- プラグインアーキテクチャ規約に従っている
|
||||
- 既存スキルと重複する内容が含まれていない
|
||||
|
||||
## アウトプット
|
||||
|
||||
このスキルは以下を生成する:
|
||||
|
||||
- **SKILL.md**: コンベンションスキルの定義ファイル
|
||||
- フロントマター（name, description）
|
||||
- 概要、責任範囲、基本方針
|
||||
- カテゴリ別の規約・ガイドライン
|
||||
- 良い例/悪い例（full版の場合）
|
||||
- チェックリスト
|
||||
|
||||
## 想定されるエラーと対処法
|
||||
|
||||
### エラー1: 責任範囲が曖昧
|
||||
|
||||
**検出例:**
|
||||
|
||||
```markdown
|
||||
このSkillは、いろいろな規約を定義する
|
||||
```
|
||||
|
||||
**対処法:**
|
||||
|
||||
- 具体的な表現を使用する（命名規則、フォーマット、セキュリティなど）
|
||||
- 責任範囲を明確に列挙する
|
||||
|
||||
### エラー2: 良い例/悪い例が不明確
|
||||
|
||||
**検出例:**
|
||||
|
||||
```markdown
|
||||
良い例: これ
|
||||
悪い例: あれ
|
||||
```
|
||||
|
||||
**対処法:**
|
||||
|
||||
- 具体的なコード例やテキスト例を記述する
|
||||
- なぜ良い/悪いのか理由を簡潔に説明する
|
||||
|
||||
## ベストプラクティス
|
||||
|
||||
- カテゴリは2〜5個に抑える（多すぎると複雑になる）
|
||||
- 各カテゴリのルールは3〜5項目程度にする
|
||||
- 良い例/悪い例は実用的で理解しやすいものを記述する（full版の場合）
|
||||
- チェックリストは具体的で検証可能な項目にする
|
||||
- markdownlint検証は必ず実施する
|
||||
- ユーザーフィードバックを反映して改善する
|
||||
|
||||
## チェックリスト
|
||||
|
||||
### 既存スキル確認完了時
|
||||
|
||||
- [ ] プラグインディレクトリ内の既存スキルを確認した
|
||||
- [ ] 同じ目的のスキルが存在しないことを確認した
|
||||
- [ ] 重複する内容が他のスキルに含まれていないことを確認した
|
||||
- [ ] 既存スキルで代用できない理由が明確である
|
||||
- [ ] 重複する内容を除外する方針を決定した
|
||||
|
||||
### 情報収集完了時
|
||||
|
||||
- [ ] スキルの目的が明確になっている
|
||||
- [ ] 規約・ガイドラインの全体像を把握している
|
||||
- [ ] カテゴリ分類の方針が決まっている
|
||||
- [ ] 良い例/悪い例の必要性が確認されている
|
||||
- [ ] チェックリストの粒度が確認されている
|
||||
|
||||
### テンプレート選択完了時
|
||||
|
||||
- [ ] スキルの複雑度を評価した
|
||||
- [ ] テンプレート（simple/full）を選択した
|
||||
- [ ] ユーザーの確認を得た
|
||||
|
||||
### コンテンツ生成完了時
|
||||
|
||||
- [ ] フロントマター（name, description）が記述されている
|
||||
- [ ] 概要が簡潔に記述されている
|
||||
- [ ] 責任範囲が明確に定義されている
|
||||
- [ ] カテゴリ別の規約が記述されている
|
||||
- [ ] 各カテゴリに具体的なルールが含まれている
|
||||
- [ ] 良い例/悪い例が記述されている（full版の場合）
|
||||
- [ ] チェックリストが作成されている
|
||||
- [ ] プラグインアーキテクチャ規約に従っている
|
||||
- [ ] 既存スキルと重複する内容が含まれていない
|
||||
|
||||
### 検証完了時
|
||||
|
||||
- [ ] プラグインアーキテクチャ規約の遵守を確認した
|
||||
- [ ] markdownlint検証を実施した（エラーなし）
|
||||
- [ ] テンプレート構造の整合性を確認した
|
||||
- [ ] ユーザーにプレビューを提示した
|
||||
- [ ] フィードバックを収集した
|
||||
- [ ] 必要な修正を完了した
|
||||
|
||||
### 最終確認
|
||||
|
||||
- [ ] SKILL.mdファイルが生成されている
|
||||
- [ ] すべてのセクションが適切に記述されている
|
||||
- [ ] プラグインアーキテクチャ規約が遵守されている
|
||||
- [ ] markdownlint検証に合格している
|
||||
- [ ] ユーザーの承認を得ている
|
||||
@@ -0,0 +1,82 @@
|
||||
---
|
||||
name: [skill-name]
|
||||
description: [このConvention Skillが定義する規約・ガイドラインを簡潔に説明]
|
||||
---
|
||||
|
||||
# [Convention Skill名]
|
||||
|
||||
## 概要
|
||||
|
||||
[概要を記述]
|
||||
|
||||
## 責任範囲
|
||||
|
||||
このSkillは以下の範囲をカバーします:
|
||||
|
||||
- [責任範囲の内容1]
|
||||
- [責任範囲の内容2]
|
||||
- [責任範囲の内容3]
|
||||
|
||||
## [カテゴリ1]
|
||||
|
||||
### [規約項目1-1]
|
||||
|
||||
- [ルールの記述]
|
||||
|
||||
良い例:
|
||||
|
||||
```text
|
||||
[推奨例]
|
||||
```
|
||||
|
||||
悪い例:
|
||||
|
||||
```text
|
||||
[非推奨例]
|
||||
```
|
||||
|
||||
### [規約項目1-2]
|
||||
|
||||
- [ルールの記述]
|
||||
|
||||
良い例:
|
||||
|
||||
```text
|
||||
[推奨例]
|
||||
```
|
||||
|
||||
悪い例:
|
||||
|
||||
```text
|
||||
[非推奨例]
|
||||
```
|
||||
|
||||
## [カテゴリ2]
|
||||
|
||||
### [規約項目2-1]
|
||||
|
||||
- [ルールの記述]
|
||||
|
||||
良い例:
|
||||
|
||||
```text
|
||||
[推奨例]
|
||||
```
|
||||
|
||||
悪い例:
|
||||
|
||||
```text
|
||||
[非推奨例]
|
||||
```
|
||||
|
||||
## チェックリスト
|
||||
|
||||
### [カテゴリ1]チェックリスト
|
||||
|
||||
- [ ] [チェック項目1-1]
|
||||
- [ ] [チェック項目1-2]
|
||||
|
||||
### [カテゴリ2]チェックリスト
|
||||
|
||||
- [ ] [チェック項目2-1]
|
||||
- [ ] [チェック項目2-2]
|
||||
@@ -0,0 +1,38 @@
|
||||
---
|
||||
name: [skill-name]
|
||||
description: [このConvention Skillが定義する規約・ガイドラインを簡潔に説明]
|
||||
---
|
||||
|
||||
# [Convention Skill名]
|
||||
|
||||
## 概要
|
||||
|
||||
[概要を記述]
|
||||
|
||||
## 責任範囲
|
||||
|
||||
このSkillは以下の範囲をカバーします:
|
||||
|
||||
- [責任範囲の内容1]
|
||||
- [責任範囲の内容2]
|
||||
- [責任範囲の内容3]
|
||||
|
||||
## [カテゴリ1]
|
||||
|
||||
- [ルールの記述]
|
||||
|
||||
## [カテゴリ2]
|
||||
|
||||
- [ルールの記述]
|
||||
|
||||
## チェックリスト
|
||||
|
||||
### [カテゴリ1]チェックリスト
|
||||
|
||||
- [ ] [チェック項目1-1]
|
||||
- [ ] [チェック項目1-2]
|
||||
|
||||
### [カテゴリ2]チェックリスト
|
||||
|
||||
- [ ] [チェック項目2-1]
|
||||
- [ ] [チェック項目2-2]
|
||||
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つの明確な作業フローを持つものはスキルにする
|
||||
|
||||
## ベストプラクティス
|
||||
|
||||
- 業務領域の理解には十分な時間をかける（急がず丁寧に）
|
||||
- ユーザーとの対話を重視し、推測や仮定を避ける
|
||||
- 機能は小さく分解し、単一責任の原則に従う
|
||||
- 要素分類は明確な基準に基づいて行う
|
||||
- 推奨構成は実装の優先順位を明示する
|
||||
- 業務領域分析レポートは後続フェーズで参照できるようにする
|
||||
|
||||
## チェックリスト
|
||||
|
||||
### 情報収集完了時
|
||||
|
||||
- [ ] 業務領域の概要が明確になっている
|
||||
- [ ] プラグイン化の目的が明確になっている
|
||||
- [ ] 対象ユーザーが特定されている
|
||||
- [ ] 現在の課題や問題点が把握されている
|
||||
- [ ] 期待される効果や成果が確認されている
|
||||
|
||||
### 領域分析完了時
|
||||
|
||||
- [ ] 業務の特徴が整理されている
|
||||
- [ ] 技術的制約が特定されている
|
||||
- [ ] ビジネス的制約が特定されている
|
||||
- [ ] 前提条件や依存関係が把握されている
|
||||
- [ ] 既存ツールやプロセスとの関係が確認されている
|
||||
|
||||
### 機能抽出完了時
|
||||
|
||||
- [ ] 業務の各ステップが分解されている
|
||||
- [ ] 自動化可能な作業が特定されている
|
||||
- [ ] 手作業が必要な部分が明確になっている
|
||||
- [ ] 各機能の入力と出力が定義されている
|
||||
- [ ] ドキュメント生成機能で使用するテンプレートファイルが特定されている
|
||||
- [ ] 機能間の依存関係が整理されている
|
||||
- [ ] 機能の粒度が適切である（単一責任の原則）
|
||||
|
||||
### 要素分類完了時
|
||||
|
||||
- [ ] エージェント候補が特定されている
|
||||
- [ ] ワークフロースキル候補が特定されている
|
||||
- [ ] コンベンションスキル候補が特定されている
|
||||
- [ ] コマンド候補が特定されている
|
||||
- [ ] 要素間の依存関係が整理されている
|
||||
- [ ] 分類基準が明確である
|
||||
|
||||
### 推奨提示完了時
|
||||
|
||||
- [ ] 推奨プラグイン構成が明確に提示されている
|
||||
- [ ] 各要素の役割が説明されている
|
||||
- [ ] 実装の優先順位が付けられている
|
||||
- [ ] 次のステップが案内されている
|
||||
- [ ] ユーザーの承認を得ている
|
||||
|
||||
### 最終確認
|
||||
|
||||
- [ ] 必要な機能リストが作成されている
|
||||
- [ ] 推奨エージェント/スキル/コマンド候補が提示されている
|
||||
- [ ] 業務領域分析レポートが作成されている
|
||||
- [ ] すべてのアウトプットが明確で理解しやすい
|
||||
- [ ] ユーザーが次のステップに進める状態になっている
|
||||
317
skills/element-definition-convention/SKILL.md
Normal file
317
skills/element-definition-convention/SKILL.md
Normal file
@@ -0,0 +1,317 @@
|
||||
---
|
||||
name: element-definition-convention
|
||||
description: プラグイン要素の定義ルール（命名規則、必須項目、記述フォーマット）を定義する。プラグイン要素作成時、エージェント・スキル・コマンド定義時、またはユーザーが命名規則、フロントマター、必須項目、記述フォーマットに言及した際に使用する。
|
||||
---
|
||||
|
||||
# Element Definition Convention
|
||||
|
||||
## 概要
|
||||
|
||||
このSkillは、プラグイン要素（エージェント、スキル、コマンド）の定義ルールを明確化する。命名規則、フロントマターの必須項目、必須セクション、ドキュメント記述フォーマットについて標準を定義し、一貫性のあるプラグイン要素の作成を実現することを目的とする。
|
||||
|
||||
## 責任範囲
|
||||
|
||||
このSkillは以下の範囲をカバーする:
|
||||
|
||||
- プラグイン要素（エージェント、スキル、コマンド）の命名規則
|
||||
- フロントマターの必須項目と記述ルール
|
||||
- 必須セクション（概要、責任範囲、基本方針など）の定義
|
||||
- ドキュメント記述フォーマットと記述原則
|
||||
- チェックリストの作成ガイドライン
|
||||
|
||||
## 基本方針
|
||||
|
||||
- 命名はケバブケース（kebab-case）を使用する
|
||||
- フロントマターにはname、descriptionを必須とする
|
||||
- 必須セクションを統一し、一貫性を保つ
|
||||
- ドキュメントは日本語・常体で記述する
|
||||
- 簡潔で明確な文章を使用する
|
||||
- 箇条書きを活用して情報を整理する
|
||||
|
||||
## 命名規則
|
||||
|
||||
### エージェントの命名
|
||||
|
||||
エージェントの役割を表す名前を使用する。
|
||||
|
||||
**命名パターン:**
|
||||
|
||||
- `[役割]-agent`の形式を使用する
|
||||
- 責任範囲が明確にわかる名前にする
|
||||
- ケバブケース（例: requirements-agent, design-agent）を使用する
|
||||
|
||||
良い例:
|
||||
|
||||
```text
|
||||
requirements-agent
|
||||
design-agent
|
||||
implementation-agent
|
||||
test-agent
|
||||
```
|
||||
|
||||
悪い例:
|
||||
|
||||
```text
|
||||
RequirementsAgent (キャメルケースは使用しない)
|
||||
req-agent (省略形は避ける)
|
||||
requirements_agent (スネークケースは使用しない)
|
||||
agent-requirements (順序が逆)
|
||||
```
|
||||
|
||||
### スキルの命名
|
||||
|
||||
スキルの目的を表す名前を使用する。
|
||||
|
||||
**Workflow Skillの命名パターン:**
|
||||
|
||||
- 動詞を含む名前にする（例: code-generator, api-designer）
|
||||
- 「何を生成するか」「何を設計するか」を明確にする
|
||||
- ケバブケース（例: database-schema-designer）を使用する
|
||||
|
||||
**Convention Skillの命名パターン:**
|
||||
|
||||
- 規約の対象を表す名前にする（例: coding-conventions, documentation-standards）
|
||||
- 複数形を使用することが多い（conventions, standards, guidelinesなど）
|
||||
- ケバブケース（例: security-guidelines）を使用する
|
||||
|
||||
良い例（Workflow Skill）:
|
||||
|
||||
```text
|
||||
code-generator
|
||||
api-designer
|
||||
database-schema-designer
|
||||
requirements-structurer
|
||||
```
|
||||
|
||||
良い例（Convention Skill）:
|
||||
|
||||
```text
|
||||
coding-conventions
|
||||
documentation-standards
|
||||
security-guidelines
|
||||
interaction-guidelines
|
||||
```
|
||||
|
||||
悪い例:
|
||||
|
||||
```text
|
||||
CodeGenerator (キャメルケースは使用しない)
|
||||
api_designer (スネークケースは使用しない)
|
||||
gen-code (省略形は避ける)
|
||||
generator (目的が不明確)
|
||||
```
|
||||
|
||||
### コマンドの命名
|
||||
|
||||
コマンドの機能を表す名前を使用する。
|
||||
|
||||
**命名パターン:**
|
||||
|
||||
- ユーザーが覚えやすい簡潔な名前にする
|
||||
- 動詞または名詞を使用する（例: requirements, design, generate）
|
||||
- ケバブケース（例: test-run）を使用する
|
||||
- 複数単語の場合は、意味が明確になるようにする
|
||||
|
||||
良い例:
|
||||
|
||||
```text
|
||||
requirements
|
||||
design
|
||||
task
|
||||
implement
|
||||
test-run
|
||||
generate-plugin
|
||||
```
|
||||
|
||||
悪い例:
|
||||
|
||||
```text
|
||||
req (省略形は避ける)
|
||||
RequirementsCommand (キャメルケースは使用しない)
|
||||
requirements_command (スネークケースは使用しない)
|
||||
command-requirements (順序が逆)
|
||||
```
|
||||
|
||||
## フロントマターの定義
|
||||
|
||||
すべてのプラグイン要素のマークダウンファイルには、フロントマターを記述する。
|
||||
|
||||
**必須項目:**
|
||||
|
||||
- `name`: 要素の名前（ケバブケース）
|
||||
- `description`: 要素の簡潔な説明（1行、50文字以内を目安）
|
||||
|
||||
**フォーマット:**
|
||||
|
||||
```markdown
|
||||
---
|
||||
name: 要素名（ケバブケース）
|
||||
description: 簡潔な説明（1行、50文字以内）
|
||||
---
|
||||
```
|
||||
|
||||
良い例:
|
||||
|
||||
```markdown
|
||||
---
|
||||
name: code-generator
|
||||
description: 設計仕様からソースコードを生成する
|
||||
---
|
||||
```
|
||||
|
||||
悪い例:
|
||||
|
||||
```markdown
|
||||
---
|
||||
name: CodeGenerator
|
||||
description: このスキルは、設計仕様書を入力として受け取り、それに基づいてソースコードを自動的に生成するための機能を提供します。生成されるコードは、プロジェクトのコーディング規約に準拠し、テストケースも含まれます。
|
||||
---
|
||||
（nameがキャメルケース、descriptionが長すぎる）
|
||||
```
|
||||
|
||||
## 必須セクションの定義
|
||||
|
||||
### エージェントの必須セクション
|
||||
|
||||
1. **概要**: エージェントの目的と役割を簡潔に説明（1〜2段落）
|
||||
2. **責任範囲**: エージェントが責任を持つ範囲を箇条書き（3〜5項目）
|
||||
3. **基本方針**: エージェントの行動指針（該当する場合のみ）
|
||||
|
||||
### スキルの必須セクション
|
||||
|
||||
1. **概要**: スキルの目的と実行内容を簡潔に説明（1〜2段落）
|
||||
2. **責任範囲**: スキルがカバーする範囲を箇条書き（3〜5項目）
|
||||
3. **基本方針**: スキルの実行原則（該当する場合のみ）
|
||||
4. **ワークフロー/カテゴリ**:
|
||||
- Workflow Skill: フェーズごとの実施内容
|
||||
- Convention Skill: カテゴリ別の規約・ガイドライン
|
||||
5. **アウトプット**: スキルが生成する成果物（Workflow Skillの場合）
|
||||
6. **チェックリスト**: 各フェーズ/カテゴリのチェック項目
|
||||
|
||||
### コマンドの必須セクション
|
||||
|
||||
1. **概要**: コマンドの目的と機能を簡潔に説明（1〜2段落）
|
||||
2. **使用するエージェント**: コマンドが使用するエージェント
|
||||
3. **使用するスキル**: コマンドが使用するスキルのリスト
|
||||
4. **実行フロー**: スキルの実行順序とデータの受け渡し
|
||||
5. **成果物**: コマンド実行後の出力先とファイル構成
|
||||
|
||||
## ドキュメント記述の原則
|
||||
|
||||
プラグイン要素のドキュメント記述時は、以下の原則に従う:
|
||||
|
||||
- 日本語・常体で記述する
|
||||
- 簡潔で明確な文章を使用する
|
||||
- 箇条書きを活用して情報を整理する
|
||||
- 具体例を記述する場合は、良い例/悪い例の形式を使用する
|
||||
|
||||
良い例:
|
||||
|
||||
```markdown
|
||||
## 概要
|
||||
|
||||
このSkillは、設計仕様からソースコードを生成する。コーディング規約に準拠したコードを自動生成し、開発効率を向上させることを目的とする。
|
||||
|
||||
## 責任範囲
|
||||
|
||||
このSkillは以下の範囲をカバーする:
|
||||
|
||||
- 設計仕様の解析とコード構造の決定
|
||||
- コーディング規約に準拠したソースコードの生成
|
||||
- 生成コードの検証とフォーマット
|
||||
```
|
||||
|
||||
悪い例:
|
||||
|
||||
```markdown
|
||||
## 概要
|
||||
|
||||
このSkillは、設計仕様書を入力として受け取り、それに基づいてソースコードを自動的に生成するための機能を提供します。生成されるコードは、プロジェクトのコーディング規約に準拠し、テストケースも含まれます。また、コードレビューの観点からも最適化されており、保守性の高いコードを生成することができます。
|
||||
|
||||
## 責任範囲
|
||||
|
||||
このSkillは以下の範囲をカバーします:
|
||||
|
||||
・設計仕様の解析
|
||||
・コード生成
|
||||
・検証
|
||||
```
|
||||
|
||||
（文章が冗長、敬体を使用、箇条書きのマーカーが不統一）
|
||||
|
||||
## チェックリストの作成ガイドライン
|
||||
|
||||
### チェックリストの構成
|
||||
|
||||
- フェーズごと/カテゴリごとにチェックリストを作成する
|
||||
- 最終確認用のチェックリストを含める
|
||||
- 具体的で検証可能な項目を記述する
|
||||
- 各項目は明確で検証可能にする（「〜を確認した」「〜が含まれている」のような表現）
|
||||
|
||||
良い例:
|
||||
|
||||
```markdown
|
||||
### フェーズ1完了時
|
||||
|
||||
- [ ] 設計仕様書を読み込んだ
|
||||
- [ ] コード構造を決定した
|
||||
- [ ] 必要なファイルパスを特定した
|
||||
|
||||
### 最終確認
|
||||
|
||||
- [ ] 生成コードがコーディング規約に準拠している
|
||||
- [ ] すべてのファイルが正しいパスに配置されている
|
||||
- [ ] 構文エラーがない
|
||||
```
|
||||
|
||||
悪い例:
|
||||
|
||||
```markdown
|
||||
### チェックリスト
|
||||
|
||||
- [ ] 設計仕様を確認
|
||||
- [ ] コード生成
|
||||
- [ ] 良いコードになっている
|
||||
```
|
||||
|
||||
（フェーズ分けがない、項目が曖昧、検証不可能な表現）
|
||||
|
||||
## チェックリスト
|
||||
|
||||
### 命名規則確認時
|
||||
|
||||
- [ ] ケバブケース（kebab-case）を使用している
|
||||
- [ ] エージェント名は責任範囲が明確である
|
||||
- [ ] スキル名は目的が明確である（Workflow Skillは動詞を含む、Convention Skillは規約の対象を表す）
|
||||
- [ ] コマンド名は簡潔で覚えやすい
|
||||
- [ ] 省略形を避けている
|
||||
|
||||
### フロントマター作成時
|
||||
|
||||
- [ ] nameフィールドがケバブケースで記述されている
|
||||
- [ ] descriptionフィールドが1行50文字以内である
|
||||
- [ ] descriptionが簡潔で要素の目的を明確に説明している
|
||||
|
||||
### 必須セクション作成時
|
||||
|
||||
- [ ] 概要セクションが1〜2段落で簡潔に記述されている
|
||||
- [ ] 責任範囲が箇条書きで3〜5項目記述されている
|
||||
- [ ] 基本方針が明確である（該当する場合）
|
||||
- [ ] ワークフロー/カテゴリが適切に構成されている
|
||||
- [ ] チェックリストが作成されている
|
||||
|
||||
### ドキュメント記述確認時
|
||||
|
||||
- [ ] 日本語・常体で記述されている
|
||||
- [ ] 簡潔で明確な文章を使用している
|
||||
- [ ] 箇条書きを活用して情報が整理されている
|
||||
- [ ] リストのインデントがスペース2個で統一されている
|
||||
- [ ] 良い例/悪い例が具体的で実用的である（該当する場合）
|
||||
|
||||
### 最終確認
|
||||
|
||||
- [ ] すべての命名規則が守られている
|
||||
- [ ] フロントマターが正しく記述されている
|
||||
- [ ] 必須セクションがすべて含まれている
|
||||
- [ ] ドキュメント記述の原則に従っている
|
||||
- [ ] チェックリストが適切に作成されている
|
||||
542
skills/element-relationship-analyzer/SKILL.md
Normal file
542
skills/element-relationship-analyzer/SKILL.md
Normal file
@@ -0,0 +1,542 @@
|
||||
---
|
||||
name: element-relationship-analyzer
|
||||
description: プラグイン要素間の依存関係や呼び出し順序を分析する。プラグイン整合性確認時、依存関係検証時、またはユーザーが要素間依存、呼び出し順序、循環依存、アーキテクチャ検証に言及した際に使用する。
|
||||
---
|
||||
|
||||
# Element Relationship Analyzer
|
||||
|
||||
## 概要
|
||||
|
||||
このSkillは、プラグイン内の要素（エージェント、スキル、コマンド）間の依存関係や呼び出し順序を分析する。プラグインの整合性を確認し、循環依存やアーキテクチャ違反を検出して、適切な依存関係の構築を支援する。
|
||||
|
||||
## 責任範囲
|
||||
|
||||
このSkillは以下の範囲をカバーする:
|
||||
|
||||
- プラグイン要素（エージェント、スキル、コマンド）の収集
|
||||
- 要素間の依存関係の分析
|
||||
- 要素の呼び出し順序の分析
|
||||
- 循環依存の検出と報告
|
||||
- アーキテクチャ規約違反の検出
|
||||
- 依存関係の最適化提案
|
||||
|
||||
## ワークフロー
|
||||
|
||||
### フェーズ1: 要素収集
|
||||
|
||||
プラグインディレクトリから全ての要素を収集し、基本情報を抽出する。
|
||||
|
||||
**実施内容:**
|
||||
|
||||
1. プラグインディレクトリ構造を確認する
|
||||
2. エージェントファイルを収集する
|
||||
3. スキルファイルを収集する
|
||||
4. コマンドファイルを収集する
|
||||
5. 各要素のフロントマター情報を抽出する
|
||||
|
||||
**収集対象:**
|
||||
|
||||
- エージェント: `agents/[agent-name].md`
|
||||
- スキル: `skills/*/SKILL.md`
|
||||
- コマンド: `commands/[command-name].md`
|
||||
|
||||
**抽出情報:**
|
||||
|
||||
- name（要素名）
|
||||
- description（説明）
|
||||
- tools（エージェントのみ）
|
||||
- 依存する要素の参照（本文中のエージェント名、スキル名、コマンド名）
|
||||
|
||||
**良い例:**
|
||||
|
||||
```markdown
|
||||
【要素収集結果】
|
||||
|
||||
プラグイン名: database-design-plugin
|
||||
プラグインディレクトリ: D:\projects\database-design-plugin
|
||||
|
||||
エージェント (1個):
|
||||
- database-design-agent
|
||||
- 説明: データベース設計フェーズ全体に対する責任を持つ
|
||||
- tools: "*"
|
||||
|
||||
スキル (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
|
||||
- 説明: スキーマ定義のみを生成
|
||||
```
|
||||
|
||||
**悪い例:**
|
||||
|
||||
```markdown
|
||||
【要素収集結果】
|
||||
|
||||
何かある
|
||||
```
|
||||
|
||||
### フェーズ2: 依存関係分析
|
||||
|
||||
各要素が参照する他の要素を分析し、依存関係を明確にする。
|
||||
|
||||
**実施内容:**
|
||||
|
||||
1. 各要素のドキュメント本文を解析する
|
||||
2. 他の要素への参照を検出する
|
||||
3. 依存関係マップを作成する
|
||||
4. 依存の種類を分類する（必須依存、オプション依存）
|
||||
5. 依存の方向を確認する（エージェント→スキル、スキル→スキル、コマンド→エージェント/スキル）
|
||||
|
||||
**依存関係の検出方法:**
|
||||
|
||||
- エージェント: 本文中のスキル名参照
|
||||
- スキル: 本文中の他のスキル名参照（※プラグインアーキテクチャ規約では推奨されない）
|
||||
- コマンド: 「使用するエージェント」「使用するスキル」セクションからの参照
|
||||
|
||||
**良い例:**
|
||||
|
||||
```markdown
|
||||
【依存関係分析結果】
|
||||
|
||||
コマンド: design-database
|
||||
- 使用するエージェント:
|
||||
- database-design-agent（必須）
|
||||
- 使用するスキル:
|
||||
- entity-definition-collector（必須）
|
||||
- normalization-processor（必須）
|
||||
- er-diagram-generator（必須）
|
||||
- table-definition-writer（必須）
|
||||
- ddl-script-generator（必須）
|
||||
- database-naming-conventions（必須）
|
||||
- normalization-rules（必須）
|
||||
|
||||
コマンド: generate-schema
|
||||
- 使用するエージェント:
|
||||
- database-design-agent（必須）
|
||||
- 使用するスキル:
|
||||
- entity-definition-collector（必須）
|
||||
- normalization-processor（必須）
|
||||
- database-naming-conventions（必須）
|
||||
- normalization-rules（必須）
|
||||
|
||||
エージェント: database-design-agent
|
||||
- 依存するスキル: なし
|
||||
※アーキテクチャ規約に従い、エージェントは直接スキルを参照しない
|
||||
|
||||
スキル: entity-definition-collector
|
||||
- 依存するスキル: なし
|
||||
※アーキテクチャ規約に従い、スキルは他のスキルを参照しない
|
||||
|
||||
スキル: normalization-processor
|
||||
- 依存するスキル: なし
|
||||
|
||||
スキル: er-diagram-generator
|
||||
- 依存するスキル: なし
|
||||
|
||||
スキル: table-definition-writer
|
||||
- 依存するスキル: なし
|
||||
|
||||
スキル: ddl-script-generator
|
||||
- 依存するスキル: なし
|
||||
|
||||
スキル: database-naming-conventions
|
||||
- 依存するスキル: なし
|
||||
|
||||
スキル: normalization-rules
|
||||
- 依存するスキル: なし
|
||||
```
|
||||
|
||||
**悪い例:**
|
||||
|
||||
```markdown
|
||||
【依存関係分析結果】
|
||||
|
||||
いろいろ依存している
|
||||
```
|
||||
|
||||
### フェーズ3: 呼び出し順序分析
|
||||
|
||||
コマンドにおけるスキルの呼び出し順序を分析する。
|
||||
|
||||
**実施内容:**
|
||||
|
||||
1. 各コマンドの「実行フロー」セクションを解析する
|
||||
2. スキルの実行順序を抽出する
|
||||
3. 並列実行可能なスキルを特定する
|
||||
4. 順次実行が必要なスキルを特定する
|
||||
5. 実行順序の妥当性を検証する
|
||||
|
||||
**分析基準:**
|
||||
|
||||
- スキルの実行順序が明確であるか
|
||||
- 依存関係に基づいた順序になっているか
|
||||
- 並列実行可能なスキルが適切に識別されているか
|
||||
- データの受け渡しが明確であるか
|
||||
|
||||
**良い例:**
|
||||
|
||||
```markdown
|
||||
【呼び出し順序分析結果】
|
||||
|
||||
コマンド: design-database
|
||||
|
||||
実行フロー:
|
||||
1. database-design-agent が entity-definition-collector を使用してエンティティ定義を収集
|
||||
- 入力: ユーザーからの要求、既存システムの情報
|
||||
- 出力: エンティティ一覧、属性リスト
|
||||
- 並列実行: 不可（最初のステップ）
|
||||
|
||||
2. database-design-agent が normalization-processor を使用して正規化を実施
|
||||
- 入力: エンティティ定義（ステップ1の出力）
|
||||
- 出力: 正規化されたテーブル定義
|
||||
- 並列実行: 不可（ステップ1に依存）
|
||||
- 使用する規約: normalization-rules
|
||||
|
||||
3. database-design-agent が以下のスキルを並列実行:
|
||||
- er-diagram-generator: ER図を生成
|
||||
- 入力: 正規化されたテーブル定義（ステップ2の出力）
|
||||
- 出力: ER図（Mermaid形式）
|
||||
- table-definition-writer: テーブル定義書を作成
|
||||
- 入力: 正規化されたテーブル定義（ステップ2の出力）
|
||||
- 出力: テーブル定義書（Markdown形式）
|
||||
- ddl-script-generator: DDLスクリプトを生成
|
||||
- 入力: 正規化されたテーブル定義（ステップ2の出力）
|
||||
- 出力: DDLスクリプト
|
||||
- 並列実行: 可能（全てステップ2の出力を使用、相互依存なし）
|
||||
|
||||
妥当性: OK
|
||||
- 各ステップの入力と出力が明確
|
||||
- 依存関係に基づいた順序
|
||||
- 並列実行可能なステップが適切に識別されている
|
||||
|
||||
コマンド: generate-schema
|
||||
|
||||
実行フロー:
|
||||
1. database-design-agent が entity-definition-collector を使用してエンティティ定義を収集
|
||||
2. database-design-agent が normalization-processor を使用して正規化を実施
|
||||
|
||||
妥当性: OK
|
||||
- 最小限のステップのみ実行
|
||||
- 依存関係が明確
|
||||
```
|
||||
|
||||
**悪い例:**
|
||||
|
||||
```markdown
|
||||
【呼び出し順序分析結果】
|
||||
|
||||
順番に実行する
|
||||
```
|
||||
|
||||
### フェーズ4: 循環依存検出
|
||||
|
||||
要素間の循環依存を検出し、報告する。
|
||||
|
||||
**実施内容:**
|
||||
|
||||
1. 依存関係グラフを構築する
|
||||
2. 循環依存を検出するアルゴリズムを実行する
|
||||
3. 検出された循環依存を報告する
|
||||
4. 循環依存の影響を評価する
|
||||
5. 循環依存の解消方法を提案する
|
||||
|
||||
**検出方法:**
|
||||
|
||||
- 深さ優先探索（DFS）による循環検出
|
||||
- トポロジカルソートによる順序確認
|
||||
|
||||
**良い例:**
|
||||
|
||||
```markdown
|
||||
【循環依存検出結果】
|
||||
|
||||
循環依存: 検出されませんでした
|
||||
|
||||
依存関係グラフ:
|
||||
|
||||
design-database コマンド
|
||||
↓
|
||||
database-design-agent エージェント
|
||||
↓
|
||||
entity-definition-collector スキル
|
||||
normalization-processor スキル
|
||||
er-diagram-generator スキル
|
||||
table-definition-writer スキル
|
||||
ddl-script-generator スキル
|
||||
database-naming-conventions スキル
|
||||
normalization-rules スキル
|
||||
|
||||
generate-schema コマンド
|
||||
↓
|
||||
database-design-agent エージェント
|
||||
↓
|
||||
entity-definition-collector スキル
|
||||
normalization-processor スキル
|
||||
database-naming-conventions スキル
|
||||
normalization-rules スキル
|
||||
|
||||
トポロジカルソート結果:
|
||||
1. database-naming-conventions（コンベンション、依存なし）
|
||||
2. normalization-rules（コンベンション、依存なし）
|
||||
3. entity-definition-collector（ワークフロー、コンベンションに依存可能）
|
||||
4. normalization-processor（ワークフロー、コンベンションに依存可能）
|
||||
5. er-diagram-generator（ワークフロー、依存なし）
|
||||
6. table-definition-writer（ワークフロー、依存なし）
|
||||
7. ddl-script-generator（ワークフロー、依存なし）
|
||||
8. database-design-agent（エージェント、スキルを使用）
|
||||
9. design-database（コマンド、エージェントとスキルを使用）
|
||||
10. generate-schema（コマンド、エージェントとスキルを使用）
|
||||
|
||||
アーキテクチャ規約遵守: OK
|
||||
- エージェントは他の要素を参照していない
|
||||
- スキルは他のスキルを参照していない
|
||||
- コマンドのみがエージェントとスキルを参照している
|
||||
```
|
||||
|
||||
**悪い例（循環依存が存在する場合）:**
|
||||
|
||||
```markdown
|
||||
【循環依存検出結果】
|
||||
|
||||
循環依存: 検出されました
|
||||
|
||||
循環1:
|
||||
skill-a → skill-b → skill-c → skill-a
|
||||
|
||||
問題: スキルが他のスキルを参照している（アーキテクチャ規約違反）
|
||||
影響: スキルの独立性が損なわれ、再利用性が低下
|
||||
解消方法:
|
||||
- スキル間の参照を削除する
|
||||
- 共通の処理をコンベンションスキルに分離する
|
||||
- コマンドで依存関係を管理する
|
||||
|
||||
循環2:
|
||||
command-a → agent-b → command-a
|
||||
|
||||
問題: コマンドとエージェントが相互参照している
|
||||
影響: 無限ループの可能性
|
||||
解消方法:
|
||||
- エージェントからコマンドへの参照を削除する
|
||||
- エージェントはスキルのみを使用するようにする
|
||||
```
|
||||
|
||||
### フェーズ5: 推奨提示
|
||||
|
||||
分析結果をまとめ、改善提案をユーザーに提示する。
|
||||
|
||||
**実施内容:**
|
||||
|
||||
1. 分析結果をサマリー化する
|
||||
2. 検出された問題をリストアップする
|
||||
3. アーキテクチャ規約の遵守状況を報告する
|
||||
4. 改善提案を作成する
|
||||
5. 次のステップを案内する
|
||||
|
||||
**提示形式:**
|
||||
|
||||
```markdown
|
||||
【要素関係分析レポート】
|
||||
|
||||
プラグイン名: database-design-plugin
|
||||
分析日時: 2025-11-15
|
||||
|
||||
【サマリー】
|
||||
|
||||
要素数:
|
||||
- エージェント: 1個
|
||||
- スキル: 7個（ワークフロー: 5個、コンベンション: 2個）
|
||||
- コマンド: 2個
|
||||
|
||||
依存関係:
|
||||
- 総依存数: 14個
|
||||
- 循環依存: 0個
|
||||
- アーキテクチャ規約違反: 0個
|
||||
|
||||
品質評価: 優良
|
||||
- 循環依存なし
|
||||
- アーキテクチャ規約遵守
|
||||
- 依存関係が明確
|
||||
|
||||
【詳細分析結果】
|
||||
|
||||
依存関係マップ:
|
||||
- design-database → database-design-agent, 5つのワークフロースキル, 2つのコンベンションスキル
|
||||
- generate-schema → database-design-agent, 2つのワークフロースキル, 2つのコンベンションスキル
|
||||
|
||||
呼び出し順序:
|
||||
- design-database: 3ステップ（ステップ3は3つのスキルを並列実行）
|
||||
- generate-schema: 2ステップ（順次実行）
|
||||
|
||||
循環依存: なし
|
||||
|
||||
アーキテクチャ規約遵守:
|
||||
- ✓ エージェントは他の要素を参照していない
|
||||
- ✓ スキルは他のスキルを参照していない
|
||||
- ✓ コマンドのみがエージェントとスキルを参照している
|
||||
- ✓ 依存関係の方向が正しい（コマンド→エージェント→スキル）
|
||||
|
||||
【改善提案】
|
||||
|
||||
改善点: なし
|
||||
|
||||
このプラグインは適切に設計されています。
|
||||
|
||||
【推奨事項】
|
||||
|
||||
1. 定期的に要素関係を分析し、循環依存が発生していないか確認する
|
||||
2. 新しい要素を追加する際は、アーキテクチャ規約を遵守する
|
||||
3. コマンドの実行フローを明確に記述する
|
||||
4. 並列実行可能なスキルを適切に識別する
|
||||
|
||||
【次のステップ】
|
||||
|
||||
1. プラグイン全体の品質検証（plugin-validator スキルを使用）
|
||||
2. プラグインのパッケージング（plugin-packager スキルを使用）
|
||||
```
|
||||
|
||||
**良い例:**
|
||||
|
||||
分析結果が明確で、問題点、改善提案、推奨事項が示されている。
|
||||
|
||||
**悪い例:**
|
||||
|
||||
```markdown
|
||||
【要素関係分析レポート】
|
||||
|
||||
分析した
|
||||
問題なし
|
||||
```
|
||||
|
||||
## アウトプット
|
||||
|
||||
このスキルは以下を生成する:
|
||||
|
||||
- **依存関係マップ**: 要素間の依存関係を整理したマッピング
|
||||
- **呼び出し順序図**: コマンドにおけるスキルの呼び出し順序を図示したドキュメント
|
||||
- **循環依存レポート**: 検出された循環依存とその解消方法
|
||||
- **要素関係分析レポート**: 分析結果、問題点、改善提案をまとめたレポート
|
||||
|
||||
## 想定されるエラーと対処法
|
||||
|
||||
### エラー1: 循環依存が検出された
|
||||
|
||||
**検出例:**
|
||||
|
||||
```markdown
|
||||
skill-a → skill-b → skill-a
|
||||
```
|
||||
|
||||
**対処法:**
|
||||
|
||||
- スキル間の参照を削除する
|
||||
- 共通の処理をコンベンションスキルに分離する
|
||||
- コマンドで依存関係を管理する
|
||||
|
||||
### エラー2: アーキテクチャ規約違反
|
||||
|
||||
**検出例:**
|
||||
|
||||
```markdown
|
||||
エージェントがスキルを直接参照している
|
||||
スキルが他のスキルを参照している
|
||||
```
|
||||
|
||||
**対処法:**
|
||||
|
||||
- エージェントからスキルへの直接参照を削除する
|
||||
- スキル間の参照を削除する
|
||||
- コマンドで依存関係を管理する
|
||||
|
||||
### エラー3: 呼び出し順序が不明確
|
||||
|
||||
**検出例:**
|
||||
|
||||
```markdown
|
||||
実行フロー: スキルを実行する
|
||||
```
|
||||
|
||||
**対処法:**
|
||||
|
||||
- 実行フローを明確に記述する
|
||||
- スキルの実行順序を番号付きで記述する
|
||||
- 並列実行可能なスキルを明示する
|
||||
|
||||
## ベストプラクティス
|
||||
|
||||
- 定期的に要素関係を分析する
|
||||
- 循環依存を早期に検出して解消する
|
||||
- アーキテクチャ規約を遵守する
|
||||
- 依存関係を明確に文書化する
|
||||
- 呼び出し順序を明示する
|
||||
- 並列実行可能なスキルを適切に識別する
|
||||
|
||||
## チェックリスト
|
||||
|
||||
### 要素収集完了時
|
||||
|
||||
- [ ] プラグインディレクトリ構造が確認されている
|
||||
- [ ] エージェントファイルが収集されている
|
||||
- [ ] スキルファイルが収集されている
|
||||
- [ ] コマンドファイルが収集されている
|
||||
- [ ] 各要素のフロントマター情報が抽出されている
|
||||
|
||||
### 依存関係分析完了時
|
||||
|
||||
- [ ] 各要素のドキュメント本文が解析されている
|
||||
- [ ] 他の要素への参照が検出されている
|
||||
- [ ] 依存関係マップが作成されている
|
||||
- [ ] 依存の種類が分類されている
|
||||
- [ ] 依存の方向が確認されている
|
||||
|
||||
### 呼び出し順序分析完了時
|
||||
|
||||
- [ ] 各コマンドの「実行フロー」セクションが解析されている
|
||||
- [ ] スキルの実行順序が抽出されている
|
||||
- [ ] 並列実行可能なスキルが特定されている
|
||||
- [ ] 順次実行が必要なスキルが特定されている
|
||||
- [ ] 実行順序の妥当性が検証されている
|
||||
|
||||
### 循環依存検出完了時
|
||||
|
||||
- [ ] 依存関係グラフが構築されている
|
||||
- [ ] 循環依存検出アルゴリズムが実行されている
|
||||
- [ ] 検出された循環依存が報告されている
|
||||
- [ ] 循環依存の影響が評価されている
|
||||
- [ ] 循環依存の解消方法が提案されている
|
||||
|
||||
### 推奨提示完了時
|
||||
|
||||
- [ ] 分析結果がサマリー化されている
|
||||
- [ ] 検出された問題がリストアップされている
|
||||
- [ ] アーキテクチャ規約の遵守状況が報告されている
|
||||
- [ ] 改善提案が作成されている
|
||||
- [ ] 次のステップが案内されている
|
||||
- [ ] ユーザーの承認を得ている
|
||||
|
||||
### 最終確認
|
||||
|
||||
- [ ] 依存関係マップが作成されている
|
||||
- [ ] 呼び出し順序図が作成されている
|
||||
- [ ] 循環依存レポートが作成されている（該当する場合）
|
||||
- [ ] 要素関係分析レポートが作成されている
|
||||
- [ ] すべてのアウトプットが明確で理解しやすい
|
||||
- [ ] ユーザーが次のステップに進める状態になっている
|
||||
523
skills/plugin-architecture-convention/SKILL.md
Normal file
523
skills/plugin-architecture-convention/SKILL.md
Normal file
@@ -0,0 +1,523 @@
|
||||
---
|
||||
name: plugin-architecture-convention
|
||||
description: プラグイン全体の構造設計原則（要素の役割分担、階層構造、依存関係管理）を定義する。プラグイン設計時、アーキテクチャレビュー時、またはユーザーがプラグイン構造、設計原則、独立性、汎用性、依存関係管理に言及した際に使用する。
|
||||
---
|
||||
|
||||
# Plugin Architecture Convention
|
||||
|
||||
## 概要
|
||||
|
||||
このSkillは、プラグイン全体のアーキテクチャ設計原則を定義する。プラグインを構成する要素（エージェント、スキル、コマンド）の役割分担、依存関係管理、独立性の確保、汎用性の維持について明確な指針を提供し、再利用可能で保守性の高いプラグイン設計を実現することを目的とする。
|
||||
|
||||
## 責任範囲
|
||||
|
||||
このSkillは以下の範囲をカバーする:
|
||||
|
||||
- プラグイン要素（エージェント、スキル、コマンド）の定義と役割
|
||||
- 要素間の依存関係管理の原則
|
||||
- 独立性の原則（他要素への参照禁止ルール）
|
||||
- 汎用性の原則（固有名詞の使用禁止ルール）
|
||||
- スキルの分類（Workflow Skill / Convention Skill）
|
||||
- コマンドの責任範囲と役割
|
||||
- プラグイン要素の命名と記述のガイドライン
|
||||
|
||||
## 基本方針
|
||||
|
||||
- すべてのエージェントおよびすべてのスキルは互いに依存しない
|
||||
- 各要素は独立した要素として確立される
|
||||
- 依存関係についてはすべてコマンドが引き受ける
|
||||
- 固有名詞を含めず、汎用的な表現を使用する
|
||||
- 1スキル1目的の原則を厳守する
|
||||
- 再利用可能で保守性の高い設計を重視する
|
||||
|
||||
## プラグインの構造
|
||||
|
||||
### ディレクトリ構成
|
||||
|
||||
プラグインは以下のディレクトリ構造を持つ:
|
||||
|
||||
```text
|
||||
[プラグイン名]/
|
||||
├── agents/
|
||||
│ └── [エージェント名].md
|
||||
├── skills/
|
||||
│ ├── [Convention Skill名]/
|
||||
│ │ └── SKILL.md
|
||||
│ │ ※ Convention Skillはtemplates/ディレクトリを持たない
|
||||
│ ├── [Workflow Skill (テンプレートなし)名]/
|
||||
│ │ └── SKILL.md
|
||||
│ └── [Workflow Skill (テンプレートあり)名]/
|
||||
│ ├── SKILL.md
|
||||
│ └── templates/
|
||||
│ ├── [テンプレート1].md
|
||||
│ └── [テンプレート2].md
|
||||
└── commands/
|
||||
└── [コマンド名].md
|
||||
```
|
||||
|
||||
**注釈:**
|
||||
|
||||
- Convention Skillは規約を定義するだけで、templates/ディレクトリを持たない
|
||||
- Workflow Skillは、ドキュメント生成を含む場合のみtemplates/ディレクトリを持つ
|
||||
- テンプレートファイルは、ユーザーのプロジェクトにコピーされ使用される
|
||||
|
||||
### ファイルの配置ルール
|
||||
|
||||
#### エージェント
|
||||
|
||||
- **配置場所:** `[プラグイン名]/agents/[エージェント名].md`
|
||||
- **ファイル名:** エージェント名をケバブケースで記述（例: `plugin-development-agent.md`）
|
||||
- **ファイル形式:** マークダウン（.md）
|
||||
|
||||
#### スキル
|
||||
|
||||
- **Convention Skill配置場所:** `[プラグイン名]/skills/[スキル名]/SKILL.md`
|
||||
- **Workflow Skill配置場所:** `[プラグイン名]/skills/[スキル名]/SKILL.md`
|
||||
- **スキル名:** ケバブケースで記述（例: `command-generator`）
|
||||
- **ファイル名:** 必ず `SKILL.md` とする（大文字）
|
||||
- **テンプレートファイル:** Workflow Skillの場合、必要に応じて `templates/` ディレクトリを同じディレクトリ内に作成
|
||||
|
||||
#### コマンド
|
||||
|
||||
- **配置場所:** `[プラグイン名]/commands/[コマンド名].md`
|
||||
- **ファイル名:** コマンド名をケバブケースで記述（例: `generate-agent.md`）
|
||||
- **ファイル形式:** マークダウン（.md）
|
||||
|
||||
### 出力パスの記述形式
|
||||
|
||||
コマンドやスキルのドキュメント内で出力先を記述する際は、以下の形式を使用する:
|
||||
|
||||
- `[プラグインディレクトリ]/agents/[エージェント名].md`
|
||||
- `[プラグインディレクトリ]/skills/[スキル名]/SKILL.md`
|
||||
- `[プラグインディレクトリ]/commands/[コマンド名].md`
|
||||
|
||||
プレースホルダー `[プラグインディレクトリ]` は、ユーザーが実際に使用するプラグインのルートディレクトリを指す。固有のプラグイン名を含めず、汎用的な表現を維持する。
|
||||
|
||||
## プラグイン要素の定義
|
||||
|
||||
### エージェント（Agent）
|
||||
|
||||
エージェントは**責任範囲が定義されている**要素である。
|
||||
|
||||
**特徴:**
|
||||
|
||||
- 「誰が何に対して責任を持つか」を明確にする
|
||||
- 具体的な作業内容やワークフローは定義されていない
|
||||
- フェーズ全体を統括する役割を担う
|
||||
|
||||
**例:**
|
||||
|
||||
- Requirements Agent: 要件定義フェーズ全体に対する責任を持つ
|
||||
- Design Agent: 詳細設計フェーズ全体に対する責任を持つ
|
||||
|
||||
### スキル（Skill）
|
||||
|
||||
スキルは**単一作業のワークフローが記述されている**要素である。
|
||||
|
||||
**特徴:**
|
||||
|
||||
- 一つの明確な目的を持った作業の手順が定義されている
|
||||
- その作業に必要な規約やガイドラインも含まれている
|
||||
- 1スキル1目的の原則に従う
|
||||
|
||||
**例:**
|
||||
|
||||
- Code Generator: 設計仕様からソースコードを生成する
|
||||
- API Designer: API仕様を設計する
|
||||
- Coding Convention: コーディング規約を定義する
|
||||
|
||||
### コマンド（Command）
|
||||
|
||||
コマンドは**エージェントと複数のスキルを組み合わせて作業を行うためのワークフロー**が定義されている要素である。
|
||||
|
||||
**特徴:**
|
||||
|
||||
- ユーザーが実際に実行する指示である
|
||||
- 一つのコマンドが複数のスキルを適切な順序で呼び出す
|
||||
- フェーズ全体の作業を進める
|
||||
|
||||
**例:**
|
||||
|
||||
- requirements: 要件定義フェーズの開始から完了までを管理
|
||||
- design: 詳細設計フェーズの開始から完了までを管理
|
||||
|
||||
## スキルの分類
|
||||
|
||||
スキルは以下の2種類に分類される。
|
||||
|
||||
### Workflow Skill（ワークフロースキル）
|
||||
|
||||
実際にワークフローに沿って具体的な作業を実行するスキルである。
|
||||
|
||||
**特徴:**
|
||||
|
||||
- アウトプットを生成することが主な目的
|
||||
- 作業の手順が明確に定義されている
|
||||
- 具体的な成果物を作成する
|
||||
|
||||
**例:**
|
||||
|
||||
- Code Generator: 設計仕様からソースコードを生成する
|
||||
- API Designer: API仕様を設計する
|
||||
- Database Schema Designer: データベーススキーマを設計する
|
||||
|
||||
**テンプレートファイル:**
|
||||
|
||||
- Workflow Skillがドキュメント生成を含む場合、skills/[スキル名]/templates/配下にテンプレートファイルを配置する
|
||||
- テンプレートファイルは、ユーザーのプロジェクトにコピーされ、プロジェクト固有の情報を入力する際に使用される
|
||||
- テンプレートファイルを持たないWorkflow Skillも存在する（例: データ変換、分析処理など）
|
||||
|
||||
**テンプレートファイルを持つ例:**
|
||||
|
||||
- requirement-analysis-workflow: templates/requirements-document.md
|
||||
- test-specification-workflow: templates/test-specification.md, templates/test-case.md
|
||||
|
||||
**テンプレートファイルを持たない例:**
|
||||
|
||||
- data-transformation-workflow: データ変換処理のみを実行
|
||||
- code-analysis-workflow: コード分析のみを実行
|
||||
|
||||
### Convention Skill（コンベンションスキル）
|
||||
|
||||
規約やガイドラインが定義されているスキルである。
|
||||
|
||||
**特徴:**
|
||||
|
||||
- ワークフロースキル内に規約を記述すると内容が肥大化する場合に分割
|
||||
- 基本はワークフロースキルの中に規約を直接記述する
|
||||
- スキルの肥大化を避ける目的で分離する
|
||||
|
||||
**例:**
|
||||
|
||||
- Coding Convention: 変数命名規則、インデントルールなど
|
||||
- API Design Guideline: RESTful設計原則、エンドポイント命名規則など
|
||||
- Documentation Standard: ドキュメント記述標準、構造の標準化など
|
||||
|
||||
**テンプレートファイル:**
|
||||
|
||||
- Convention Skillは規約・ガイドラインを定義するだけで、テンプレートファイルを持たない
|
||||
- Convention Skill Generator（スキル生成時）はconvention-skill-template-*.mdを使用してSKILL.mdを生成するが、生成されたConvention Skill自体にはtemplates/ディレクトリを作成しない
|
||||
|
||||
## 依存関係管理の原則
|
||||
|
||||
### コマンドが依存関係を管理する
|
||||
|
||||
すべてのエージェントおよびすべてのスキルは互いに依存しない。コマンドが以下の責任を持つ:
|
||||
|
||||
- どのエージェントがどのスキルを使用するかを定義
|
||||
- 成果物のファイルパスやディレクトリ構造を定義
|
||||
- スキル間のデータの受け渡しを定義
|
||||
- 実行順序とワークフローを定義
|
||||
|
||||
### エージェントとスキルの独立性
|
||||
|
||||
エージェントとスキルは再利用可能な独立したコンポーネントとして設計される。
|
||||
|
||||
**原則:**
|
||||
|
||||
- エージェントは他のエージェントに依存しない
|
||||
- スキルは他のスキルに依存しない
|
||||
- エージェントは特定のスキルに依存しない
|
||||
- スキルは特定のエージェントに依存しない
|
||||
|
||||
## 要素の責任分担原則
|
||||
|
||||
プラグイン開発において、Analyzer（分析スキル）とGenerator（生成スキル）の責任範囲を明確に分離する。
|
||||
|
||||
### Analyzerの責任範囲
|
||||
|
||||
Analyzerは**分析と特定**に責任を持つ。
|
||||
|
||||
**責任:**
|
||||
|
||||
- 必要な要素（機能、スキル、テンプレートなど）を分析する
|
||||
- 何が必要かを特定し、リストとして出力する
|
||||
- 要素間の関係を分析する
|
||||
- テンプレートファイルの必要性を特定する
|
||||
- どのスキルにどのテンプレートが必要かを分析する
|
||||
|
||||
**禁止事項:**
|
||||
|
||||
- ファイルを生成してはいけない
|
||||
- ファイルを配置してはいけない
|
||||
- 実装作業を行ってはいけない
|
||||
|
||||
**例:**
|
||||
|
||||
- domain-analyzer: 業務領域を分析し、必要な機能とテンプレートファイルリストを出力する
|
||||
- workflow-analyzer: 作業フローを分析し、必要なスキルとテンプレートファイルリストを出力する
|
||||
|
||||
### Generatorの責任範囲
|
||||
|
||||
Generatorは**生成と配置**に責任を持つ。
|
||||
|
||||
**責任:**
|
||||
|
||||
- 分析結果に基づいてファイルを生成する
|
||||
- 生成したファイルを適切な場所に配置する
|
||||
- SKILL.mdファイルを生成する
|
||||
- テンプレートファイルを生成する（Workflow Skillでドキュメント生成を含む場合）
|
||||
- markdownlint検証を実施する
|
||||
|
||||
**原則:**
|
||||
|
||||
- Analyzerの出力（テンプレートファイルリスト）を入力として受け取る
|
||||
- Convention Skillにはテンプレートファイルを生成しない
|
||||
- Workflow Skillには、必要に応じてテンプレートファイルを生成し、skills/[スキル名]/templates/配下に配置する
|
||||
|
||||
**例:**
|
||||
|
||||
- convention-skill-generator: Convention SkillのSKILL.mdを生成する（テンプレートファイルは生成しない）
|
||||
- workflow-skill-generator: Workflow SkillのSKILL.mdを生成し、必要に応じてテンプレートファイルも生成する
|
||||
|
||||
### 責任分担の具体例
|
||||
|
||||
#### ケース1: 仕様書作成プラグインの開発
|
||||
|
||||
1. domain-analyzer（分析）:
|
||||
- 「要件定義書作成」機能を特定
|
||||
- requirements-document.md テンプレートが必要と判断
|
||||
- テンプレートファイルリストを出力: `[{skill: "requirement-analysis-workflow", templates: ["requirements-document.md"]}]`
|
||||
|
||||
2. workflow-skill-generator（生成）:
|
||||
- requirement-analysis-workflow/SKILL.md を生成
|
||||
- requirement-analysis-workflow/templates/requirements-document.md を生成・配置
|
||||
|
||||
#### ケース2: コーディング規約プラグインの開発
|
||||
|
||||
1. domain-analyzer（分析）:
|
||||
- 「コーディング規約定義」機能を特定
|
||||
- Convention Skillと判断
|
||||
- テンプレートファイルリストを出力: `[]` （空）
|
||||
|
||||
2. convention-skill-generator（生成）:
|
||||
- coding-conventions/SKILL.md を生成
|
||||
- テンプレートファイルは生成しない（Convention Skillのため）
|
||||
|
||||
## 独立性の原則（他要素への参照禁止）
|
||||
|
||||
### 参照禁止ルール
|
||||
|
||||
エージェントとスキルのドキュメント内で、他のエージェント、スキル、コマンドを参照してはいけない。
|
||||
|
||||
**重要:** この制限は**エージェントとスキルのみ**に適用される。コマンドは依存関係を管理する役割を持つため、エージェントとスキルを明示的に参照することが**求められる**。
|
||||
|
||||
**理由:**
|
||||
|
||||
- 参照先の要素が存在しない環境では使用できない
|
||||
- 参照先の要素が変更されると、参照元も影響を受ける
|
||||
- 要素単体での再利用が困難になる
|
||||
- 他のプロジェクトへの移植性が低下する
|
||||
|
||||
### 必要な情報の記述方法
|
||||
|
||||
必要な規約やガイドラインは、各エージェント・スキルのドキュメント内に直接記述するか、汎用的な表現で記載する。
|
||||
|
||||
**エージェント・スキルの場合:**
|
||||
|
||||
良い例:
|
||||
|
||||
```markdown
|
||||
コーディングルールに従う
|
||||
（具体的なルールは当該スキル内に記述）
|
||||
|
||||
ドキュメント記述標準に従う
|
||||
（具体的な標準は当該スキル内に記述）
|
||||
|
||||
要件定義フェーズに対する責任を持つ
|
||||
（他のエージェントに言及しない）
|
||||
|
||||
設計完了後に実行する
|
||||
（コマンド名を明示しない）
|
||||
|
||||
ユーザーとの対話パターンに従う
|
||||
（具体的なパターンは当該スキル内に記述）
|
||||
```
|
||||
|
||||
悪い例:
|
||||
|
||||
```markdown
|
||||
コーディングルールは coding-convention スキルに従う
|
||||
（他のスキルを参照している）
|
||||
|
||||
詳細は documentation-standards スキルを参照
|
||||
（他のスキルを参照している）
|
||||
|
||||
Requirements Agent と連携して動作する
|
||||
（他のエージェントを参照している）
|
||||
|
||||
design コマンドを実行してから使用する
|
||||
（他のコマンドを参照している）
|
||||
|
||||
interaction-guidelines スキルで定義された対話パターンを使用する
|
||||
（他のスキルを参照している）
|
||||
```
|
||||
|
||||
**コマンドの場合:**
|
||||
|
||||
良い例:
|
||||
|
||||
```markdown
|
||||
version-control-agentがversion-control-guidelinesスキルを使用して、現在の変更状況を確認する
|
||||
（コマンドは依存関係を管理するため、エージェントとスキルを明示的に参照する）
|
||||
|
||||
design-agentがapi-design-guidelinesスキルとdocumentation-standardsスキルを使用して、API仕様書を作成する
|
||||
（複数のスキルを組み合わせて使用することを明示）
|
||||
```
|
||||
|
||||
## 汎用性の原則（固有名詞禁止）
|
||||
|
||||
### 固有名詞の使用禁止
|
||||
|
||||
すべてのエージェント、スキル、コマンドにおいて、固有名詞を含めない。
|
||||
|
||||
**対象:**
|
||||
|
||||
- 組織名、チーム名、企業名
|
||||
- プロジェクト名、製品名、サービス名
|
||||
- 特定の技術スタックやツールの名前（汎用的な場合を除く）
|
||||
|
||||
**理由:**
|
||||
|
||||
- 再利用性: 他のプロジェクトやチームでも使用できる汎用的な要素にする
|
||||
- 独立性: 特定の環境やコンテキストに依存しない独立した要素として設計する
|
||||
- 保守性: 組織名やプロジェクト名が変更されても、要素の更新が不要になる
|
||||
- 移植性: 異なる環境や組織に簡単に移植できる
|
||||
|
||||
### コード例やサンプルにおける固有名詞
|
||||
|
||||
コード例やサンプルにおいても、固有名詞の使用を避ける。代わりに、以下のような汎用的なプレースホルダーを使用する:
|
||||
|
||||
- `YourProject`: プロジェクト名のプレースホルダー
|
||||
- `YourCompany`: 組織名のプレースホルダー
|
||||
- `example.com`: ドメイン名のプレースホルダー
|
||||
|
||||
良い例（エージェントの記述）:
|
||||
|
||||
```markdown
|
||||
このエージェントは、すべての要件定義フェーズに対する責任を持つ。
|
||||
```
|
||||
|
||||
悪い例（エージェントの記述）:
|
||||
|
||||
```markdown
|
||||
このエージェントは、XYZ社プロジェクトの要件定義フェーズに対する責任を持つ。
|
||||
```
|
||||
|
||||
良い例（スキルの記述）:
|
||||
|
||||
```markdown
|
||||
このSkillは、開発されるすべての.NETプロジェクトに適用されるコーディング規約を定義する。
|
||||
```
|
||||
|
||||
悪い例（スキルの記述）:
|
||||
|
||||
```markdown
|
||||
このSkillは、ABC社で開発されるすべての.NETプロジェクトに適用されるコーディング規約を定義する。
|
||||
```
|
||||
|
||||
良い例（コマンドの記述）:
|
||||
|
||||
```markdown
|
||||
このコマンドは、要件定義フェーズ全体を管理し、要件定義書を生成する。
|
||||
```
|
||||
|
||||
悪い例（コマンドの記述）:
|
||||
|
||||
```markdown
|
||||
このコマンドは、XYZ社の要件定義フェーズ全体を管理し、要件定義書を生成する。
|
||||
```
|
||||
|
||||
良い例（コード例）:
|
||||
|
||||
```csharp
|
||||
namespace YourProject.Orders;
|
||||
|
||||
public class OrderProcessor
|
||||
{
|
||||
// 実装
|
||||
}
|
||||
```
|
||||
|
||||
悪い例（コード例）:
|
||||
|
||||
```csharp
|
||||
namespace RevTechStudio.Orders;
|
||||
|
||||
public class OrderProcessor
|
||||
{
|
||||
// 実装
|
||||
}
|
||||
```
|
||||
|
||||
## コマンドの責任範囲
|
||||
|
||||
### コマンドの役割
|
||||
|
||||
コマンドは以下の責任を持つ:
|
||||
|
||||
- どのエージェントがどのスキルを使用するかを定義
|
||||
- 成果物のファイルパスやディレクトリ構造を定義
|
||||
- スキル間のデータの受け渡しを定義
|
||||
- 実行順序とワークフローを定義
|
||||
|
||||
### コマンドの粒度
|
||||
|
||||
各フェーズでは1〜2個のコマンドに抑えることで、ユーザーが覚えるべきコマンド数を最小限にする。
|
||||
|
||||
**例:**
|
||||
|
||||
- `requirements`: 要件定義フェーズ全体を管理
|
||||
- `design`: 詳細設計フェーズ全体を管理し、設計書の出力先を指定
|
||||
- `task`: 設計完了後にタスク分割を実行し、タスクリストの出力先を指定
|
||||
|
||||
## チェックリスト
|
||||
|
||||
### エージェント定義時
|
||||
|
||||
- [ ] 責任範囲が明確に定義されている
|
||||
- [ ] 他のエージェント、スキル、コマンドを参照していない
|
||||
- [ ] 固有名詞を含めていない
|
||||
- [ ] 具体的な作業内容やワークフローを記述していない
|
||||
- [ ] フェーズ全体を統括する役割が明確である
|
||||
- [ ] `[プラグイン名]/agents/[エージェント名].md` の形式で配置されている
|
||||
- [ ] ファイル名がケバブケースで記述されている
|
||||
|
||||
### スキル定義時
|
||||
|
||||
- [ ] 1スキル1目的の原則を守っている
|
||||
- [ ] 単一作業のワークフローが明確に定義されている
|
||||
- [ ] 他のエージェント、スキル、コマンドを参照していない
|
||||
- [ ] 固有名詞を含めていない
|
||||
- [ ] 必要な規約やガイドラインをスキル内に直接記述している
|
||||
- [ ] Workflow SkillまたはConvention Skillのいずれかに分類できる
|
||||
- [ ] Convention Skillの場合、templates/ディレクトリを作成していない
|
||||
- [ ] Workflow Skillでドキュメント生成を含む場合、templates/ディレクトリにテンプレートファイルを配置している
|
||||
- [ ] テンプレートファイルのフロントマターが適切に定義されている（name, about, title等）
|
||||
- [ ] `[プラグイン名]/skills/[スキル名]/SKILL.md` の形式で配置されている
|
||||
- [ ] ファイル名が `SKILL.md`（大文字）になっている
|
||||
- [ ] ディレクトリ名がケバブケースで記述されている
|
||||
|
||||
### コマンド定義時
|
||||
|
||||
- [ ] どのエージェントがどのスキルを使用するかが定義されている
|
||||
- [ ] 成果物のファイルパスやディレクトリ構造が定義されている
|
||||
- [ ] スキル間のデータの受け渡しが定義されている
|
||||
- [ ] 実行順序とワークフローが定義されている
|
||||
- [ ] ユーザーが覚えやすい簡潔な名前である
|
||||
- [ ] 固有名詞を含めていない
|
||||
- [ ] `[プラグイン名]/commands/[コマンド名].md` の形式で配置されている
|
||||
- [ ] ファイル名がケバブケースで記述されている
|
||||
- [ ] 成果物のパスが `[プラグインディレクトリ]/...` の形式で記述されている
|
||||
|
||||
### 最終確認
|
||||
|
||||
- [ ] すべての要素が互いに依存していない
|
||||
- [ ] 依存関係がコマンドで管理されている
|
||||
- [ ] 他要素への参照が含まれていない
|
||||
- [ ] 固有名詞が使用されていない
|
||||
- [ ] 再利用可能で保守性の高い設計になっている
|
||||
- [ ] ドキュメントが明確で理解しやすい
|
||||
- [ ] プラグイン全体が標準のディレクトリ構造に従っている
|
||||
- [ ] すべてのファイルが正しい配置場所に配置されている
|
||||
- [ ] 出力パスの記述が標準形式に従っている
|
||||
485
skills/plugin-packager/SKILL.md
Normal file
485
skills/plugin-packager/SKILL.md
Normal file
@@ -0,0 +1,485 @@
|
||||
---
|
||||
name: plugin-packager
|
||||
description: 生成したプラグインをZIP形式にまとめる。プラグインパッケージング時、配布準備時、またはユーザーがZIP作成、プラグイン配布、パッケージング、リリース準備に言及した際に使用する。
|
||||
---
|
||||
|
||||
# Plugin Packager
|
||||
|
||||
## 概要
|
||||
|
||||
このSkillは、生成したプラグインをZIP形式にパッケージングする。プラグインのファイルを収集し、必要なメタデータを生成して、配布可能なZIPファイルを作成する。
|
||||
|
||||
## 責任範囲
|
||||
|
||||
このSkillは以下の範囲をカバーする:
|
||||
|
||||
- パッケージング対象ファイルの収集
|
||||
- ファイルの完全性検証
|
||||
- メタデータファイルの生成（package.json、VERSION）
|
||||
- ZIPファイルの作成
|
||||
- パッケージの出力とメタデータの記録
|
||||
- 配布用ドキュメントの準備
|
||||
|
||||
## ワークフロー
|
||||
|
||||
### フェーズ1: ファイル収集
|
||||
|
||||
パッケージングするファイルを収集し、リストを作成する。
|
||||
|
||||
**実施内容:**
|
||||
|
||||
1. プラグインディレクトリを確認する
|
||||
2. パッケージング対象のファイルを特定する
|
||||
3. 除外ファイルを確認する（.claudeignore）
|
||||
4. ファイルリストを作成する
|
||||
5. ファイルサイズを集計する
|
||||
|
||||
**収集対象:**
|
||||
|
||||
- README.md（必須）
|
||||
- agents/[agent-name].md
|
||||
- skills/[skill-name]/SKILL.md
|
||||
- commands/[command-name].md
|
||||
- LICENSE（オプション）
|
||||
- CHANGELOG.md（オプション）
|
||||
|
||||
**除外対象:**
|
||||
|
||||
- .git/
|
||||
- node_modules/
|
||||
- .DS_Store
|
||||
- *.tmp
|
||||
- .claudeignore に記載されたファイル
|
||||
|
||||
**良い例:**
|
||||
|
||||
```markdown
|
||||
【ファイル収集結果】
|
||||
|
||||
プラグイン名: database-design-plugin
|
||||
プラグインディレクトリ: D:\projects\database-design-plugin
|
||||
|
||||
収集対象ファイル（11個）:
|
||||
- README.md
|
||||
- agents/database-design-agent.md
|
||||
- skills/entity-definition-collector/SKILL.md
|
||||
- skills/normalization-processor/SKILL.md
|
||||
- skills/er-diagram-generator/SKILL.md
|
||||
- skills/table-definition-writer/SKILL.md
|
||||
- skills/ddl-script-generator/SKILL.md
|
||||
- skills/database-naming-conventions/SKILL.md
|
||||
- skills/normalization-rules/SKILL.md
|
||||
- commands/design-database.md
|
||||
- commands/generate-schema.md
|
||||
|
||||
除外ファイル:
|
||||
- .git/（Gitディレクトリ）
|
||||
- .DS_Store（システムファイル）
|
||||
|
||||
合計サイズ: 125 KB
|
||||
```
|
||||
|
||||
**悪い例:**
|
||||
|
||||
```markdown
|
||||
【ファイル収集結果】
|
||||
|
||||
何かファイルを集めた
|
||||
```
|
||||
|
||||
### フェーズ2: 検証
|
||||
|
||||
収集したファイルの完全性を検証する。
|
||||
|
||||
**実施内容:**
|
||||
|
||||
1. 必須ファイルの存在を確認する
|
||||
2. ファイル形式の正当性を確認する
|
||||
3. フロントマター情報を検証する
|
||||
4. ファイル内容の完全性を確認する
|
||||
5. 検証結果をレポートする
|
||||
|
||||
**検証項目:**
|
||||
|
||||
- README.md が存在するか
|
||||
- 全ての AGENT.md, SKILL.md, COMMAND.md が正しく読み込めるか
|
||||
- フロントマター情報が正しくパースできるか
|
||||
- 必須フィールド（name, description）が存在するか
|
||||
- ファイル内容が破損していないか
|
||||
|
||||
**良い例:**
|
||||
|
||||
```markdown
|
||||
【検証結果】
|
||||
|
||||
必須ファイル: ✓ OK
|
||||
- ✓ README.md が存在する
|
||||
|
||||
ファイル形式: ✓ OK
|
||||
- ✓ 全てのファイルが正しく読み込める（11個）
|
||||
|
||||
フロントマター: ✓ OK
|
||||
- ✓ 全てのフロントマターが正しくパースできる（10個）
|
||||
- ✓ 必須フィールド（name, description）が全て存在する
|
||||
|
||||
ファイル内容: ✓ OK
|
||||
- ✓ 全てのファイルが破損していない
|
||||
|
||||
検証: 合格
|
||||
```
|
||||
|
||||
**悪い例（問題がある場合）:**
|
||||
|
||||
```markdown
|
||||
【検証結果】
|
||||
|
||||
必須ファイル: ✗ NG
|
||||
- ✗ README.md が存在しない
|
||||
|
||||
ファイル形式: ✗ NG
|
||||
- ✗ entity-definition-collector/SKILL.md が読み込めない
|
||||
|
||||
フロントマター: ✗ NG
|
||||
- ✗ normalization-processor/SKILL.md でフロントマターがパースできない
|
||||
|
||||
検証: 不合格（3個の問題）
|
||||
```
|
||||
|
||||
### フェーズ3: メタデータ生成
|
||||
|
||||
パッケージに必要なメタデータファイルを生成する。
|
||||
|
||||
**実施内容:**
|
||||
|
||||
1. package.json を生成する
|
||||
2. VERSION ファイルを生成する
|
||||
3. MANIFEST.md を生成する（ファイルリスト）
|
||||
4. ハッシュ値を計算する（整合性確認用）
|
||||
5. メタデータの妥当性を確認する
|
||||
|
||||
**生成するメタデータ:**
|
||||
|
||||
- **package.json**: プラグインのメタ情報（名前、バージョン、説明、作者など）
|
||||
- **VERSION**: バージョン番号
|
||||
- **MANIFEST.md**: 含まれるファイルのリスト
|
||||
- **CHECKSUM.txt**: ファイルのハッシュ値（オプション）
|
||||
|
||||
**良い例:**
|
||||
|
||||
```markdown
|
||||
【メタデータ生成結果】
|
||||
|
||||
package.json:
|
||||
{
|
||||
"name": "database-design-plugin",
|
||||
"version": "1.0.0",
|
||||
"description": "データベース設計を支援するプラグイン",
|
||||
"author": "Your Name",
|
||||
"created": "2025-11-15",
|
||||
"agents": ["database-design-agent"],
|
||||
"skills": [
|
||||
"entity-definition-collector",
|
||||
"normalization-processor",
|
||||
"er-diagram-generator",
|
||||
"table-definition-writer",
|
||||
"ddl-script-generator",
|
||||
"database-naming-conventions",
|
||||
"normalization-rules"
|
||||
],
|
||||
"commands": ["design-database", "generate-schema"]
|
||||
}
|
||||
|
||||
VERSION:
|
||||
1.0.0
|
||||
|
||||
MANIFEST.md:
|
||||
# Manifest
|
||||
|
||||
このパッケージには以下のファイルが含まれています:
|
||||
|
||||
## プラグイン情報
|
||||
- package.json
|
||||
- VERSION
|
||||
- MANIFEST.md
|
||||
- README.md
|
||||
|
||||
## エージェント
|
||||
- agents/database-design-agent.md
|
||||
|
||||
## スキル
|
||||
- skills/entity-definition-collector/SKILL.md
|
||||
- skills/normalization-processor/SKILL.md
|
||||
- skills/er-diagram-generator/SKILL.md
|
||||
- skills/table-definition-writer/SKILL.md
|
||||
- skills/ddl-script-generator/SKILL.md
|
||||
- skills/database-naming-conventions/SKILL.md
|
||||
- skills/normalization-rules/SKILL.md
|
||||
|
||||
## コマンド
|
||||
- commands/design-database.md
|
||||
- commands/generate-schema.md
|
||||
|
||||
合計: 14ファイル
|
||||
|
||||
メタデータ生成: 完了
|
||||
```
|
||||
|
||||
**悪い例:**
|
||||
|
||||
```markdown
|
||||
【メタデータ生成結果】
|
||||
|
||||
何か作った
|
||||
```
|
||||
|
||||
### フェーズ4: パッケージング
|
||||
|
||||
収集したファイルとメタデータをZIP形式にまとめる。
|
||||
|
||||
**実施内容:**
|
||||
|
||||
1. ZIPファイル名を決定する
|
||||
2. ファイルをZIPに追加する
|
||||
3. ディレクトリ構造を保持する
|
||||
4. 圧縮レベルを設定する
|
||||
5. ZIP作成を実行する
|
||||
|
||||
**パッケージング設定:**
|
||||
|
||||
- **ファイル名形式**: `{plugin-name}-v{version}.zip`
|
||||
- **圧縮レベル**: 標準（balance between size and speed）
|
||||
- **ディレクトリ構造**: 保持する
|
||||
- **ルートディレクトリ**: プラグイン名のディレクトリを作成
|
||||
|
||||
**良い例:**
|
||||
|
||||
```markdown
|
||||
【パッケージング結果】
|
||||
|
||||
ZIPファイル名: database-design-plugin-v1.0.0.zip
|
||||
|
||||
ディレクトリ構造:
|
||||
database-design-plugin/
|
||||
package.json
|
||||
VERSION
|
||||
MANIFEST.md
|
||||
README.md
|
||||
agents/
|
||||
database-design-agent.md
|
||||
skills/
|
||||
entity-definition-collector/
|
||||
SKILL.md
|
||||
normalization-processor/
|
||||
SKILL.md
|
||||
er-diagram-generator/
|
||||
SKILL.md
|
||||
table-definition-writer/
|
||||
SKILL.md
|
||||
ddl-script-generator/
|
||||
SKILL.md
|
||||
database-naming-conventions/
|
||||
SKILL.md
|
||||
normalization-rules/
|
||||
SKILL.md
|
||||
commands/
|
||||
design-database.md
|
||||
generate-schema.md
|
||||
|
||||
ファイル数: 14個
|
||||
圧縮前サイズ: 125 KB
|
||||
圧縮後サイズ: 35 KB
|
||||
圧縮率: 72%
|
||||
|
||||
パッケージング: 完了
|
||||
```
|
||||
|
||||
**悪い例:**
|
||||
|
||||
```markdown
|
||||
【パッケージング結果】
|
||||
|
||||
ZIPを作った
|
||||
```
|
||||
|
||||
### フェーズ5: 出力
|
||||
|
||||
作成したパッケージを出力し、メタデータを記録する。
|
||||
|
||||
**実施内容:**
|
||||
|
||||
1. 出力先ディレクトリを確認する
|
||||
2. ZIPファイルを出力する
|
||||
3. パッケージ情報を記録する
|
||||
4. 配布用ドキュメントを準備する
|
||||
5. 次のステップを案内する
|
||||
|
||||
**出力先:**
|
||||
|
||||
- デフォルト: `{plugin-directory}/dist/`
|
||||
- カスタム: ユーザー指定のディレクトリ
|
||||
|
||||
**良い例:**
|
||||
|
||||
```markdown
|
||||
【出力結果】
|
||||
|
||||
出力先: D:\projects\database-design-plugin\dist\
|
||||
ZIPファイル: database-design-plugin-v1.0.0.zip
|
||||
ZIPファイルパス: D:\projects\database-design-plugin\dist\database-design-plugin-v1.0.0.zip
|
||||
|
||||
パッケージ情報:
|
||||
- プラグイン名: database-design-plugin
|
||||
- バージョン: 1.0.0
|
||||
- 作成日時: 2025-11-15 10:30:00
|
||||
- ファイル数: 14個
|
||||
- 圧縮後サイズ: 35 KB
|
||||
- ハッシュ値（SHA-256）: a1b2c3d4e5f6...
|
||||
|
||||
配布用ドキュメント:
|
||||
- README.md（プラグインの概要、インストール方法、使い方）
|
||||
- CHANGELOG.md（変更履歴）
|
||||
- LICENSE（ライセンス情報）
|
||||
|
||||
【配布方法】
|
||||
|
||||
1. GitHub リリースとして配布
|
||||
- ZIPファイルをアップロード
|
||||
- リリースノートを作成
|
||||
|
||||
2. 手動配布
|
||||
- ZIPファイルを共有
|
||||
- README.md を参照してもらう
|
||||
|
||||
【次のステップ】
|
||||
|
||||
1. パッケージを配布する
|
||||
2. ユーザーにインストール方法を案内する
|
||||
3. フィードバックを収集する
|
||||
|
||||
パッケージング完了: ✓
|
||||
```
|
||||
|
||||
**良い例:**
|
||||
|
||||
出力結果が明確で、パッケージ情報、配布方法、次のステップが案内されている。
|
||||
|
||||
**悪い例:**
|
||||
|
||||
```markdown
|
||||
【出力結果】
|
||||
|
||||
ZIPを作った
|
||||
```
|
||||
|
||||
## アウトプット
|
||||
|
||||
このスキルは以下を生成する:
|
||||
|
||||
- **ZIPファイル**: プラグイン全体をまとめたZIPファイル
|
||||
- **メタデータファイル**: package.json, VERSION, MANIFEST.md
|
||||
- **パッケージ情報レポート**: パッケージの詳細情報（ファイル数、サイズ、ハッシュ値など）
|
||||
|
||||
## 想定されるエラーと対処法
|
||||
|
||||
### エラー1: 必須ファイルが存在しない
|
||||
|
||||
**検出例:**
|
||||
|
||||
```markdown
|
||||
README.md が存在しない
|
||||
```
|
||||
|
||||
**対処法:**
|
||||
|
||||
- README.md を作成する
|
||||
- プラグインの概要、使い方、コマンド一覧を記述する
|
||||
- パッケージングを再実行する
|
||||
|
||||
### エラー2: ファイルが破損している
|
||||
|
||||
**検出例:**
|
||||
|
||||
```markdown
|
||||
entity-definition-collector/SKILL.md が読み込めない
|
||||
```
|
||||
|
||||
**対処法:**
|
||||
|
||||
- ファイルの内容を確認する
|
||||
- ファイルを再生成する
|
||||
- パッケージングを再実行する
|
||||
|
||||
### エラー3: メタデータ生成に失敗
|
||||
|
||||
**検出例:**
|
||||
|
||||
```markdown
|
||||
package.json の生成に失敗した
|
||||
```
|
||||
|
||||
**対処法:**
|
||||
|
||||
- プラグイン名、バージョン、説明が正しいか確認する
|
||||
- メタデータ生成の設定を確認する
|
||||
- 再度メタデータ生成を実行する
|
||||
|
||||
## ベストプラクティス
|
||||
|
||||
- パッケージング前にプラグインを検証する（plugin-validator スキルを使用）
|
||||
- メタデータファイルを必ず含める（package.json, VERSION, MANIFEST.md）
|
||||
- README.md を詳細に記述する（インストール方法、使い方）
|
||||
- CHANGELOG.md を作成する（変更履歴を記録）
|
||||
- LICENSE ファイルを含める（ライセンス情報）
|
||||
- ハッシュ値を記録する（整合性確認用）
|
||||
- 配布用ドキュメントを準備する
|
||||
|
||||
## チェックリスト
|
||||
|
||||
### ファイル収集完了時
|
||||
|
||||
- [ ] プラグインディレクトリが確認されている
|
||||
- [ ] パッケージング対象のファイルが特定されている
|
||||
- [ ] 除外ファイルが確認されている
|
||||
- [ ] ファイルリストが作成されている
|
||||
- [ ] ファイルサイズが集計されている
|
||||
|
||||
### 検証完了時
|
||||
|
||||
- [ ] 必須ファイルの存在が確認されている
|
||||
- [ ] ファイル形式の正当性が確認されている
|
||||
- [ ] フロントマター情報が検証されている
|
||||
- [ ] ファイル内容の完全性が確認されている
|
||||
- [ ] 検証結果がレポートされている
|
||||
|
||||
### メタデータ生成完了時
|
||||
|
||||
- [ ] package.json が生成されている
|
||||
- [ ] VERSION ファイルが生成されている
|
||||
- [ ] MANIFEST.md が生成されている
|
||||
- [ ] ハッシュ値が計算されている（オプション）
|
||||
- [ ] メタデータの妥当性が確認されている
|
||||
|
||||
### パッケージング完了時
|
||||
|
||||
- [ ] ZIPファイル名が決定されている
|
||||
- [ ] ファイルがZIPに追加されている
|
||||
- [ ] ディレクトリ構造が保持されている
|
||||
- [ ] 圧縮レベルが設定されている
|
||||
- [ ] ZIP作成が実行されている
|
||||
|
||||
### 出力完了時
|
||||
|
||||
- [ ] 出力先ディレクトリが確認されている
|
||||
- [ ] ZIPファイルが出力されている
|
||||
- [ ] パッケージ情報が記録されている
|
||||
- [ ] 配布用ドキュメントが準備されている
|
||||
- [ ] 次のステップが案内されている
|
||||
- [ ] ユーザーの承認を得ている
|
||||
|
||||
### 最終確認
|
||||
|
||||
- [ ] ZIPファイルが作成されている
|
||||
- [ ] メタデータファイルが生成されている
|
||||
- [ ] パッケージ情報レポートが作成されている
|
||||
- [ ] すべてのアウトプットが明確で理解しやすい
|
||||
- [ ] ユーザーがパッケージを配布できる状態になっている
|
||||
538
skills/plugin-validator/SKILL.md
Normal file
538
skills/plugin-validator/SKILL.md
Normal file
@@ -0,0 +1,538 @@
|
||||
---
|
||||
name: plugin-validator
|
||||
description: 生成したプラグイン全体の整合性・完全性を検証する。プラグイン検証時、品質チェック時、またはユーザーがプラグイン検証、整合性確認、完全性チェック、品質保証、バリデーションに言及した際に使用する。
|
||||
---
|
||||
|
||||
# Plugin Validator
|
||||
|
||||
## 概要
|
||||
|
||||
このSkillは、生成したプラグイン全体の整合性・完全性を検証する。プラグインのディレクトリ構造、ファイル形式、要素間の整合性、ドキュメント品質を確認し、問題を検出して改善提案を行う。
|
||||
|
||||
## 責任範囲
|
||||
|
||||
このSkillは以下の範囲をカバーする:
|
||||
|
||||
- プラグインディレクトリ構造の検証
|
||||
- 必須ファイルの存在確認
|
||||
- フロントマター形式の検証
|
||||
- 要素間の整合性検証
|
||||
- ドキュメント品質の検証（markdownlint）
|
||||
- アーキテクチャ規約の遵守確認
|
||||
- 検証レポートの作成
|
||||
|
||||
## ワークフロー
|
||||
|
||||
### フェーズ1: プラグイン読込
|
||||
|
||||
プラグインディレクトリを読み込み、全ファイルを収集する。
|
||||
|
||||
**実施内容:**
|
||||
|
||||
1. プラグインディレクトリのパスを確認する
|
||||
2. ディレクトリ構造を読み込む
|
||||
3. 全ファイルのリストを作成する
|
||||
4. 各ファイルの内容を読み込む
|
||||
5. フロントマター情報を抽出する
|
||||
|
||||
**確認対象:**
|
||||
|
||||
- README.md（プラグインルート）
|
||||
- agents/*.md
|
||||
- skills/*/SKILL.md
|
||||
- commands/*.md
|
||||
- .claudeignore（オプション）
|
||||
|
||||
**良い例:**
|
||||
|
||||
```markdown
|
||||
【プラグイン読込結果】
|
||||
|
||||
プラグイン名: database-design-plugin
|
||||
プラグインディレクトリ: D:\projects\database-design-plugin
|
||||
|
||||
ファイル構造:
|
||||
database-design-plugin/
|
||||
README.md
|
||||
agents/
|
||||
database-design-agent/
|
||||
AGENT.md
|
||||
skills/
|
||||
entity-definition-collector/
|
||||
SKILL.md
|
||||
normalization-processor/
|
||||
SKILL.md
|
||||
er-diagram-generator/
|
||||
SKILL.md
|
||||
table-definition-writer/
|
||||
SKILL.md
|
||||
ddl-script-generator/
|
||||
SKILL.md
|
||||
database-naming-conventions/
|
||||
SKILL.md
|
||||
normalization-rules/
|
||||
SKILL.md
|
||||
commands/
|
||||
design-database/
|
||||
COMMAND.md
|
||||
generate-schema/
|
||||
COMMAND.md
|
||||
|
||||
ファイル数:
|
||||
- README.md: 1個
|
||||
- AGENT.md: 1個
|
||||
- SKILL.md: 7個
|
||||
- COMMAND.md: 2個
|
||||
- 合計: 11個
|
||||
```
|
||||
|
||||
**悪い例:**
|
||||
|
||||
```markdown
|
||||
【プラグイン読込結果】
|
||||
|
||||
何かファイルがある
|
||||
```
|
||||
|
||||
### フェーズ2: 構造検証
|
||||
|
||||
プラグインのディレクトリ構造とファイル形式が正しいか検証する。
|
||||
|
||||
**実施内容:**
|
||||
|
||||
1. 必須ファイルの存在を確認する
|
||||
2. ディレクトリ構造が規約に従っているか確認する
|
||||
3. ファイル名が規約に従っているか確認する
|
||||
4. フロントマター形式が正しいか確認する
|
||||
5. 必須フロントマターフィールドの存在を確認する
|
||||
|
||||
**検証項目:**
|
||||
|
||||
- README.md が存在するか
|
||||
- agents/, skills/, commands/ ディレクトリが存在するか
|
||||
- 各要素がサブディレクトリに配置されているか
|
||||
- AGENT.md, SKILL.md, COMMAND.md のファイル名が正しいか
|
||||
- フロントマターが正しくパースできるか
|
||||
- 必須フィールド（name, description）が存在するか
|
||||
|
||||
**良い例:**
|
||||
|
||||
```markdown
|
||||
【構造検証結果】
|
||||
|
||||
必須ファイル: ✓ OK
|
||||
- ✓ README.md が存在する
|
||||
- ✓ agents/ ディレクトリが存在する
|
||||
- ✓ skills/ ディレクトリが存在する
|
||||
- ✓ commands/ ディレクトリが存在する
|
||||
|
||||
ディレクトリ構造: ✓ OK
|
||||
- ✓ agents/database-design-agent.md
|
||||
- ✓ skills/entity-definition-collector/SKILL.md
|
||||
- ✓ skills/normalization-processor/SKILL.md
|
||||
- ✓ skills/er-diagram-generator/SKILL.md
|
||||
- ✓ skills/table-definition-writer/SKILL.md
|
||||
- ✓ skills/ddl-script-generator/SKILL.md
|
||||
- ✓ skills/database-naming-conventions/SKILL.md
|
||||
- ✓ skills/normalization-rules/SKILL.md
|
||||
- ✓ commands/design-database.md
|
||||
- ✓ commands/generate-schema.md
|
||||
|
||||
フロントマター形式: ✓ OK
|
||||
- ✓ 全てのファイルでフロントマターがパースできる
|
||||
|
||||
必須フィールド: ✓ OK
|
||||
- ✓ 全てのファイルで name フィールドが存在する
|
||||
- ✓ 全てのファイルで description フィールドが存在する
|
||||
|
||||
エージェント固有フィールド: ✓ OK
|
||||
- ✓ database-design-agent に tools フィールドが存在する
|
||||
|
||||
構造検証: 合格
|
||||
```
|
||||
|
||||
**悪い例（問題がある場合）:**
|
||||
|
||||
```markdown
|
||||
【構造検証結果】
|
||||
|
||||
必須ファイル: ✗ NG
|
||||
- ✗ README.md が存在しない
|
||||
|
||||
ディレクトリ構造: ✗ NG
|
||||
- ✗ agents/database-design-agent.md が存在しない
|
||||
- ✗ skills/entity-collector.md（ファイル名が SKILL.md ではない）
|
||||
|
||||
フロントマター形式: ✗ NG
|
||||
- ✗ agents/database-design-agent.md でフロントマターがパースできない
|
||||
|
||||
必須フィールド: ✗ NG
|
||||
- ✗ skills/entity-definition-collector/SKILL.md に description フィールドが存在しない
|
||||
|
||||
構造検証: 不合格（4個の問題）
|
||||
```
|
||||
|
||||
### フェーズ3: 整合性検証
|
||||
|
||||
要素間の整合性を検証する。
|
||||
|
||||
**実施内容:**
|
||||
|
||||
1. コマンドが参照するエージェントが存在するか確認する
|
||||
2. コマンドが参照するスキルが存在するか確認する
|
||||
3. 要素名の一貫性を確認する（ファイル名とフロントマターのname）
|
||||
4. 循環依存がないか確認する
|
||||
5. アーキテクチャ規約の遵守を確認する
|
||||
|
||||
**検証項目:**
|
||||
|
||||
- コマンドが参照するエージェントが実在するか
|
||||
- コマンドが参照するスキルが実在するか
|
||||
- ディレクトリ名とフロントマターのnameが一致するか
|
||||
- エージェントが他の要素を直接参照していないか
|
||||
- スキルが他のスキルを参照していないか
|
||||
- 循環依存がないか
|
||||
|
||||
**良い例:**
|
||||
|
||||
```markdown
|
||||
【整合性検証結果】
|
||||
|
||||
エージェント参照: ✓ OK
|
||||
- ✓ design-database が参照する database-design-agent は存在する
|
||||
- ✓ generate-schema が参照する database-design-agent は存在する
|
||||
|
||||
スキル参照: ✓ OK
|
||||
- ✓ design-database が参照する全てのスキル（7個）が存在する
|
||||
- ✓ generate-schema が参照する全てのスキル（4個）が存在する
|
||||
|
||||
要素名の一貫性: ✓ OK
|
||||
- ✓ ディレクトリ名とフロントマターのnameが全て一致する
|
||||
|
||||
循環依存: ✓ OK
|
||||
- ✓ 循環依存は検出されませんでした
|
||||
|
||||
アーキテクチャ規約: ✓ OK
|
||||
- ✓ エージェントは他の要素を直接参照していない
|
||||
- ✓ スキルは他のスキルを参照していない
|
||||
- ✓ コマンドのみがエージェントとスキルを参照している
|
||||
|
||||
整合性検証: 合格
|
||||
```
|
||||
|
||||
**悪い例（問題がある場合）:**
|
||||
|
||||
```markdown
|
||||
【整合性検証結果】
|
||||
|
||||
エージェント参照: ✗ NG
|
||||
- ✗ design-database が参照する db-agent が存在しない
|
||||
|
||||
スキル参照: ✗ NG
|
||||
- ✗ design-database が参照する entity-collector が存在しない
|
||||
|
||||
要素名の一貫性: ✗ NG
|
||||
- ✗ agents/database-design-agent/ のnameが "db-agent" になっている
|
||||
|
||||
循環依存: ✗ NG
|
||||
- ✗ skill-a → skill-b → skill-c → skill-a の循環依存が検出された
|
||||
|
||||
アーキテクチャ規約: ✗ NG
|
||||
- ✗ database-design-agent が entity-definition-collector を直接参照している
|
||||
- ✗ normalization-processor が database-naming-conventions を参照している
|
||||
|
||||
整合性検証: 不合格（6個の問題）
|
||||
```
|
||||
|
||||
### フェーズ4: 品質検証
|
||||
|
||||
ドキュメントの品質を検証する。
|
||||
|
||||
**実施内容:**
|
||||
|
||||
1. markdownlint検証を実施する
|
||||
2. 必須セクションの存在を確認する
|
||||
3. セクションの順序を確認する
|
||||
4. ドキュメントの充実度を評価する
|
||||
5. 良い例/悪い例の存在を確認する（該当する場合）
|
||||
|
||||
**検証項目:**
|
||||
|
||||
- markdownlintエラーがないか
|
||||
- 必須セクション（概要、責任範囲、ワークフローなど）が存在するか
|
||||
- セクションの順序が正しいか
|
||||
- 各セクションに内容が記述されているか
|
||||
- 良い例/悪い例が記述されているか（ワークフロースキル、コンベンションスキル）
|
||||
|
||||
**良い例:**
|
||||
|
||||
```markdown
|
||||
【品質検証結果】
|
||||
|
||||
markdownlint検証: ✓ OK
|
||||
- ✓ 全てのファイルでmarkdownlintエラーなし
|
||||
|
||||
必須セクション: ✓ OK
|
||||
エージェント:
|
||||
- ✓ database-design-agent: 役割、責任範囲、注意事項が存在する
|
||||
|
||||
スキル（ワークフロー）:
|
||||
- ✓ entity-definition-collector: 概要、責任範囲、ワークフロー、アウトプットが存在する
|
||||
- ✓ normalization-processor: 概要、責任範囲、ワークフロー、アウトプットが存在する
|
||||
- ✓ er-diagram-generator: 概要、責任範囲、ワークフロー、アウトプットが存在する
|
||||
- ✓ table-definition-writer: 概要、責任範囲、ワークフロー、アウトプットが存在する
|
||||
- ✓ ddl-script-generator: 概要、責任範囲、ワークフロー、アウトプットが存在する
|
||||
|
||||
スキル（コンベンション）:
|
||||
- ✓ database-naming-conventions: 概要、責任範囲、カテゴリ別規約が存在する
|
||||
- ✓ normalization-rules: 概要、責任範囲、カテゴリ別規約が存在する
|
||||
|
||||
コマンド:
|
||||
- ✓ design-database: 概要、使用するエージェント、使用するスキル、実行フローが存在する
|
||||
- ✓ generate-schema: 概要、使用するエージェント、使用するスキル、実行フローが存在する
|
||||
|
||||
ドキュメント充実度: ✓ 優良
|
||||
- ✓ 全てのセクションに詳細な内容が記述されている
|
||||
- ✓ ワークフロースキルに良い例/悪い例が記述されている
|
||||
- ✓ コンベンションスキルに良い例/悪い例が記述されている
|
||||
- ✓ チェックリストが詳細に記述されている
|
||||
|
||||
品質検証: 合格
|
||||
```
|
||||
|
||||
**悪い例（問題がある場合）:**
|
||||
|
||||
```markdown
|
||||
【品質検証結果】
|
||||
|
||||
markdownlint検証: ✗ NG
|
||||
- ✗ entity-definition-collector/SKILL.md: MD009（行末の空白）
|
||||
- ✗ normalization-processor/SKILL.md: MD013（行の長さ）
|
||||
- ✗ design-database/COMMAND.md: MD022（見出しの前後の空行）
|
||||
|
||||
必須セクション: ✗ NG
|
||||
- ✗ entity-definition-collector: ワークフローセクションが存在しない
|
||||
- ✗ normalization-processor: アウトプットセクションが存在しない
|
||||
|
||||
ドキュメント充実度: △ 改善の余地あり
|
||||
- △ 概要セクションの記述が不十分（2ファイル）
|
||||
- △ ワークフロースキルに良い例/悪い例が記述されていない（3ファイル）
|
||||
- △ チェックリストが簡素すぎる（4ファイル）
|
||||
|
||||
品質検証: 不合格（8個の問題）
|
||||
```
|
||||
|
||||
### フェーズ5: レポート作成
|
||||
|
||||
検証結果をまとめ、改善提案をレポートとして作成する。
|
||||
|
||||
**実施内容:**
|
||||
|
||||
1. 全ての検証結果をサマリー化する
|
||||
2. 検出された問題を重要度別に分類する
|
||||
3. 各問題の改善方法を提案する
|
||||
4. プラグインの品質スコアを算出する
|
||||
5. 次のステップを案内する
|
||||
|
||||
**提示形式:**
|
||||
|
||||
```markdown
|
||||
【プラグイン検証レポート】
|
||||
|
||||
プラグイン名: database-design-plugin
|
||||
検証日時: 2025-11-15
|
||||
|
||||
【総合評価】
|
||||
|
||||
総合スコア: 95/100（優良）
|
||||
|
||||
内訳:
|
||||
- 構造検証: 25/25 ✓
|
||||
- 整合性検証: 25/25 ✓
|
||||
- 品質検証: 20/25 △
|
||||
- アーキテクチャ規約: 25/25 ✓
|
||||
|
||||
評価: 優良
|
||||
- プラグインは高品質で、リリース可能な状態です
|
||||
|
||||
【検証結果サマリー】
|
||||
|
||||
構造検証: ✓ 合格
|
||||
- 必須ファイル: OK
|
||||
- ディレクトリ構造: OK
|
||||
- フロントマター形式: OK
|
||||
- 必須フィールド: OK
|
||||
|
||||
整合性検証: ✓ 合格
|
||||
- エージェント参照: OK
|
||||
- スキル参照: OK
|
||||
- 要素名の一貫性: OK
|
||||
- 循環依存: OK
|
||||
- アーキテクチャ規約: OK
|
||||
|
||||
品質検証: △ 改善の余地あり
|
||||
- markdownlint検証: OK
|
||||
- 必須セクション: OK
|
||||
- ドキュメント充実度: 一部改善の余地あり
|
||||
|
||||
【検出された問題】
|
||||
|
||||
重要度1（必須修正）: 0個
|
||||
|
||||
重要度2（推奨修正）: 2個
|
||||
1. ワークフロースキルの一部で良い例/悪い例が不足している
|
||||
- 対象: er-diagram-generator, table-definition-writer
|
||||
- 改善方法: 各フェーズに良い例/悪い例を追加する
|
||||
|
||||
2. チェックリストの粒度が粗い
|
||||
- 対象: ddl-script-generator
|
||||
- 改善方法: チェックリストをより詳細にする
|
||||
|
||||
重要度3（任意修正）: 0個
|
||||
|
||||
【改善提案】
|
||||
|
||||
1. ワークフロースキルに良い例/悪い例を追加する
|
||||
- er-diagram-generator: ER図の良い例/悪い例
|
||||
- table-definition-writer: テーブル定義書の良い例/悪い例
|
||||
|
||||
2. チェックリストを詳細化する
|
||||
- ddl-script-generator: DDLスクリプト生成時のチェックリストを詳細にする
|
||||
|
||||
3. README.mdを充実させる（推奨）
|
||||
- プラグインの概要、使い方、コマンド一覧を追加する
|
||||
|
||||
【次のステップ】
|
||||
|
||||
1. 検出された問題を修正する（任意）
|
||||
2. プラグインをパッケージングする（plugin-packager スキルを使用）
|
||||
3. プラグインをリリースする
|
||||
|
||||
【詳細レポート】
|
||||
|
||||
（各検証フェーズの詳細結果を添付）
|
||||
```
|
||||
|
||||
**良い例:**
|
||||
|
||||
検証結果が明確で、問題点、改善提案、次のステップが示されている。
|
||||
|
||||
**悪い例:**
|
||||
|
||||
```markdown
|
||||
【プラグイン検証レポート】
|
||||
|
||||
検証した
|
||||
問題なし
|
||||
```
|
||||
|
||||
## アウトプット
|
||||
|
||||
このスキルは以下を生成する:
|
||||
|
||||
- **プラグイン検証レポート**: 構造、整合性、品質の検証結果をまとめたレポート
|
||||
- **問題リスト**: 検出された問題と改善方法のリスト
|
||||
- **品質スコア**: プラグインの品質を数値化したスコア
|
||||
|
||||
## 想定されるエラーと対処法
|
||||
|
||||
### エラー1: 必須ファイルが存在しない
|
||||
|
||||
**検出例:**
|
||||
|
||||
```markdown
|
||||
README.md が存在しない
|
||||
```
|
||||
|
||||
**対処法:**
|
||||
|
||||
- README.md を作成する
|
||||
- プラグインの概要、使い方、コマンド一覧を記述する
|
||||
|
||||
### エラー2: フロントマターが不正
|
||||
|
||||
**検出例:**
|
||||
|
||||
```markdown
|
||||
フロントマターがパースできない
|
||||
```
|
||||
|
||||
**対処法:**
|
||||
|
||||
- フロントマターの形式を確認する（YAML形式）
|
||||
- 必須フィールド（name, description）が存在するか確認する
|
||||
- インデントやコロンの位置を確認する
|
||||
|
||||
### エラー3: 循環依存が検出された
|
||||
|
||||
**検出例:**
|
||||
|
||||
```markdown
|
||||
skill-a → skill-b → skill-a
|
||||
```
|
||||
|
||||
**対処法:**
|
||||
|
||||
- スキル間の参照を削除する
|
||||
- 共通の処理をコンベンションスキルに分離する
|
||||
- コマンドで依存関係を管理する
|
||||
|
||||
## ベストプラクティス
|
||||
|
||||
- 定期的にプラグインを検証する
|
||||
- 問題を早期に検出して修正する
|
||||
- markdownlintエラーをゼロにする
|
||||
- アーキテクチャ規約を遵守する
|
||||
- ドキュメントを充実させる（良い例/悪い例、チェックリスト）
|
||||
- README.mdを詳細に記述する
|
||||
|
||||
## チェックリスト
|
||||
|
||||
### プラグイン読込完了時
|
||||
|
||||
- [ ] プラグインディレクトリのパスが確認されている
|
||||
- [ ] ディレクトリ構造が読み込まれている
|
||||
- [ ] 全ファイルのリストが作成されている
|
||||
- [ ] 各ファイルの内容が読み込まれている
|
||||
- [ ] フロントマター情報が抽出されている
|
||||
|
||||
### 構造検証完了時
|
||||
|
||||
- [ ] 必須ファイルの存在が確認されている
|
||||
- [ ] ディレクトリ構造が規約に従っているか確認されている
|
||||
- [ ] ファイル名が規約に従っているか確認されている
|
||||
- [ ] フロントマター形式が正しいか確認されている
|
||||
- [ ] 必須フロントマターフィールドの存在が確認されている
|
||||
|
||||
### 整合性検証完了時
|
||||
|
||||
- [ ] コマンドが参照するエージェントの存在が確認されている
|
||||
- [ ] コマンドが参照するスキルの存在が確認されている
|
||||
- [ ] 要素名の一貫性が確認されている
|
||||
- [ ] 循環依存がないか確認されている
|
||||
- [ ] アーキテクチャ規約の遵守が確認されている
|
||||
|
||||
### 品質検証完了時
|
||||
|
||||
- [ ] markdownlint検証が実施されている
|
||||
- [ ] 必須セクションの存在が確認されている
|
||||
- [ ] セクションの順序が確認されている
|
||||
- [ ] ドキュメントの充実度が評価されている
|
||||
- [ ] 良い例/悪い例の存在が確認されている（該当する場合）
|
||||
|
||||
### レポート作成完了時
|
||||
|
||||
- [ ] 全ての検証結果がサマリー化されている
|
||||
- [ ] 検出された問題が重要度別に分類されている
|
||||
- [ ] 各問題の改善方法が提案されている
|
||||
- [ ] プラグインの品質スコアが算出されている
|
||||
- [ ] 次のステップが案内されている
|
||||
- [ ] ユーザーの承認を得ている
|
||||
|
||||
### 最終確認
|
||||
|
||||
- [ ] プラグイン検証レポートが作成されている
|
||||
- [ ] 問題リストが作成されている
|
||||
- [ ] 品質スコアが算出されている
|
||||
- [ ] すべてのアウトプットが明確で理解しやすい
|
||||
- [ ] ユーザーが次のステップに進める状態になっている
|
||||
454
skills/responsibility-mapper/SKILL.md
Normal file
454
skills/responsibility-mapper/SKILL.md
Normal file
@@ -0,0 +1,454 @@
|
||||
---
|
||||
name: responsibility-mapper
|
||||
description: 作業の責任範囲を整理し、エージェント定義に必要な情報を抽出する。エージェント設計時、責任範囲整理時、またはユーザーが責任範囲、役割分担、責任境界、エージェント構成に言及した際に使用する。
|
||||
---
|
||||
|
||||
# Responsibility Mapper
|
||||
|
||||
## 概要
|
||||
|
||||
このSkillは、ユーザーが提供する作業や業務の情報を基に、責任範囲を整理し、エージェント定義に必要な情報を抽出する。ユーザーとの対話を通じて責任の境界を明確にし、適切なエージェント構成を提案する。
|
||||
|
||||
## 責任範囲
|
||||
|
||||
このSkillは以下の範囲をカバーする:
|
||||
|
||||
- 作業や業務の責任範囲の収集
|
||||
- 責任範囲の分類と整理
|
||||
- 責任範囲内・責任範囲外の明確化
|
||||
- エージェント候補の特定と分類
|
||||
- 推奨エージェント構成の提案
|
||||
- エージェント定義情報の作成
|
||||
|
||||
## ワークフロー
|
||||
|
||||
### フェーズ1: 責任収集
|
||||
|
||||
ユーザーとの対話を通じて、作業や業務の責任範囲に関する情報を収集する。
|
||||
|
||||
**実施内容:**
|
||||
|
||||
1. 対象となる作業や業務を確認する
|
||||
2. 作業の目的と範囲を把握する
|
||||
3. 担当者や役割を特定する
|
||||
4. 責任の境界を確認する
|
||||
5. 関連する作業やシステムを把握する
|
||||
|
||||
**質問例:**
|
||||
|
||||
```markdown
|
||||
【責任範囲の確認】
|
||||
エージェントに担当させたい責任範囲を教えてください。
|
||||
|
||||
1. フェーズ全体（例: 要件定義フェーズ全体、設計フェーズ全体）
|
||||
2. 領域全体（例: セキュリティ領域全体、品質管理領域全体）
|
||||
3. 特定の役割（例: レビュー担当、ドキュメント作成担当）
|
||||
4. その他（具体的に教えてください）
|
||||
```
|
||||
|
||||
**良い例:**
|
||||
|
||||
```markdown
|
||||
責任範囲: データベース設計フェーズ全体
|
||||
目的: データベーススキーマの設計、正規化、ドキュメント作成を一貫して管理する
|
||||
担当者: データベースエンジニア、バックエンド開発者
|
||||
境界:
|
||||
- 開始: 要件定義が完了し、エンティティの候補が特定された時点
|
||||
- 終了: テーブル定義書とDDLスクリプトが作成され、レビューが完了した時点
|
||||
関連:
|
||||
- 前工程: 要件定義（エンティティ候補の提供）
|
||||
- 後工程: データベース構築（DDLスクリプトの実行）
|
||||
```
|
||||
|
||||
**悪い例:**
|
||||
|
||||
```markdown
|
||||
責任範囲: データベース
|
||||
目的: いろいろやる
|
||||
担当者: 誰か
|
||||
境界: よくわからない
|
||||
```
|
||||
|
||||
### フェーズ2: 責任分類
|
||||
|
||||
収集した責任範囲を、カテゴリ別に分類し整理する。
|
||||
|
||||
**実施内容:**
|
||||
|
||||
1. 責任範囲をフェーズ別、領域別、役割別に分類する
|
||||
2. 責任の粒度を評価する（大きすぎる、適切、小さすぎる）
|
||||
3. 責任の重複を確認する
|
||||
4. 責任のギャップを特定する
|
||||
5. 責任の優先順位を付ける
|
||||
|
||||
**分類基準:**
|
||||
|
||||
- **フェーズ別**: 開発プロセスの特定フェーズに対する責任（要件定義、設計、実装など）
|
||||
- **領域別**: 特定の技術領域や品質領域に対する責任（セキュリティ、パフォーマンス、テストなど）
|
||||
- **役割別**: 特定の役割や作業に対する責任（レビュー、ドキュメント作成、検証など）
|
||||
|
||||
**良い例:**
|
||||
|
||||
```markdown
|
||||
【責任分類結果】
|
||||
|
||||
フェーズ別責任:
|
||||
- データベース設計フェーズ全体
|
||||
- エンティティ定義
|
||||
- 正規化
|
||||
- ER図作成
|
||||
- テーブル定義書作成
|
||||
- DDLスクリプト生成
|
||||
|
||||
粒度評価: 適切
|
||||
- 1つのフェーズとして明確な範囲がある
|
||||
- 作業の開始と終了が明確
|
||||
- 成果物が定義されている
|
||||
|
||||
重複確認:
|
||||
- 要件定義フェーズとの境界: エンティティ候補の特定は要件定義の責任
|
||||
- データベース構築フェーズとの境界: DDLスクリプトの実行は構築の責任
|
||||
|
||||
優先順位:
|
||||
1. エンティティ定義（最も重要、後続作業の基礎）
|
||||
2. 正規化（品質の要）
|
||||
3. テーブル定義書作成（ドキュメント）
|
||||
4. ER図作成（可視化）
|
||||
5. DDLスクリプト生成（自動化）
|
||||
```
|
||||
|
||||
**悪い例:**
|
||||
|
||||
```markdown
|
||||
【責任分類結果】
|
||||
|
||||
フェーズ: いろいろ
|
||||
粒度: たぶん良い
|
||||
重複: 知らない
|
||||
```
|
||||
|
||||
### フェーズ3: 範囲定義
|
||||
|
||||
責任範囲内と責任範囲外を明確に定義する。
|
||||
|
||||
**実施内容:**
|
||||
|
||||
1. 責任範囲内の項目を列挙する
|
||||
2. 責任範囲外の項目を列挙する
|
||||
3. 境界が曖昧な項目を明確にする
|
||||
4. 注意事項を整理する
|
||||
5. 制約条件を確認する
|
||||
|
||||
**定義基準:**
|
||||
|
||||
- **責任範囲内**: エージェントが明確に担当する範囲
|
||||
- 具体的で検証可能
|
||||
- 開始と終了が明確
|
||||
- 成果物が定義されている
|
||||
- **責任範囲外**: エージェントが担当しない範囲
|
||||
- 混同しやすい範囲
|
||||
- 他のエージェントや人間の責任
|
||||
- 明示的に除外すべき範囲
|
||||
|
||||
**良い例:**
|
||||
|
||||
```markdown
|
||||
【責任範囲定義】
|
||||
|
||||
責任範囲内:
|
||||
|
||||
**エンティティ定義:** エンティティの特定、属性の定義、関連の整理を行う
|
||||
**正規化:** 第1正規形〜第3正規形への変換、正規化ルールの検証を行う
|
||||
**ER図作成:** エンティティ関連図の生成、レイアウト最適化を行う
|
||||
**テーブル定義書作成:** テーブル定義、カラム定義、制約定義をドキュメント化する
|
||||
**DDLスクリプト生成:** データベース製品別のCREATE TABLE文、制約定義を生成する
|
||||
|
||||
責任範囲外:
|
||||
|
||||
**エンティティ候補の特定:** 要件定義フェーズの責任であり、このエージェントは候補を受け取る側
|
||||
**DDLスクリプトの実行:** データベース構築フェーズの責任であり、このエージェントはスクリプトを提供する側
|
||||
**パフォーマンスチューニング:** データベース運用の責任であり、設計フェーズでは考慮するが実施しない
|
||||
|
||||
注意事項:
|
||||
|
||||
- エンティティ定義は要件定義からの引き継ぎを明確にする
|
||||
- 正規化は必ずルールに基づいて実施する
|
||||
- ER図は自動生成を基本とし、手動調整は最小限にする
|
||||
- テーブル定義書はMarkdown形式で作成する
|
||||
- DDLスクリプトは対象データベース製品を明示する
|
||||
```
|
||||
|
||||
**悪い例:**
|
||||
|
||||
```markdown
|
||||
【責任範囲定義】
|
||||
|
||||
責任範囲内: データベースのこと
|
||||
責任範囲外: データベース以外のこと
|
||||
```
|
||||
|
||||
### フェーズ4: エージェント分類
|
||||
|
||||
定義した責任範囲を基に、エージェント候補を特定し分類する。
|
||||
|
||||
**実施内容:**
|
||||
|
||||
1. 責任範囲からエージェント候補を特定する
|
||||
2. エージェントの役割を定義する
|
||||
3. エージェントの使用可能なツールを確認する
|
||||
4. エージェントの表示色を決定する
|
||||
5. エージェント間の依存関係を整理する
|
||||
|
||||
**分類基準:**
|
||||
|
||||
- 1エージェントは1つの明確な責任範囲を持つ
|
||||
- エージェントの粒度は適切である（大きすぎず、小さすぎず）
|
||||
- エージェント間の境界が明確である
|
||||
- エージェントの役割が重複していない
|
||||
|
||||
**良い例:**
|
||||
|
||||
```markdown
|
||||
【エージェント分類結果】
|
||||
|
||||
エージェント候補:
|
||||
|
||||
1. database-design-agent
|
||||
- 役割: データベース設計フェーズ全体に対する責任を持つ
|
||||
- 責任範囲: エンティティ定義、正規化、ER図作成、テーブル定義書作成、DDLスクリプト生成
|
||||
- 使用可能なツール: All tools (Read, Write, Bash, Grep, Glob など)
|
||||
- 表示色: blue（設計フェーズを示す色）
|
||||
- モデル: inherit（デフォルトモデルを使用）
|
||||
|
||||
責任範囲内:
|
||||
- エンティティ定義: エンティティの特定、属性の定義、関連の整理を行う
|
||||
- 正規化: 第1正規形〜第3正規形への変換、正規化ルールの検証を行う
|
||||
- ER図作成: エンティティ関連図の生成、レイアウト最適化を行う
|
||||
- テーブル定義書作成: テーブル定義、カラム定義、制約定義をドキュメント化する
|
||||
- DDLスクリプト生成: データベース製品別のCREATE TABLE文、制約定義を生成する
|
||||
|
||||
責任範囲外:
|
||||
- エンティティ候補の特定: 要件定義フェーズの責任
|
||||
- DDLスクリプトの実行: データベース構築フェーズの責任
|
||||
- パフォーマンスチューニング: データベース運用の責任
|
||||
|
||||
注意事項:
|
||||
- エンティティ定義は要件定義からの引き継ぎを明確にする
|
||||
- 正規化は必ずルールに基づいて実施する
|
||||
- ER図は自動生成を基本とし、手動調整は最小限にする
|
||||
- テーブル定義書はMarkdown形式で作成する
|
||||
- DDLスクリプトは対象データベース製品を明示する
|
||||
|
||||
依存関係:
|
||||
- 前工程: 要件定義エージェント（エンティティ候補の提供を受ける）
|
||||
- 後工程: データベース構築エージェント（DDLスクリプトを提供する）
|
||||
- 使用するスキル: entity-definition-collector, normalization-processor, er-diagram-generator など
|
||||
```
|
||||
|
||||
**悪い例:**
|
||||
|
||||
```markdown
|
||||
エージェント: データベース担当
|
||||
役割: データベースのことをやる
|
||||
```
|
||||
|
||||
### フェーズ5: 推奨提示
|
||||
|
||||
分類結果を基に、推奨されるエージェント構成をユーザーに提示する。
|
||||
|
||||
**実施内容:**
|
||||
|
||||
1. 推奨されるエージェント構成を提示する
|
||||
2. 各エージェントの定義情報をまとめる
|
||||
3. エージェント間の関係を図示する
|
||||
4. 実装の優先順位を提案する
|
||||
5. 次のステップ（エージェントの詳細設計）を案内する
|
||||
|
||||
**提示形式:**
|
||||
|
||||
```markdown
|
||||
【推奨エージェント構成】
|
||||
|
||||
エージェント数: 1個
|
||||
|
||||
エージェント1: database-design-agent
|
||||
- 説明: データベース設計フェーズ全体に対する責任を持つ
|
||||
- 責任範囲: エンティティ定義、正規化、ER図作成、テーブル定義書作成、DDLスクリプト生成
|
||||
- 表示色: blue
|
||||
- 使用可能なツール: All tools
|
||||
|
||||
【責任範囲マップ】
|
||||
|
||||
database-design-agent の責任範囲:
|
||||
|
||||
責任範囲内:
|
||||
- エンティティ定義
|
||||
- 正規化
|
||||
- ER図作成
|
||||
- テーブル定義書作成
|
||||
- DDLスクリプト生成
|
||||
|
||||
責任範囲外:
|
||||
- エンティティ候補の特定（要件定義の責任）
|
||||
- DDLスクリプトの実行（データベース構築の責任）
|
||||
- パフォーマンスチューニング（データベース運用の責任）
|
||||
|
||||
【エージェント定義情報】
|
||||
|
||||
database-design-agent 用のエージェント定義ファイル情報:
|
||||
|
||||
フロントマター:
|
||||
- name: database-design-agent
|
||||
- description: データベース設計フェーズ全体に対する責任を持つ
|
||||
- tools: "*"
|
||||
- model: inherit
|
||||
- color: blue
|
||||
|
||||
役割:
|
||||
データベース設計フェーズ全体に対する責任を持ち、エンティティ定義から DDL スクリプト生成までを一貫して管理する。要件定義フェーズから引き継いだエンティティ候補を基に、正規化されたテーブル定義を作成し、ER 図とテーブル定義書、DDL スクリプトを生成する。
|
||||
|
||||
責任範囲:
|
||||
（上記の責任範囲内・外をそのまま使用）
|
||||
|
||||
注意事項:
|
||||
- エンティティ定義は要件定義からの引き継ぎを明確にする
|
||||
- 正規化は必ずルールに基づいて実施する
|
||||
- ER図は自動生成を基本とし、手動調整は最小限にする
|
||||
- テーブル定義書はMarkdown形式で作成する
|
||||
- DDLスクリプトは対象データベース製品を明示する
|
||||
|
||||
【実装優先順位】
|
||||
|
||||
優先度1（必須）:
|
||||
- database-design-agent の作成
|
||||
|
||||
【次のステップ】
|
||||
|
||||
1. database-design-agent の詳細設計（agent-generator スキルを使用）
|
||||
2. 関連するスキルの設計（workflow-analyzer スキルを使用）
|
||||
3. コマンドの設計（command-generator スキルを使用）
|
||||
```
|
||||
|
||||
**良い例:**
|
||||
|
||||
推奨構成が明確で、エージェント定義情報が詳細に記述されており、次のステップが案内されている。
|
||||
|
||||
**悪い例:**
|
||||
|
||||
```markdown
|
||||
エージェントを作る
|
||||
```
|
||||
|
||||
## アウトプット
|
||||
|
||||
このスキルは以下を生成する:
|
||||
|
||||
- **責任範囲マップ**: 作業と責任範囲の対応関係を整理したマッピング
|
||||
- **推奨エージェント構成**: 責任範囲を実現するために必要なエージェントの推奨案
|
||||
- **エージェント定義情報**: 各エージェントの責任範囲内・外、注意事項などの詳細情報
|
||||
|
||||
## 想定されるエラーと対処法
|
||||
|
||||
### エラー1: 責任範囲が曖昧
|
||||
|
||||
**検出例:**
|
||||
|
||||
```markdown
|
||||
責任範囲: データベース全般
|
||||
```
|
||||
|
||||
**対処法:**
|
||||
|
||||
- 具体的な作業や成果物を明示する
|
||||
- 開始条件と終了条件を明確にする
|
||||
- 責任の境界を明示する
|
||||
|
||||
### エラー2: 責任範囲が大きすぎる
|
||||
|
||||
**検出例:**
|
||||
|
||||
```markdown
|
||||
責任範囲: システム開発全体
|
||||
```
|
||||
|
||||
**対処法:**
|
||||
|
||||
- 責任範囲をフェーズ別、領域別、役割別に分割する
|
||||
- 1エージェントは1つの明確な責任範囲を持つようにする
|
||||
- 複数のエージェントに分割することを検討する
|
||||
|
||||
### エラー3: 責任範囲内・外が不明確
|
||||
|
||||
**検出例:**
|
||||
|
||||
```markdown
|
||||
責任範囲内: いろいろ
|
||||
責任範囲外: その他
|
||||
```
|
||||
|
||||
**対処法:**
|
||||
|
||||
- 具体的な作業や成果物を列挙する
|
||||
- 「〜を行う」という動詞で表現する
|
||||
- 混同しやすい範囲を明示的に除外する
|
||||
|
||||
## ベストプラクティス
|
||||
|
||||
- 責任範囲は具体的で検証可能にする
|
||||
- 責任の境界を明確にする（開始条件、終了条件）
|
||||
- 責任範囲内・外を明示的に定義する
|
||||
- エージェントの粒度は適切にする（1エージェント1責任）
|
||||
- 推奨構成は実装の優先順位を明示する
|
||||
- エージェント定義情報は詳細に記述する
|
||||
|
||||
## チェックリスト
|
||||
|
||||
### 責任収集完了時
|
||||
|
||||
- [ ] 対象となる作業や業務が確認されている
|
||||
- [ ] 作業の目的と範囲が把握されている
|
||||
- [ ] 担当者や役割が特定されている
|
||||
- [ ] 責任の境界が確認されている
|
||||
- [ ] 関連する作業やシステムが把握されている
|
||||
|
||||
### 責任分類完了時
|
||||
|
||||
- [ ] 責任範囲がフェーズ別、領域別、役割別に分類されている
|
||||
- [ ] 責任の粒度が評価されている
|
||||
- [ ] 責任の重複が確認されている
|
||||
- [ ] 責任のギャップが特定されている
|
||||
- [ ] 責任の優先順位が付けられている
|
||||
|
||||
### 範囲定義完了時
|
||||
|
||||
- [ ] 責任範囲内の項目が列挙されている
|
||||
- [ ] 責任範囲外の項目が列挙されている
|
||||
- [ ] 境界が曖昧な項目が明確になっている
|
||||
- [ ] 注意事項が整理されている
|
||||
- [ ] 制約条件が確認されている
|
||||
|
||||
### エージェント分類完了時
|
||||
|
||||
- [ ] エージェント候補が特定されている
|
||||
- [ ] エージェントの役割が定義されている
|
||||
- [ ] エージェントの使用可能なツールが確認されている
|
||||
- [ ] エージェントの表示色が決定されている
|
||||
- [ ] エージェント間の依存関係が整理されている
|
||||
- [ ] エージェントの粒度が適切である
|
||||
|
||||
### 推奨提示完了時
|
||||
|
||||
- [ ] 推奨エージェント構成が明確に提示されている
|
||||
- [ ] 各エージェントの定義情報がまとめられている
|
||||
- [ ] エージェント間の関係が図示されている
|
||||
- [ ] 実装の優先順位が提案されている
|
||||
- [ ] 次のステップが案内されている
|
||||
- [ ] ユーザーの承認を得ている
|
||||
|
||||
### 最終確認
|
||||
|
||||
- [ ] 責任範囲マップが作成されている
|
||||
- [ ] 推奨エージェント構成が提示されている
|
||||
- [ ] エージェント定義情報が作成されている
|
||||
- [ ] すべてのアウトプットが明確で理解しやすい
|
||||
- [ ] ユーザーが次のステップに進める状態になっている
|
||||
341
skills/skill-granularity-convention/SKILL.md
Normal file
341
skills/skill-granularity-convention/SKILL.md
Normal file
@@ -0,0 +1,341 @@
|
||||
---
|
||||
name: skill-granularity-convention
|
||||
description: スキルの適切な粒度を定義（1スキル1目的、分割基準、結合基準）する。スキル設計時、粒度判断時、またはユーザーがスキル粒度、1スキル1目的、分割基準、結合基準、スキル設計原則に言及した際に使用する。
|
||||
---
|
||||
|
||||
# Skill Granularity Convention
|
||||
|
||||
## 概要
|
||||
|
||||
このSkillは、スキルの適切な粒度を定義し、1スキル1目的の原則を明確化する。スキルを分割すべき基準、結合すべき基準、適切な粒度の判断方法について指針を提供し、保守性と再利用性の高いスキル設計を実現することを目的とする。
|
||||
|
||||
## 責任範囲
|
||||
|
||||
このSkillは以下の範囲をカバーする:
|
||||
|
||||
- 1スキル1目的の原則の定義
|
||||
- スキル分割の基準と判断方法
|
||||
- スキル結合の基準と判断方法
|
||||
- 適切な粒度の判断指標
|
||||
- 粒度判断のベストプラクティス
|
||||
|
||||
## 基本方針
|
||||
|
||||
- 1スキル1目的を厳守する
|
||||
- 責任範囲を明確に定義する
|
||||
- 複数の目的が含まれる場合は分割を検討する
|
||||
- 過度に細分化しない（実用性を保つ）
|
||||
- コンテキストサイズを最小化する
|
||||
- 再利用性と保守性を重視する
|
||||
|
||||
## 1スキル1目的の原則
|
||||
|
||||
### 原則の定義
|
||||
|
||||
各スキルは、一つの明確な目的を持つべきである。
|
||||
|
||||
**目的の定義:**
|
||||
|
||||
- スキルが達成すべき具体的な成果物または作業内容
|
||||
- 責任範囲セクションで明確に表現できる範囲
|
||||
- ユーザーが「このスキルは〜をする」と一文で説明できる範囲
|
||||
|
||||
### 原則の適用
|
||||
|
||||
スキルの目的が明確であることを確認する:
|
||||
|
||||
- スキルのdescriptionが1行で簡潔に説明できる
|
||||
- 責任範囲が3〜5項目で列挙できる
|
||||
- ワークフローが2〜5フェーズで構成できる（Workflow Skillの場合）
|
||||
- カテゴリが2〜5個で構成できる（Convention Skillの場合）
|
||||
|
||||
良い例:
|
||||
|
||||
```markdown
|
||||
---
|
||||
name: api-designer
|
||||
description: RESTful API仕様を設計する
|
||||
---
|
||||
|
||||
## 責任範囲
|
||||
|
||||
- エンドポイントの定義
|
||||
- リクエスト/レスポンス形式の設計
|
||||
- 認証・認可方式の設計
|
||||
```
|
||||
|
||||
（目的が「API仕様を設計する」と明確）
|
||||
|
||||
悪い例:
|
||||
|
||||
```markdown
|
||||
---
|
||||
name: system-designer
|
||||
description: システム全体を設計する
|
||||
---
|
||||
|
||||
## 責任範囲
|
||||
|
||||
- アーキテクチャ設計
|
||||
- データベース設計
|
||||
- API設計
|
||||
- UI/UX設計
|
||||
- セキュリティ設計
|
||||
- パフォーマンス設計
|
||||
```
|
||||
|
||||
（目的が広すぎて、複数のスキルに分割すべき）
|
||||
|
||||
## スキル分割の基準
|
||||
|
||||
### 分割すべきケース
|
||||
|
||||
以下の場合は、スキルを分割することを検討する:
|
||||
|
||||
1. **複数の異なる目的が含まれる場合**
|
||||
- 一つのスキルで複数の成果物を生成する
|
||||
- 責任範囲が6項目以上ある
|
||||
- descriptionが2文以上必要になる
|
||||
|
||||
2. **ワークフローが複雑すぎる場合**
|
||||
- ワークフローのフェーズが6個以上ある
|
||||
- 各フェーズの実施内容が5項目以上ある
|
||||
- フェーズ間の依存関係が複雑である
|
||||
|
||||
3. **カテゴリが多すぎる場合**
|
||||
- カテゴリが6個以上ある（Convention Skillの場合）
|
||||
- 各カテゴリのルールが5項目以上ある
|
||||
- カテゴリ間の関連性が薄い
|
||||
|
||||
4. **規約部分が肥大化する場合**
|
||||
- Workflow Skillに含まれる規約が大量にある
|
||||
- 規約の説明が長く、ワークフローの理解を妨げる
|
||||
- 規約を他のスキルでも再利用したい
|
||||
|
||||
### 分割方法
|
||||
|
||||
#### パターン1: 目的別に分割
|
||||
|
||||
システム設計スキルを目的別に分割:
|
||||
|
||||
- アーキテクチャ設計スキル
|
||||
- データベース設計スキル
|
||||
- API設計スキル
|
||||
- UI/UX設計スキル
|
||||
|
||||
#### パターン2: フェーズ別に分割
|
||||
|
||||
要件定義スキルをフェーズ別に分割:
|
||||
|
||||
- 要件収集スキル
|
||||
- 要件整理スキル
|
||||
- 要件検証スキル
|
||||
|
||||
#### パターン3: 規約を分離
|
||||
|
||||
コード生成スキルから規約を分離:
|
||||
|
||||
- コード生成スキル（Workflow Skill）
|
||||
- コーディング規約スキル（Convention Skill）
|
||||
|
||||
良い例:
|
||||
|
||||
```text
|
||||
分割前:
|
||||
- system-designer（システム全体を設計する）
|
||||
|
||||
分割後:
|
||||
- architecture-designer（システムアーキテクチャを設計する）
|
||||
- database-schema-designer（データベーススキーマを設計する）
|
||||
- api-designer（RESTful API仕様を設計する）
|
||||
- ui-component-architect（UIコンポーネント構成を設計する）
|
||||
```
|
||||
|
||||
悪い例:
|
||||
|
||||
```text
|
||||
分割前:
|
||||
- api-designer（RESTful API仕様を設計する）
|
||||
|
||||
分割後:
|
||||
- endpoint-designer（エンドポイントを設計する）
|
||||
- request-designer（リクエスト形式を設計する）
|
||||
- response-designer（レスポンス形式を設計する）
|
||||
- auth-designer（認証方式を設計する）
|
||||
```
|
||||
|
||||
（過度に細分化されており、実用性が低い）
|
||||
|
||||
## スキル結合の基準
|
||||
|
||||
### 結合すべきケース
|
||||
|
||||
以下の場合は、スキルを結合することを検討する:
|
||||
|
||||
1. **スキルが小さすぎる場合**
|
||||
- 責任範囲が1〜2項目しかない
|
||||
- ワークフローが1フェーズしかない
|
||||
- 単独では実用的でない
|
||||
|
||||
2. **スキル間の依存関係が強い場合**
|
||||
- 常に一緒に実行される
|
||||
- 一方のスキルの出力が他方の入力になる
|
||||
- 分離することで理解が困難になる
|
||||
|
||||
3. **重複が多い場合**
|
||||
- 複数のスキルで同じ規約やガイドラインを記述している
|
||||
- 同じ前提条件や制約事項を持っている
|
||||
- 統合することで重複を削減できる
|
||||
|
||||
### 結合方法
|
||||
|
||||
#### パターン1: 関連する作業を統合
|
||||
|
||||
エンドポイント設計、リクエスト設計、レスポンス設計を統合:
|
||||
|
||||
- API設計スキル（すべてを含む）
|
||||
|
||||
#### パターン2: 規約を直接記述
|
||||
|
||||
コード生成スキルに規約を直接記述:
|
||||
|
||||
- コード生成スキル（規約を含む）
|
||||
|
||||
良い例:
|
||||
|
||||
```text
|
||||
結合前:
|
||||
- endpoint-designer（エンドポイントを設計する）
|
||||
- request-designer（リクエスト形式を設計する）
|
||||
- response-designer（レスポンス形式を設計する）
|
||||
|
||||
結合後:
|
||||
- api-designer（RESTful API仕様を設計する）
|
||||
```
|
||||
|
||||
悪い例:
|
||||
|
||||
```text
|
||||
結合前:
|
||||
- architecture-designer（システムアーキテクチャを設計する）
|
||||
- database-schema-designer（データベーススキーマを設計する）
|
||||
- api-designer（RESTful API仕様を設計する）
|
||||
|
||||
結合後:
|
||||
- system-designer（システム全体を設計する）
|
||||
```
|
||||
|
||||
（目的が広すぎて、1スキル1目的の原則に反する）
|
||||
|
||||
## 適切な粒度の判断方法
|
||||
|
||||
### 判断指標
|
||||
|
||||
以下の指標を使用して、スキルの粒度が適切かどうかを判断する:
|
||||
|
||||
1. **descriptionの明確さ**
|
||||
- 1行50文字以内で説明できる → 適切
|
||||
- 2文以上必要 → 分割を検討
|
||||
|
||||
2. **責任範囲の項目数**
|
||||
- 3〜5項目 → 適切
|
||||
- 1〜2項目 → 結合を検討
|
||||
- 6項目以上 → 分割を検討
|
||||
|
||||
3. **ワークフローのフェーズ数（Workflow Skill）**
|
||||
- 2〜5フェーズ → 適切
|
||||
- 1フェーズ → 結合を検討
|
||||
- 6フェーズ以上 → 分割を検討
|
||||
|
||||
4. **カテゴリ数（Convention Skill）**
|
||||
- 2〜5カテゴリ → 適切
|
||||
- 1カテゴリ → 結合を検討
|
||||
- 6カテゴリ以上 → 分割を検討
|
||||
|
||||
5. **ドキュメントサイズ**
|
||||
- 200〜400行 → 適切
|
||||
- 200行未満 → 結合を検討
|
||||
- 400行以上 → 分割を検討
|
||||
|
||||
### 判断フロー
|
||||
|
||||
```text
|
||||
1. descriptionが1行で説明できるか？
|
||||
├─ はい → 2へ
|
||||
└─ いいえ → 分割を検討
|
||||
|
||||
2. 責任範囲が3〜5項目か？
|
||||
├─ はい → 3へ
|
||||
├─ いいえ（1〜2項目） → 結合を検討
|
||||
└─ いいえ（6項目以上） → 分割を検討
|
||||
|
||||
3. ワークフロー/カテゴリが2〜5個か？
|
||||
├─ はい → 適切な粒度
|
||||
├─ いいえ（1個） → 結合を検討
|
||||
└─ いいえ（6個以上） → 分割を検討
|
||||
```
|
||||
|
||||
## ベストプラクティス
|
||||
|
||||
### 実用性を重視する
|
||||
|
||||
- 理論的に分割可能でも、実用性がなければ分割しない
|
||||
- ユーザーが使いやすい粒度を優先する
|
||||
- コマンドで組み合わせることを前提に設計する
|
||||
|
||||
### コンテキストサイズを最小化する
|
||||
|
||||
- 不要な情報を含めない
|
||||
- 規約やガイドラインは必要最小限にする
|
||||
- 他のスキルと重複する内容を避ける
|
||||
|
||||
### 再利用性を考慮する
|
||||
|
||||
- 複数のコマンドから使用されるスキルは独立させる
|
||||
- 特定のコマンド専用のスキルは統合を検討する
|
||||
|
||||
### 保守性を確保する
|
||||
|
||||
- 変更頻度が異なる内容は分離する
|
||||
- 安定した部分と変更される部分を分ける
|
||||
|
||||
## チェックリスト
|
||||
|
||||
### スキル作成時
|
||||
|
||||
- [ ] descriptionが1行50文字以内で説明できる
|
||||
- [ ] 責任範囲が3〜5項目である
|
||||
- [ ] ワークフロー/カテゴリが2〜5個である
|
||||
- [ ] 1スキル1目的の原則を守っている
|
||||
- [ ] 複数の異なる目的が含まれていない
|
||||
|
||||
### スキル分割検討時
|
||||
|
||||
- [ ] 複数の異なる目的が含まれているか確認した
|
||||
- [ ] ワークフローが複雑すぎないか確認した
|
||||
- [ ] カテゴリが多すぎないか確認した
|
||||
- [ ] 規約部分が肥大化していないか確認した
|
||||
- [ ] 分割後の各スキルが実用的であるか確認した
|
||||
|
||||
### スキル結合検討時
|
||||
|
||||
- [ ] スキルが小さすぎないか確認した
|
||||
- [ ] スキル間の依存関係が強いか確認した
|
||||
- [ ] 重複が多いか確認した
|
||||
- [ ] 結合後も1スキル1目的の原則を守れるか確認した
|
||||
|
||||
### 粒度判断時
|
||||
|
||||
- [ ] descriptionの明確さを確認した
|
||||
- [ ] 責任範囲の項目数を確認した
|
||||
- [ ] ワークフロー/カテゴリ数を確認した
|
||||
- [ ] ドキュメントサイズを確認した
|
||||
- [ ] 実用性を考慮した
|
||||
|
||||
### 最終確認
|
||||
|
||||
- [ ] 適切な粒度になっている
|
||||
- [ ] 1スキル1目的の原則が守られている
|
||||
- [ ] 実用性がある
|
||||
- [ ] コンテキストサイズが最小化されている
|
||||
- [ ] 再利用性と保守性が確保されている
|
||||
549
skills/task-decomposer/SKILL.md
Normal file
549
skills/task-decomposer/SKILL.md
Normal file
@@ -0,0 +1,549 @@
|
||||
---
|
||||
name: task-decomposer
|
||||
description: 複雑な作業を単一目的の小さなタスクに分解する。タスク分解時、作業細分化時、スキル設計時、またはユーザーがタスク分解、作業分割、細分化、単一目的、タスク粒度に言及した際に使用する。
|
||||
---
|
||||
|
||||
# Task Decomposer
|
||||
|
||||
## 概要
|
||||
|
||||
このSkillは、ユーザーが提供する複雑な作業や大きなタスクを、単一目的の小さなタスクに分解する。ユーザーとの対話を通じてタスクの詳細を理解し、適切な粒度のタスクに分解して、スキルやコマンドの設計を支援する。
|
||||
|
||||
## 責任範囲
|
||||
|
||||
このSkillは以下の範囲をカバーする:
|
||||
|
||||
- 複雑なタスクや大きな作業の収集
|
||||
- タスクの複雑度と依存関係の評価
|
||||
- タスクの分解と小タスクへの変換
|
||||
- タスク粒度の調整と最適化
|
||||
- 分解されたタスクリストの提供
|
||||
- タスク実行順序の提案
|
||||
|
||||
## ワークフロー
|
||||
|
||||
### フェーズ1: タスク収集
|
||||
|
||||
ユーザーとの対話を通じて、分解対象となる複雑なタスクや大きな作業を収集する。
|
||||
|
||||
**実施内容:**
|
||||
|
||||
1. 分解対象のタスクを確認する
|
||||
2. タスクの目的と期待される成果を把握する
|
||||
3. タスクの制約条件を確認する
|
||||
4. タスクに必要なリソースを特定する
|
||||
5. タスクの完了基準を明確にする
|
||||
|
||||
**質問例:**
|
||||
|
||||
```markdown
|
||||
【タスクの確認】
|
||||
分解したい複雑なタスクを教えてください。
|
||||
|
||||
1. タスク名: [タスクの名称]
|
||||
2. 目的: [このタスクで達成したいこと]
|
||||
3. 期待される成果: [タスク完了後の成果物や状態]
|
||||
4. 制約条件: [時間、リソース、技術的制約など]
|
||||
5. 完了基準: [どうなったら完了とするか]
|
||||
```
|
||||
|
||||
**良い例:**
|
||||
|
||||
```markdown
|
||||
タスク名: コードレビュープロセスの自動化
|
||||
目的: コードレビューの効率化と品質向上
|
||||
期待される成果:
|
||||
- 静的解析結果の自動確認
|
||||
- コーディング規約違反の自動検出
|
||||
- レビューコメントの自動生成
|
||||
- レビューレポートの自動作成
|
||||
|
||||
制約条件:
|
||||
- 既存のCI/CDパイプラインと統合する
|
||||
- GitHub APIを使用する
|
||||
- レビュー時間を50%削減する
|
||||
|
||||
完了基準:
|
||||
- 全ての成果物が実装されている
|
||||
- CI/CDパイプラインと統合されている
|
||||
- レビュー時間が50%削減されている
|
||||
```
|
||||
|
||||
**悪い例:**
|
||||
|
||||
```markdown
|
||||
タスク名: レビュー
|
||||
目的: 良くする
|
||||
期待される成果: 何か
|
||||
制約条件: 特になし
|
||||
完了基準: 終わったら
|
||||
```
|
||||
|
||||
### フェーズ2: 複雑度評価
|
||||
|
||||
収集したタスクの複雑度を評価し、分解の必要性と方針を決定する。
|
||||
|
||||
**実施内容:**
|
||||
|
||||
1. タスクの規模を評価する（工数、影響範囲）
|
||||
2. タスクの複雑度を評価する（技術的難易度、依存関係）
|
||||
3. タスクの依存関係を特定する
|
||||
4. 分解の必要性を判断する
|
||||
5. 分解の方針を決定する
|
||||
|
||||
**評価基準:**
|
||||
|
||||
- **規模**: 小/中/大
|
||||
- 小: 1〜2時間で完了
|
||||
- 中: 半日〜1日で完了
|
||||
- 大: 2日以上必要
|
||||
- **複雑度**: 低/中/高
|
||||
- 低: 明確な手順があり、判断が不要
|
||||
- 中: 一部判断が必要だが、手順は明確
|
||||
- 高: 複雑な判断や技術的課題がある
|
||||
- **依存関係**: 独立/一部依存/強依存
|
||||
- 独立: 他のタスクに依存しない
|
||||
- 一部依存: 一部のタスクに依存する
|
||||
- 強依存: 多くのタスクに依存する
|
||||
|
||||
**良い例:**
|
||||
|
||||
```markdown
|
||||
【複雑度評価結果】
|
||||
|
||||
タスク: コードレビュープロセスの自動化
|
||||
|
||||
規模: 大
|
||||
- 工数: 5〜7日程度
|
||||
- 影響範囲: CI/CDパイプライン、レビュープロセス全体
|
||||
|
||||
複雑度: 高
|
||||
- 技術的課題: GitHub API連携、静的解析ツール統合、自然言語処理
|
||||
- 判断の必要性: レビューコメントの適切性、優先度判断
|
||||
|
||||
依存関係: 一部依存
|
||||
- CI/CDパイプラインの整備（前提条件）
|
||||
- GitHub リポジトリへのアクセス権限（前提条件）
|
||||
- 静的解析ツールの導入（並行作業可能）
|
||||
|
||||
分解の必要性: 必要
|
||||
- 理由: 規模が大きく、複雑度が高いため、小さなタスクに分解すべき
|
||||
|
||||
分解の方針:
|
||||
- 機能別に分解する（静的解析確認、規約違反検出、コメント生成など）
|
||||
- 各機能を独立したタスクとして実装する
|
||||
- 依存関係を明確にして実装順序を決定する
|
||||
```
|
||||
|
||||
**悪い例:**
|
||||
|
||||
```markdown
|
||||
【複雑度評価結果】
|
||||
|
||||
規模: 大きい
|
||||
複雑度: 難しい
|
||||
依存関係: ある
|
||||
分解の必要性: たぶん必要
|
||||
```
|
||||
|
||||
### フェーズ3: タスク分解
|
||||
|
||||
複雑なタスクを、単一目的の小さなタスクに分解する。
|
||||
|
||||
**実施内容:**
|
||||
|
||||
1. タスクを機能別に分解する
|
||||
2. 各小タスクの目的を明確にする
|
||||
3. 各小タスクの入力と出力を定義する
|
||||
4. 小タスク間の依存関係を整理する
|
||||
5. 小タスクの実行順序を決定する
|
||||
|
||||
**分解基準:**
|
||||
|
||||
- 1タスクは1つの明確な目的を持つ
|
||||
- タスクの完了基準が明確である
|
||||
- タスクの入力と出力が明確である
|
||||
- タスクは半日〜1日で完了できる粒度である
|
||||
|
||||
**良い例:**
|
||||
|
||||
```markdown
|
||||
【タスク分解結果】
|
||||
|
||||
元のタスク: コードレビュープロセスの自動化
|
||||
|
||||
分解されたタスク:
|
||||
|
||||
タスク1: プルリクエスト情報取得
|
||||
- 目的: GitHub APIからプルリクエスト情報を取得する
|
||||
- 入力: プルリクエストURL
|
||||
- 出力: PR情報（タイトル、説明、変更ファイル、コミットリスト）
|
||||
- 依存関係: なし
|
||||
- 工数: 半日
|
||||
|
||||
タスク2: 静的解析結果確認
|
||||
- 目的: CI/CDパイプラインの静的解析結果を確認する
|
||||
- 入力: CI/CDパイプライン結果
|
||||
- 出力: 静的解析問題リスト（linter、型チェック、セキュリティスキャン）
|
||||
- 依存関係: なし
|
||||
- 工数: 半日
|
||||
|
||||
タスク3: コーディング規約違反検出
|
||||
- 目的: コード変更がコーディング規約に違反していないか確認する
|
||||
- 入力: 変更されたコード、コーディング規約定義
|
||||
- 出力: 規約違反リスト（違反箇所、違反内容、重要度）
|
||||
- 依存関係: タスク1（変更ファイル情報が必要）
|
||||
- 工数: 1日
|
||||
|
||||
タスク4: テストカバレッジ確認
|
||||
- 目的: テストカバレッジを確認し、不足箇所を特定する
|
||||
- 入力: テスト実行結果、カバレッジレポート
|
||||
- 出力: カバレッジ分析結果（カバレッジ率、未カバー箇所）
|
||||
- 依存関係: なし
|
||||
- 工数: 半日
|
||||
|
||||
タスク5: レビューコメント生成
|
||||
- 目的: 検出された問題からレビューコメントを生成する
|
||||
- 入力: 静的解析問題リスト、規約違反リスト、カバレッジ分析結果
|
||||
- 出力: レビューコメント（問題箇所、修正提案、優先度）
|
||||
- 依存関係: タスク2、タスク3、タスク4
|
||||
- 工数: 1日
|
||||
|
||||
タスク6: レビューレポート作成
|
||||
- 目的: レビュー結果をまとめたレポートを作成する
|
||||
- 入力: レビューコメント、PR情報
|
||||
- 出力: レビューレポート（Markdown形式）
|
||||
- 依存関係: タスク1、タスク5
|
||||
- 工数: 半日
|
||||
|
||||
タスク7: CI/CDパイプライン統合
|
||||
- 目的: 自動化されたレビュープロセスをCI/CDパイプラインに統合する
|
||||
- 入力: 全タスクの成果物
|
||||
- 出力: CI/CD設定ファイル、統合ドキュメント
|
||||
- 依存関係: タスク1〜6（全タスク完了後）
|
||||
- 工数: 1日
|
||||
|
||||
合計工数: 5.5日
|
||||
```
|
||||
|
||||
**悪い例:**
|
||||
|
||||
```markdown
|
||||
【タスク分解結果】
|
||||
|
||||
タスク1: 準備する
|
||||
タスク2: 実装する
|
||||
タスク3: 終わらせる
|
||||
```
|
||||
|
||||
### フェーズ4: 粒度調整
|
||||
|
||||
分解されたタスクの粒度を確認し、必要に応じて調整する。
|
||||
|
||||
**実施内容:**
|
||||
|
||||
1. 各タスクの粒度を確認する
|
||||
2. 大きすぎるタスクをさらに分解する
|
||||
3. 小さすぎるタスクを統合する
|
||||
4. タスクの完了基準を明確にする
|
||||
5. タスクの優先順位を付ける
|
||||
|
||||
**調整基準:**
|
||||
|
||||
- **適切な粒度**: 半日〜1日で完了できる
|
||||
- **大きすぎる**: 2日以上かかる場合は分解を検討
|
||||
- **小さすぎる**: 1〜2時間で完了する場合は統合を検討
|
||||
- **単一責任**: 1タスクは1つの明確な目的を持つ
|
||||
|
||||
**良い例:**
|
||||
|
||||
```markdown
|
||||
【粒度調整結果】
|
||||
|
||||
調整対象: タスク3（コーディング規約違反検出）
|
||||
|
||||
調整前:
|
||||
- 工数: 1日
|
||||
- 粒度評価: 適切
|
||||
|
||||
調整内容: なし（粒度は適切）
|
||||
|
||||
調整対象: タスク5（レビューコメント生成）
|
||||
|
||||
調整前:
|
||||
- 工数: 1日
|
||||
- 粒度評価: やや大きい
|
||||
|
||||
調整後:
|
||||
タスク5-1: 問題の優先度付け
|
||||
- 目的: 検出された問題に優先度を付ける
|
||||
- 入力: 静的解析問題リスト、規約違反リスト、カバレッジ分析結果
|
||||
- 出力: 優先度付き問題リスト
|
||||
- 工数: 半日
|
||||
|
||||
タスク5-2: レビューコメント生成
|
||||
- 目的: 優先度付き問題からレビューコメントを生成する
|
||||
- 入力: 優先度付き問題リスト
|
||||
- 出力: レビューコメント
|
||||
- 工数: 半日
|
||||
|
||||
調整理由: 優先度付けとコメント生成を分離することで、責任が明確になり、実装しやすくなる
|
||||
|
||||
【最終タスクリスト】
|
||||
|
||||
1. プルリクエスト情報取得（半日）
|
||||
2. 静的解析結果確認（半日）
|
||||
3. コーディング規約違反検出（1日）
|
||||
4. テストカバレッジ確認（半日）
|
||||
5-1. 問題の優先度付け（半日）
|
||||
5-2. レビューコメント生成（半日）
|
||||
6. レビューレポート作成（半日）
|
||||
7. CI/CDパイプライン統合（1日）
|
||||
|
||||
合計工数: 5.5日
|
||||
|
||||
【優先順位】
|
||||
|
||||
優先度1（必須）:
|
||||
- タスク1: プルリクエスト情報取得
|
||||
- タスク2: 静的解析結果確認
|
||||
- タスク3: コーディング規約違反検出
|
||||
|
||||
優先度2（推奨）:
|
||||
- タスク4: テストカバレッジ確認
|
||||
- タスク5-1: 問題の優先度付け
|
||||
- タスク5-2: レビューコメント生成
|
||||
|
||||
優先度3（オプション）:
|
||||
- タスク6: レビューレポート作成
|
||||
- タスク7: CI/CDパイプライン統合
|
||||
```
|
||||
|
||||
**悪い例:**
|
||||
|
||||
```markdown
|
||||
【粒度調整結果】
|
||||
|
||||
調整なし
|
||||
```
|
||||
|
||||
### フェーズ5: 推奨提示
|
||||
|
||||
分解されたタスクリストをユーザーに提示し、実装の指針を提供する。
|
||||
|
||||
**実施内容:**
|
||||
|
||||
1. 最終タスクリストを提示する
|
||||
2. タスクの実行順序を明示する
|
||||
3. タスク間の依存関係を図示する
|
||||
4. 実装の優先順位を提案する
|
||||
5. 次のステップを案内する
|
||||
|
||||
**提示形式:**
|
||||
|
||||
```markdown
|
||||
【分解されたタスクリスト】
|
||||
|
||||
合計タスク数: 8個
|
||||
合計工数: 5.5日
|
||||
|
||||
タスク一覧:
|
||||
|
||||
1. プルリクエスト情報取得（半日）
|
||||
- GitHub APIからプルリクエスト情報を取得する
|
||||
- 依存: なし
|
||||
|
||||
2. 静的解析結果確認（半日）
|
||||
- CI/CDパイプラインの静的解析結果を確認する
|
||||
- 依存: なし
|
||||
|
||||
3. コーディング規約違反検出（1日）
|
||||
- コード変更がコーディング規約に違反していないか確認する
|
||||
- 依存: タスク1
|
||||
|
||||
4. テストカバレッジ確認（半日）
|
||||
- テストカバレッジを確認し、不足箇所を特定する
|
||||
- 依存: なし
|
||||
|
||||
5-1. 問題の優先度付け（半日）
|
||||
- 検出された問題に優先度を付ける
|
||||
- 依存: タスク2、タスク3、タスク4
|
||||
|
||||
5-2. レビューコメント生成（半日）
|
||||
- 優先度付き問題からレビューコメントを生成する
|
||||
- 依存: タスク5-1
|
||||
|
||||
6. レビューレポート作成（半日）
|
||||
- レビュー結果をまとめたレポートを作成する
|
||||
- 依存: タスク1、タスク5-2
|
||||
|
||||
7. CI/CDパイプライン統合（1日）
|
||||
- 自動化されたレビュープロセスをCI/CDパイプラインに統合する
|
||||
- 依存: タスク1〜6
|
||||
|
||||
【実行順序】
|
||||
|
||||
フェーズ1（並列実行可能）:
|
||||
- タスク1: プルリクエスト情報取得
|
||||
- タスク2: 静的解析結果確認
|
||||
- タスク4: テストカバレッジ確認
|
||||
|
||||
フェーズ2:
|
||||
- タスク3: コーディング規約違反検出（タスク1完了後）
|
||||
|
||||
フェーズ3:
|
||||
- タスク5-1: 問題の優先度付け（タスク2、3、4完了後）
|
||||
|
||||
フェーズ4:
|
||||
- タスク5-2: レビューコメント生成（タスク5-1完了後）
|
||||
|
||||
フェーズ5:
|
||||
- タスク6: レビューレポート作成（タスク1、5-2完了後）
|
||||
|
||||
フェーズ6:
|
||||
- タスク7: CI/CDパイプライン統合（全タスク完了後）
|
||||
|
||||
【スキル・コマンドへのマッピング】
|
||||
|
||||
各タスクはワークフロースキルとして実装することを推奨:
|
||||
|
||||
- pull-request-analyzer（タスク1）
|
||||
- static-analysis-checker（タスク2）
|
||||
- code-quality-reviewer（タスク3）
|
||||
- test-coverage-analyzer（タスク4）
|
||||
- issue-prioritizer（タスク5-1）
|
||||
- review-comment-generator（タスク5-2）
|
||||
- review-report-writer（タスク6）
|
||||
- cicd-integrator（タスク7）
|
||||
|
||||
【次のステップ】
|
||||
|
||||
1. 各タスクをワークフロースキルとして設計（workflow-analyzer スキルを使用）
|
||||
2. 必要なコンベンションスキルを特定（coding-conventionsなど）
|
||||
3. エージェントを設計（responsibility-mapper スキルを使用）
|
||||
4. コマンドを設計（command-generator スキルを使用）
|
||||
```
|
||||
|
||||
**良い例:**
|
||||
|
||||
タスクリストが明確で、実行順序、依存関係、スキルへのマッピングが示されており、次のステップが案内されている。
|
||||
|
||||
**悪い例:**
|
||||
|
||||
```markdown
|
||||
タスクをいくつか作った
|
||||
```
|
||||
|
||||
## アウトプット
|
||||
|
||||
このスキルは以下を生成する:
|
||||
|
||||
- **分解されたタスクリスト**: 単一目的の小さなタスクのリスト（目的、入力、出力、工数を含む）
|
||||
- **タスク実行順序**: タスクの依存関係と実行順序を明示したドキュメント
|
||||
- **スキル・コマンドへのマッピング**: 各タスクをスキルやコマンドにマッピングした推奨案
|
||||
|
||||
## 想定されるエラーと対処法
|
||||
|
||||
### エラー1: タスクが大きすぎる
|
||||
|
||||
**検出例:**
|
||||
|
||||
```markdown
|
||||
タスク: システム全体を実装する（10日）
|
||||
```
|
||||
|
||||
**対処法:**
|
||||
|
||||
- タスクを機能別に分解する
|
||||
- 1タスクは半日〜1日で完了できる粒度にする
|
||||
- タスクの完了基準を明確にする
|
||||
|
||||
### エラー2: タスクが小さすぎる
|
||||
|
||||
**検出例:**
|
||||
|
||||
```markdown
|
||||
タスク: 変数名を変更する（10分）
|
||||
```
|
||||
|
||||
**対処法:**
|
||||
|
||||
- 小さなタスクを統合する
|
||||
- 関連するタスクをまとめて1つのタスクにする
|
||||
- タスクの粒度を調整する
|
||||
|
||||
### エラー3: タスクの依存関係が不明確
|
||||
|
||||
**検出例:**
|
||||
|
||||
```markdown
|
||||
タスク間の依存関係: よくわからない
|
||||
```
|
||||
|
||||
**対処法:**
|
||||
|
||||
- 各タスクの入力と出力を明確にする
|
||||
- どのタスクの出力がどのタスクの入力になるかを整理する
|
||||
- 依存関係を図示する
|
||||
|
||||
## ベストプラクティス
|
||||
|
||||
- タスクは単一目的にする（1タスク1目的）
|
||||
- タスクの粒度は半日〜1日で完了できるようにする
|
||||
- タスクの完了基準を明確にする
|
||||
- タスクの入力と出力を明示する
|
||||
- タスク間の依存関係を明確にする
|
||||
- 実行順序を明示する（並列実行可能なタスクを特定）
|
||||
- スキルやコマンドへのマッピングを提供する
|
||||
|
||||
## チェックリスト
|
||||
|
||||
### タスク収集完了時
|
||||
|
||||
- [ ] 分解対象のタスクが確認されている
|
||||
- [ ] タスクの目的と期待される成果が把握されている
|
||||
- [ ] タスクの制約条件が確認されている
|
||||
- [ ] タスクに必要なリソースが特定されている
|
||||
- [ ] タスクの完了基準が明確になっている
|
||||
|
||||
### 複雑度評価完了時
|
||||
|
||||
- [ ] タスクの規模が評価されている
|
||||
- [ ] タスクの複雑度が評価されている
|
||||
- [ ] タスクの依存関係が特定されている
|
||||
- [ ] 分解の必要性が判断されている
|
||||
- [ ] 分解の方針が決定されている
|
||||
|
||||
### タスク分解完了時
|
||||
|
||||
- [ ] タスクが機能別に分解されている
|
||||
- [ ] 各小タスクの目的が明確になっている
|
||||
- [ ] 各小タスクの入力と出力が定義されている
|
||||
- [ ] 小タスク間の依存関係が整理されている
|
||||
- [ ] 小タスクの実行順序が決定されている
|
||||
|
||||
### 粒度調整完了時
|
||||
|
||||
- [ ] 各タスクの粒度が確認されている
|
||||
- [ ] 大きすぎるタスクが分解されている
|
||||
- [ ] 小さすぎるタスクが統合されている
|
||||
- [ ] タスクの完了基準が明確になっている
|
||||
- [ ] タスクの優先順位が付けられている
|
||||
|
||||
### 推奨提示完了時
|
||||
|
||||
- [ ] 最終タスクリストが提示されている
|
||||
- [ ] タスクの実行順序が明示されている
|
||||
- [ ] タスク間の依存関係が図示されている
|
||||
- [ ] 実装の優先順位が提案されている
|
||||
- [ ] スキル・コマンドへのマッピングが提供されている
|
||||
- [ ] 次のステップが案内されている
|
||||
- [ ] ユーザーの承認を得ている
|
||||
|
||||
### 最終確認
|
||||
|
||||
- [ ] 分解されたタスクリストが作成されている
|
||||
- [ ] タスク実行順序が作成されている
|
||||
- [ ] スキル・コマンドへのマッピングが作成されている
|
||||
- [ ] すべてのアウトプットが明確で理解しやすい
|
||||
- [ ] ユーザーが次のステップに進める状態になっている
|
||||
491
skills/workflow-analyzer/SKILL.md
Normal file
491
skills/workflow-analyzer/SKILL.md
Normal file
@@ -0,0 +1,491 @@
|
||||
---
|
||||
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つの明確な責任を持つようにする
|
||||
- スキルが大きすぎる場合は分割する
|
||||
- スキルが小さすぎる場合は統合する
|
||||
- スキル粒度規約に従う
|
||||
|
||||
## ベストプラクティス
|
||||
|
||||
- 作業フローは実際の作業者にヒアリングして収集する
|
||||
- ステップ分解は細かすぎず、粗すぎず適切な粒度にする
|
||||
- 自動化分析は客観的な基準で評価する
|
||||
- スキル分類は明確な基準に基づいて行う
|
||||
- 推奨構成は実装の優先順位を明示する
|
||||
- 自動化効果を定量的に示す（時間削減率など）
|
||||
|
||||
## チェックリスト
|
||||
|
||||
### フロー収集完了時
|
||||
|
||||
- [ ] 作業フローの概要が明確になっている
|
||||
- [ ] 作業の開始条件（トリガー）が特定されている
|
||||
- [ ] 作業の終了条件（完了基準）が確認されている
|
||||
- [ ] 作業に関わる人やシステムが把握されている
|
||||
- [ ] 既存の手順書やドキュメントが確認されている
|
||||
|
||||
### ステップ分解完了時
|
||||
|
||||
- [ ] 作業が順序通りのステップに分解されている
|
||||
- [ ] 各ステップの入力と出力が定義されている
|
||||
- [ ] ステップ間のデータ受け渡しが確認されている
|
||||
- [ ] 条件分岐や繰り返しが特定されている
|
||||
- [ ] 各ステップの判断基準やルールが明確になっている
|
||||
- [ ] 各ステップで使用するテンプレートファイルやフォーマットが特定されている
|
||||
- [ ] ステップの粒度が適切である
|
||||
|
||||
### 自動化分析完了時
|
||||
|
||||
- [ ] 各ステップの自動化可能性が評価されている
|
||||
- [ ] 自動化の難易度が判定されている
|
||||
- [ ] 自動化による効果が見積もられている
|
||||
- [ ] 手作業が必要な部分が特定されている
|
||||
- [ ] 自動化の優先順位が付けられている
|
||||
- [ ] 評価基準が明確である
|
||||
|
||||
### スキル分類完了時
|
||||
|
||||
- [ ] ワークフロースキル候補が特定されている
|
||||
- [ ] コンベンションスキル候補が特定されている
|
||||
- [ ] 各スキルの責任範囲が定義されている
|
||||
- [ ] スキル間の依存関係が整理されている
|
||||
- [ ] 必要なテンプレートファイルと対応するスキルの関係が特定されている
|
||||
- [ ] スキルの粒度が適切である
|
||||
|
||||
### 推奨提示完了時
|
||||
|
||||
- [ ] 推奨スキル構成が明確に提示されている
|
||||
- [ ] スキルの実行順序が明示されている
|
||||
- [ ] 実装の優先順位が提案されている
|
||||
- [ ] 自動化効果が定量的に示されている
|
||||
- [ ] 次のステップが案内されている
|
||||
- [ ] ユーザーの承認を得ている
|
||||
|
||||
### 最終確認
|
||||
|
||||
- [ ] 自動化可能な要素リストが作成されている
|
||||
- [ ] 推奨スキル構成が提示されている
|
||||
- [ ] 作業フロー分析レポートが作成されている
|
||||
- [ ] すべてのアウトプットが明確で理解しやすい
|
||||
- [ ] ユーザーが次のステップに進める状態になっている
|
||||
265
skills/workflow-skill-generator/SKILL.md
Normal file
265
skills/workflow-skill-generator/SKILL.md
Normal file
@@ -0,0 +1,265 @@
|
||||
---
|
||||
name: workflow-skill-generator
|
||||
description: ユーザーの作業フローから、Workflow Skillのマークダウンファイルを生成する。ワークフロースキル作成時、業務プロセス文書化時、またはユーザーがWorkflow Skill、作業フロー、業務プロセス、手順書に言及した際に使用する。
|
||||
---
|
||||
|
||||
# Workflow Skill Generator
|
||||
|
||||
## 概要
|
||||
|
||||
このSkillは、ユーザーが提供する作業フローや業務プロセスの情報を基に、Workflow Skillのマークダウンファイル（SKILL.md）を生成する。ユーザーとの対話を通じて必要な情報を収集し、適切なテンプレートを選択して、標準化されたワークフロースキルのドキュメントを作成する。
|
||||
|
||||
## 責任範囲
|
||||
|
||||
このSkillは以下の範囲をカバーする:
|
||||
|
||||
- 既存スキルの確認と重複チェック
|
||||
- ユーザーとの対話による作業フロー情報の収集
|
||||
- ワークフローのフェーズ分解と整理
|
||||
- 入力・出力・実施内容の明確化
|
||||
- テンプレート（simple版/full版）の選択
|
||||
- SKILL.mdファイルの生成
|
||||
- テンプレートファイルの生成（ドキュメント生成を含む場合、skills/[スキル名]/templates/配下）
|
||||
- プラグインアーキテクチャ規約の遵守確認
|
||||
- markdownlint検証の実施
|
||||
- ユーザーフィードバックの収集と反映
|
||||
|
||||
## ワークフロー
|
||||
|
||||
### フェーズ1: 既存スキル確認
|
||||
|
||||
スキル生成前に、既存のスキルを確認し、重複を避ける。
|
||||
|
||||
**実施内容:**
|
||||
|
||||
1. プラグインディレクトリ内の既存スキルを確認する
|
||||
2. 作成予定のスキルと同じ目的のスキルが存在しないか確認する
|
||||
3. 作成予定のスキル内容と重複する記述が他のスキルに含まれていないか確認する
|
||||
4. 既存スキルで代用できる場合はユーザーに提案する
|
||||
5. 重複が避けられない場合は、どの内容を削除すべきかユーザーと確認する
|
||||
|
||||
**確認対象:**
|
||||
|
||||
- プラグインディレクトリ内のskillsディレクトリ内のドキュメント
|
||||
|
||||
**質問例:**
|
||||
|
||||
```markdown
|
||||
【既存スキル確認】
|
||||
プラグインディレクトリ内の既存スキルを確認しました。
|
||||
以下のスキルと内容が重複する可能性があります：
|
||||
|
||||
- interaction-guidelines: ユーザーとの対話パターン、質問技法
|
||||
- documentation-standards: Markdown記述ルール、markdownlint検証
|
||||
|
||||
作成予定のスキルから、これらの重複内容を除外してよろしいですか？
|
||||
```
|
||||
|
||||
**既存スキルで代用可能な場合:**
|
||||
|
||||
```markdown
|
||||
【確認】
|
||||
作成予定のスキルと同じ目的のスキルが既に存在します：
|
||||
- [既存スキル名]: [既存スキルの説明]
|
||||
|
||||
既存スキルで十分な場合は、新規作成は不要です。
|
||||
それでも新規作成が必要ですか？必要な場合は、既存スキルとの違いを教えてください。
|
||||
```
|
||||
|
||||
### フェーズ2: 情報収集
|
||||
|
||||
ユーザーとの対話を通じて、ワークフロースキルに必要な情報を収集する。
|
||||
|
||||
**実施内容:**
|
||||
|
||||
1. スキルの目的と対象作業を確認する
|
||||
2. 作業フローの全体像を把握する
|
||||
3. フェーズ分解の可能性を検討する
|
||||
4. 入力データと出力データを特定する
|
||||
5. 前提条件や制約事項を確認する
|
||||
6. ユーザーとの対話時は、明確なタイトル付き質問、複数選択肢の提示、推奨オプションの明示を行う
|
||||
|
||||
### フェーズ3: テンプレート選択
|
||||
|
||||
収集した情報を基に、適切なテンプレート（simple版/full版）を選択する。
|
||||
|
||||
**実施内容:**
|
||||
|
||||
1. スキルの複雑度を評価する
|
||||
2. テンプレートの選択肢（simple版/full版）を提示する
|
||||
3. 推奨テンプレートを明示してユーザーに確認する
|
||||
|
||||
**テンプレート選択基準:**
|
||||
|
||||
- simple版: フェーズが2〜3個程度のシンプルな作業
|
||||
- full版: フェーズが4個以上の複雑な作業、良い例/悪い例が必要
|
||||
|
||||
### フェーズ4: コンテンツ生成
|
||||
|
||||
選択したテンプレートを基に、SKILL.mdファイルのコンテンツを生成する。
|
||||
|
||||
**実施内容:**
|
||||
|
||||
1. フロントマター（name, description）を作成する
|
||||
2. 概要セクションを記述する
|
||||
3. 責任範囲を定義する
|
||||
4. 前提条件を記述する（該当する場合）
|
||||
5. 基本方針を記述する（該当する場合）
|
||||
6. ワークフローをフェーズごとに記述する
|
||||
7. アウトプット定義を記述する
|
||||
8. チェックリストを作成する
|
||||
9. エラー処理・ベストプラクティスを記述する（full版の場合）
|
||||
10. ドキュメント生成を含む場合、テンプレートファイルを生成し、skills/[スキル名]/templates/配下に配置する
|
||||
|
||||
**フロントマターの作成:**
|
||||
|
||||
```markdown
|
||||
---
|
||||
name: スキル名（ケバブケース、例: database-schema-designer）
|
||||
description: スキルの簡潔な説明（1行、50文字以内）
|
||||
---
|
||||
```
|
||||
|
||||
**概要の記述:**
|
||||
|
||||
- スキルの目的を明確に記述する
|
||||
- 実行する作業の範囲を説明する
|
||||
- 簡潔に1〜2段落で記述する
|
||||
|
||||
**責任範囲の定義:**
|
||||
|
||||
- 箇条書きで3〜5項目を記述する
|
||||
- 「〜を収集する」「〜を生成する」「〜を検証する」のような動詞で表現する
|
||||
- スキルがカバーする範囲を明確にする
|
||||
|
||||
**ワークフローの記述:**
|
||||
|
||||
各フェーズに以下を含める:
|
||||
|
||||
- フェーズ名（例: フェーズ1: 情報収集）
|
||||
- フェーズの説明（1〜2行）
|
||||
- 実施内容（箇条書き）
|
||||
- 入力データ（該当する場合）
|
||||
- 出力データ（該当する場合）
|
||||
- 良い例/悪い例（full版の場合）
|
||||
|
||||
**チェックリストの作成:**
|
||||
|
||||
- 各フェーズの完了時チェックリスト
|
||||
- 最終確認チェックリスト
|
||||
- 具体的で検証可能な項目を記述する
|
||||
|
||||
**プラグインアーキテクチャ規約の遵守:**
|
||||
|
||||
生成するスキルは、プラグインアーキテクチャ規約に従う必要がある（独立性の原則、汎用性の原則、単一責任の原則など）。
|
||||
|
||||
**重複最小化の確認:**
|
||||
|
||||
既存スキルと重複する内容が含まれていないかを確認し、スキル固有の内容のみを記述する。
|
||||
|
||||
### フェーズ5: 検証
|
||||
|
||||
生成したコンテンツを検証し、品質を確保する。
|
||||
|
||||
**実施内容:**
|
||||
|
||||
1. 設計原則の遵守を確認する
|
||||
2. markdownlint検証を実施する
|
||||
3. テンプレート構造の整合性を確認する
|
||||
4. ユーザーにプレビューを提示する
|
||||
5. フィードバックを収集する
|
||||
6. 必要に応じて修正する
|
||||
|
||||
**プラグインアーキテクチャ規約の確認:**
|
||||
|
||||
- プラグインアーキテクチャ規約に従っている
|
||||
- 既存スキルと重複する内容が含まれていない
|
||||
|
||||
## アウトプット
|
||||
|
||||
このスキルは以下を生成する:
|
||||
|
||||
- **SKILL.md**: ワークフロースキルの定義ファイル
|
||||
- フロントマター（name, description）
|
||||
- 概要、責任範囲、基本方針
|
||||
- ワークフロー（フェーズごとの実施内容）
|
||||
- アウトプット定義
|
||||
- チェックリスト
|
||||
- エラー処理・ベストプラクティス（full版の場合）
|
||||
|
||||
## 想定されるエラーと対処法
|
||||
|
||||
### エラー1: 責任範囲が曖昧
|
||||
|
||||
**検出例:**
|
||||
|
||||
```markdown
|
||||
このSkillは、いろいろな作業を行う
|
||||
```
|
||||
|
||||
**対処法:**
|
||||
|
||||
- 具体的な動詞を使用する（収集する、生成する、検証する）
|
||||
- 責任範囲を明確に列挙する
|
||||
|
||||
## ベストプラクティス
|
||||
|
||||
- フェーズは2〜5個に抑える（多すぎると複雑になる）
|
||||
- 各フェーズの実施内容は3〜5項目程度にする
|
||||
- チェックリストは具体的で検証可能な項目にする
|
||||
- 良い例/悪い例は実用的なものを記述する（full版の場合）
|
||||
- markdownlint検証は必ず実施する
|
||||
- ユーザーフィードバックを反映して改善する
|
||||
|
||||
## チェックリスト
|
||||
|
||||
### 既存スキル確認完了時
|
||||
|
||||
- [ ] プラグインディレクトリ内の既存スキルを確認した
|
||||
- [ ] 同じ目的のスキルが存在しないことを確認した
|
||||
- [ ] 重複する内容が他のスキルに含まれていないことを確認した
|
||||
- [ ] 既存スキルで代用できない理由が明確である
|
||||
- [ ] 重複する内容を除外する方針を決定した
|
||||
|
||||
### 情報収集完了時
|
||||
|
||||
- [ ] スキルの目的が明確になっている
|
||||
- [ ] 作業フローの全体像を把握している
|
||||
- [ ] フェーズ分解の方針が決まっている
|
||||
- [ ] 入力データと出力データが特定されている
|
||||
- [ ] 前提条件や制約事項が確認されている
|
||||
|
||||
### テンプレート選択完了時
|
||||
|
||||
- [ ] スキルの複雑度を評価した
|
||||
- [ ] テンプレート（simple/full）を選択した
|
||||
- [ ] ユーザーの確認を得た
|
||||
|
||||
### コンテンツ生成完了時
|
||||
|
||||
- [ ] フロントマター（name, description）が記述されている
|
||||
- [ ] 概要が簡潔に記述されている
|
||||
- [ ] 責任範囲が明確に定義されている
|
||||
- [ ] ワークフローがフェーズごとに記述されている
|
||||
- [ ] 各フェーズに実施内容が含まれている
|
||||
- [ ] アウトプット定義が記述されている
|
||||
- [ ] チェックリストが作成されている
|
||||
- [ ] プラグインアーキテクチャ規約に従っている
|
||||
- [ ] 既存スキルと重複する内容が含まれていない
|
||||
|
||||
### 検証完了時
|
||||
|
||||
- [ ] プラグインアーキテクチャ規約の遵守を確認した
|
||||
- [ ] markdownlint検証を実施した（エラーなし）
|
||||
- [ ] テンプレート構造の整合性を確認した
|
||||
- [ ] ユーザーにプレビューを提示した
|
||||
- [ ] フィードバックを収集した
|
||||
- [ ] 必要な修正を完了した
|
||||
|
||||
### 最終確認
|
||||
|
||||
- [ ] SKILL.mdファイルが生成されている
|
||||
- [ ] すべてのセクションが適切に記述されている
|
||||
- [ ] プラグインアーキテクチャ規約が遵守されている
|
||||
- [ ] markdownlint検証に合格している
|
||||
- [ ] ユーザーの承認を得ている
|
||||
@@ -0,0 +1,178 @@
|
||||
---
|
||||
name: [skill-name]
|
||||
description: [このWorkflow Skillが実行する作業を簡潔に説明]
|
||||
---
|
||||
|
||||
# [Workflow Skill名]
|
||||
|
||||
## 概要
|
||||
|
||||
[このスキルの目的と実行する作業の概要を記述]
|
||||
|
||||
## 責任範囲
|
||||
|
||||
このSkillは以下の範囲をカバーする:
|
||||
|
||||
- [責任範囲の内容1]
|
||||
- [責任範囲の内容2]
|
||||
- [責任範囲の内容3]
|
||||
|
||||
## 前提条件
|
||||
|
||||
- [前提条件1]
|
||||
- [前提条件2]
|
||||
- [前提条件3]
|
||||
|
||||
## 基本方針
|
||||
|
||||
- [基本方針1]
|
||||
- [基本方針2]
|
||||
- [基本方針3]
|
||||
|
||||
## ワークフロー
|
||||
|
||||
### フェーズ1: [フェーズ名]
|
||||
|
||||
[フェーズの詳細説明]
|
||||
|
||||
**実施内容:**
|
||||
|
||||
- [作業内容1]
|
||||
- [作業内容2]
|
||||
- [作業内容3]
|
||||
|
||||
**入力:**
|
||||
|
||||
- [入力データ1]
|
||||
- [入力データ2]
|
||||
|
||||
**出力:**
|
||||
|
||||
- [出力データ1]
|
||||
- [出力データ2]
|
||||
|
||||
良い例:
|
||||
|
||||
```text
|
||||
[推奨される実施方法の例]
|
||||
```
|
||||
|
||||
悪い例:
|
||||
|
||||
```text
|
||||
[避けるべき実施方法の例]
|
||||
```
|
||||
|
||||
### フェーズ2: [フェーズ名]
|
||||
|
||||
[フェーズの詳細説明]
|
||||
|
||||
**実施内容:**
|
||||
|
||||
- [作業内容1]
|
||||
- [作業内容2]
|
||||
- [作業内容3]
|
||||
|
||||
**入力:**
|
||||
|
||||
- [入力データ1]
|
||||
- [入力データ2]
|
||||
|
||||
**出力:**
|
||||
|
||||
- [出力データ1]
|
||||
- [出力データ2]
|
||||
|
||||
良い例:
|
||||
|
||||
```text
|
||||
[推奨される実施方法の例]
|
||||
```
|
||||
|
||||
悪い例:
|
||||
|
||||
```text
|
||||
[避けるべき実施方法の例]
|
||||
```
|
||||
|
||||
### フェーズ3: [フェーズ名]
|
||||
|
||||
[フェーズの詳細説明]
|
||||
|
||||
**実施内容:**
|
||||
|
||||
- [作業内容1]
|
||||
- [作業内容2]
|
||||
- [作業内容3]
|
||||
|
||||
**入力:**
|
||||
|
||||
- [入力データ1]
|
||||
- [入力データ2]
|
||||
|
||||
**出力:**
|
||||
|
||||
- [出力データ1]
|
||||
- [出力データ2]
|
||||
|
||||
## アウトプット
|
||||
|
||||
このスキルは以下を生成する:
|
||||
|
||||
- **[アウトプット名1]**: [詳細な説明]
|
||||
- **[アウトプット名2]**: [詳細な説明]
|
||||
- **[アウトプット名3**]: [詳細な説明]
|
||||
|
||||
## エラー処理
|
||||
|
||||
### 想定されるエラーと対処法
|
||||
|
||||
**エラー1: [エラー名]**
|
||||
|
||||
- 原因: [原因の説明]
|
||||
- 対処法: [対処法の説明]
|
||||
|
||||
**エラー2: [エラー名]**
|
||||
|
||||
- 原因: [原因の説明]
|
||||
- 対処法: [対処法の説明]
|
||||
|
||||
## ベストプラクティス
|
||||
|
||||
- [ベストプラクティス1]
|
||||
- [ベストプラクティス2]
|
||||
- [ベストプラクティス3]
|
||||
|
||||
## チェックリスト
|
||||
|
||||
### 作業開始前
|
||||
|
||||
- [ ] 前提条件がすべて満たされている
|
||||
- [ ] 必要な入力データが揃っている
|
||||
- [ ] 作業環境が準備されている
|
||||
|
||||
### フェーズ1完了時
|
||||
|
||||
- [ ] [チェック項目1-1]
|
||||
- [ ] [チェック項目1-2]
|
||||
- [ ] [チェック項目1-3]
|
||||
|
||||
### フェーズ2完了時
|
||||
|
||||
- [ ] [チェック項目2-1]
|
||||
- [ ] [チェック項目2-2]
|
||||
- [ ] [チェック項目2-3]
|
||||
|
||||
### フェーズ3完了時
|
||||
|
||||
- [ ] [チェック項目3-1]
|
||||
- [ ] [チェック項目3-2]
|
||||
- [ ] [チェック項目3-3]
|
||||
|
||||
### 最終確認
|
||||
|
||||
- [ ] すべてのフェーズが完了している
|
||||
- [ ] すべてのアウトプットが生成されている
|
||||
- [ ] 品質基準を満たしている
|
||||
- [ ] エラーや警告がない
|
||||
- [ ] ドキュメントが更新されている（必要に応じて）
|
||||
@@ -0,0 +1,68 @@
|
||||
---
|
||||
name: [skill-name]
|
||||
description: [このWorkflow Skillが実行する作業を簡潔に説明]
|
||||
---
|
||||
|
||||
# [Workflow Skill名]
|
||||
|
||||
## 概要
|
||||
|
||||
[このスキルの目的と実行する作業の概要を記述]
|
||||
|
||||
## 責任範囲
|
||||
|
||||
このSkillは以下の範囲をカバーする:
|
||||
|
||||
- [責任範囲の内容1]
|
||||
- [責任範囲の内容2]
|
||||
- [責任範囲の内容3]
|
||||
|
||||
## 前提条件
|
||||
|
||||
- [前提条件1]
|
||||
- [前提条件2]
|
||||
|
||||
## ワークフロー
|
||||
|
||||
### フェーズ1: [フェーズ名]
|
||||
|
||||
[フェーズの説明]
|
||||
|
||||
**実施内容:**
|
||||
|
||||
- [作業内容1]
|
||||
- [作業内容2]
|
||||
|
||||
### フェーズ2: [フェーズ名]
|
||||
|
||||
[フェーズの説明]
|
||||
|
||||
**実施内容:**
|
||||
|
||||
- [作業内容1]
|
||||
- [作業内容2]
|
||||
|
||||
## アウトプット
|
||||
|
||||
このスキルは以下を生成する:
|
||||
|
||||
- **[アウトプット名1]**: [説明]
|
||||
- **[アウトプット名2]**: [説明]
|
||||
|
||||
## チェックリスト
|
||||
|
||||
### フェーズ1完了時
|
||||
|
||||
- [ ] [チェック項目1-1]
|
||||
- [ ] [チェック項目1-2]
|
||||
|
||||
### フェーズ2完了時
|
||||
|
||||
- [ ] [チェック項目2-1]
|
||||
- [ ] [チェック項目2-2]
|
||||
|
||||
### 最終確認
|
||||
|
||||
- [ ] すべてのフェーズが完了している
|
||||
- [ ] アウトプットが生成されている
|
||||
- [ ] 品質基準を満たしている
|
||||
Reference in New Issue
Block a user