プラグイン全体の構造設計原則（要素の役割分担、階層構造、依存関係管理）を定義する。プラグイン設計時、アーキテクチャレビュー時、またはユーザーがプラグイン構造、設計原則、独立性、汎用性、依存関係管理に言及した際に使用する。
Defines plugin structure, component roles, and dependency management principles. Use when designing plugins, reviewing architecture, or discussing structure, independence, and dependencies.
/plugin marketplace add RevTechStudio/rts-plugins/plugin install rts-plugin-generator@rts-pluginsThis skill inherits all available tools. When active, it can use any tool Claude has access to.
このSkillは、プラグイン全体のアーキテクチャ設計原則を定義する。プラグインを構成する要素（エージェント、スキル、コマンド）の役割分担、依存関係管理、独立性の確保、汎用性の維持について明確な指針を提供し、再利用可能で保守性の高いプラグイン設計を実現することを目的とする。
このSkillは以下の範囲をカバーする:
プラグインは以下のディレクトリ構造を持つ:
[プラグイン名]/
├── 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
注釈:
[プラグイン名]/agents/[エージェント名].mdplugin-development-agent.md）[プラグイン名]/skills/[スキル名]/SKILL.md[プラグイン名]/skills/[スキル名]/SKILL.mdcommand-generator）SKILL.md とする（大文字）templates/ ディレクトリを同じディレクトリ内に作成[プラグイン名]/commands/[コマンド名].mdgenerate-agent.md）コマンドやスキルのドキュメント内で出力先を記述する際は、以下の形式を使用する:
[プラグインディレクトリ]/agents/[エージェント名].md[プラグインディレクトリ]/skills/[スキル名]/SKILL.md[プラグインディレクトリ]/commands/[コマンド名].mdプレースホルダー [プラグインディレクトリ] は、ユーザーが実際に使用するプラグインのルートディレクトリを指す。固有のプラグイン名を含めず、汎用的な表現を維持する。
エージェントは責任範囲が定義されている要素である。
特徴:
例:
スキルは単一作業のワークフローが記述されている要素である。
特徴:
例:
コマンドはエージェントと複数のスキルを組み合わせて作業を行うためのワークフローが定義されている要素である。
特徴:
例:
スキルは以下の2種類に分類される。
実際にワークフローに沿って具体的な作業を実行するスキルである。
特徴:
例:
テンプレートファイル:
テンプレートファイルを持つ例:
テンプレートファイルを持たない例:
規約やガイドラインが定義されているスキルである。
特徴:
例:
テンプレートファイル:
すべてのエージェントおよびすべてのスキルは互いに依存しない。コマンドが以下の責任を持つ:
エージェントとスキルは再利用可能な独立したコンポーネントとして設計される。
原則:
プラグイン開発において、Analyzer（分析スキル）とGenerator（生成スキル）の責任範囲を明確に分離する。
Analyzerは分析と特定に責任を持つ。
責任:
禁止事項:
例:
Generatorは生成と配置に責任を持つ。
責任:
原則:
例:
domain-analyzer（分析）:
[{skill: "requirement-analysis-workflow", templates: ["requirements-document.md"]}]workflow-skill-generator（生成）:
domain-analyzer（分析）:
[] （空）convention-skill-generator（生成）:
エージェントとスキルのドキュメント内で、他のエージェント、スキル、コマンドを参照してはいけない。
重要: この制限はエージェントとスキルのみに適用される。コマンドは依存関係を管理する役割を持つため、エージェントとスキルを明示的に参照することが求められる。
理由:
必要な規約やガイドラインは、各エージェント・スキルのドキュメント内に直接記述するか、汎用的な表現で記載する。
エージェント・スキルの場合:
良い例:
コーディングルールに従う
（具体的なルールは当該スキル内に記述）
ドキュメント記述標準に従う
（具体的な標準は当該スキル内に記述）
要件定義フェーズに対する責任を持つ
（他のエージェントに言及しない）
設計完了後に実行する
（コマンド名を明示しない）
ユーザーとの対話パターンに従う
（具体的なパターンは当該スキル内に記述）
悪い例:
コーディングルールは coding-convention スキルに従う
（他のスキルを参照している）
詳細は documentation-standards スキルを参照
（他のスキルを参照している）
Requirements Agent と連携して動作する
（他のエージェントを参照している）
design コマンドを実行してから使用する
（他のコマンドを参照している）
interaction-guidelines スキルで定義された対話パターンを使用する
（他のスキルを参照している）
コマンドの場合:
良い例:
version-control-agentがversion-control-guidelinesスキルを使用して、現在の変更状況を確認する
（コマンドは依存関係を管理するため、エージェントとスキルを明示的に参照する）
design-agentがapi-design-guidelinesスキルとdocumentation-standardsスキルを使用して、API仕様書を作成する
（複数のスキルを組み合わせて使用することを明示）
すべてのエージェント、スキル、コマンドにおいて、固有名詞を含めない。
対象:
理由:
コード例やサンプルにおいても、固有名詞の使用を避ける。代わりに、以下のような汎用的なプレースホルダーを使用する:
YourProject: プロジェクト名のプレースホルダーYourCompany: 組織名のプレースホルダーexample.com: ドメイン名のプレースホルダー良い例（エージェントの記述）:
このエージェントは、すべての要件定義フェーズに対する責任を持つ。
悪い例（エージェントの記述）:
このエージェントは、XYZ社プロジェクトの要件定義フェーズに対する責任を持つ。
良い例（スキルの記述）:
このSkillは、開発されるすべての.NETプロジェクトに適用されるコーディング規約を定義する。
悪い例（スキルの記述）:
このSkillは、ABC社で開発されるすべての.NETプロジェクトに適用されるコーディング規約を定義する。
良い例（コマンドの記述）:
このコマンドは、要件定義フェーズ全体を管理し、要件定義書を生成する。
悪い例（コマンドの記述）:
このコマンドは、XYZ社の要件定義フェーズ全体を管理し、要件定義書を生成する。
良い例（コード例）:
namespace YourProject.Orders;
public class OrderProcessor
{
// 実装
}
悪い例（コード例）:
namespace RevTechStudio.Orders;
public class OrderProcessor
{
// 実装
}
コマンドは以下の責任を持つ:
各フェーズでは1〜2個のコマンドに抑えることで、ユーザーが覚えるべきコマンド数を最小限にする。
例:
requirements: 要件定義フェーズ全体を管理design: 詳細設計フェーズ全体を管理し、設計書の出力先を指定task: 設計完了後にタスク分割を実行し、タスクリストの出力先を指定[プラグイン名]/agents/[エージェント名].md の形式で配置されている[プラグイン名]/skills/[スキル名]/SKILL.md の形式で配置されているSKILL.md（大文字）になっている[プラグイン名]/commands/[コマンド名].md の形式で配置されている[プラグインディレクトリ]/... の形式で記述されている