plugin-dev

1. ミッション

このメタスキルは、AIエコシステム全体の技術ガバナンスを司ります。共有スキル（.agents/skills/）、黄金ルールと恒久ガイドライン（.agents/rules/）、およびパッケージ知識の継続的獲得（[PkgName]_IA_CONTEXT.md）の設計、作成、継続的な改善を行います。

不可侵の基本原則：

• Single Source of Truth (SSOT) : すべてのルール、仕様、ガイドラインは、単一の権威ある場所に存在しなければなりません。複数のファイルにわたる指示の重複は正式に禁止されます。
• DRY (Don't Repeat Yourself) : 既存の指示を決して書き直したり複製したりしてはいけません。すべてのスキルまたはドキュメントは、既存のルールを単なる参照またはリンクとして活用しなければなりません。
• このスキルは、Anthropicの参照パターン（feature-dev, claude-code-setup, pr-review-toolkit）を体系的に適用し、ルールの非矛盾性を保証し、新しいワークフローを文書化し、フィードバックをYAMLインシデントカードとして記録します。

2. 起動条件と制限

• 起動する場合：
  • 会話終了 / セッション振り返り： /plugin-dev によって呼び出され、処理されたパッケージの [PkgName]_IA_CONTEXT.md ファイルと利用されたスキルに対して、セッション中に学んだ発見、落とし穴、仕組みを記録する強化計画を提案します。
  • 新しいスキルの作成リクエスト（「自動テストを管理するスキルを作成して」、「アーキテクチャ設計スキルを追加して」）。
  • 経験からのフィードバックに基づく既存スキルの改良または修正（「feature-dev スキルを修正してXを禁止するようにして」）。
  • 行動ルールの作成、更新、監査（「使用したスキルを表示するルールを追加して」、「critical-rules.md の移行に関する重要なルールを修正して」）。
  • 新しいワークフローの文書化。
  • スキルの準拠監査、ガイドラインの一貫性、重複排除（DRY/SSOT）、およびSemVerの管理。
• 起動してはいけない場合：
  • チュートリアルの作成や簡略化 ➔ tutorial-writer を使用。
  • Jekyllコンポーネントやスタイルの開発 ➔ dev-jekyll を使用。
  • 共有技術基盤（Core Theme）の同期 ➔ sync-theme を使用。
  • エージェントの初期化またはプロジェクト診断 ➔ project-setup を使用。

3. 入力と読み込むリソース

• 優先度1： .agents/skills/plugin-dev/resources/anthropic-skill-patterns.md（カプセル化されたAnthropic公式パターン）。
• 優先度2： ルールファイル：
  • .agents/rules/critical-rules.md（不変の重要なルール）。
  • .agents/rules/*.md（実行スタイルのガイドライン）。
• 優先度3： .agents/templates/generic-skill.md（10セクションのテンプレート）および .agents/templates/workflow-blueprint.md（ワークフローモデル）。
• 優先度4： グローバルハブのレジストリ catalog.yaml および CHANGELOG.md。

4. 制約と不可侵ルール

• SSOT（Single Source of Truth）とDRYの基本原則：
  • すべての慣習、ガイドライン、仕様は、唯一つの場所に存在しなければなりません。
  • 行動ルールは .agents/rules/[name].md に置かれます。スキルはこれらのルールのテキストを決して複製してはいけませんが、直接参照しなければなりません。
• パッケージコンテキストファイルの標準形式：
  • すべてのパッケージコンテキストファイルは、必ず modules/[PkgName]/[PkgName]_IA_CONTEXT.md という名前でなければなりません（例：PkgTaskCompletion_IA_CONTEXT.md）。
• .agents/references/ の厳格な最小主義（単一スキルカプセル化）：
  • 横断的な .agents/references/ ディレクトリには、最小限のファイルのみを含め、2つ以上のスキルで共有される慣習と標準にのみ予約します。
  • 単一のスキルでのみ使用される方法論ガイド、カタログ、テンプレートは、必ず <skill>/resources/ に移動し、カプセル化しなければなりません（Anthropicの段階的開示原則）。
• inspiration ブロック必須： 作成または変更されるすべてのスキルは、そのYAMLフロントマターに inspiration: メタデータを、そのソース、参照プラグイン、パターンとともに必ず含めなければなりません。
• 10セクションの厳守： 標準化された10セクションのうち一つでも欠けているスキルは公開できません。
• ルールの階層と非矛盾性：
  • ローカルルール（.agents/rules/）は一般的な推奨事項よりも優先されますが、明示的な裁定なしにセキュリティの重要なルール（critical-rules.md）に違反してはいけません。
  • 各ルールは簡潔で明白であり、明示的なトリガー（trigger: always_on または条件付き）を持つ必要があります。
• 自動検証： スキルの変更はすべて node scripts/validate-skills.js によって検証されなければなりません。
• YAMLインシデントカード： エージェントのバグによる修正はすべて、tests/feedbacks/INC-xxx.yaml にカードを生成しなければなりません。

5. ステップバイステップ手順（設計と改良のワークフロー）

パスA：新しいスキルの作成

1. ステップ1：要件分析とAnthropicパターン：
   • resources/anthropic-skill-patterns.md を参照して、最も近いパターン（feature-dev、setup、review など）を選択します。
2. ステップ2：SKILL.md の執筆：
   • 10セクションのテンプレートに記入します。
   • 説明は三人称で、起動ケースと除外ケースを明確に示します。
   • YAML inspiration ブロックに記入します。
   • スキル固有の付随リソースは、そのサブディレクトリ resources/ にカプセル化します。
3. ステップ3：決定論的チェック：
   • node scripts/validate-skills.js を実行します。
4. ステップ4：カタログへの登録：
   • catalog.yaml にエントリを追加し、CHANGELOG.md に文書化します。

パスB：既存スキルの改良

1. ステップ1：診断とYAMLカード：
   • コンテキスト、観察された動作、および目標とする修正を含む tests/feedbacks/INC-[NUM].yaml を作成します。
2. ステップ2：外科的修正：
   • セクション#4（制約）にルールを追加するか、セクション#8（チェックリスト）に二値テストを追加します。
3. ステップ3：SemVerのインクリメント：
   • バージョンを更新し（例：1.0.1）、CHANGELOG.md に記録します。

パスC：ルールの作成または変更

1. ステップ1：ルールレベルの分類：
   • グローバルなエンジニアリング/セキュリティルール ➔ .agents/rules/critical-rules.md または .agents/rules/general-principles.md に追加。
   • プロジェクトエージェントの行動ルール ➔ .agents/rules/[rule-name].md に追加。
2. ステップ2：簡潔で不可侵な執筆：
   • 明確な命令形で記述します（「エージェントは...しなければならない」、「...を正式に禁止する」）。
   • 期待される形式の直接的な例を示します。
   • SSOT原則を尊重し、ルールが既に存在する場合は決して複製してはいけません。
3. ステップ3：同期と通知：
   • 変更をハブまたはローカルプロジェクトに反映し、CHANGELOG.md に進化を記録します。

パスD：会話終了時の継続的知識獲得（/plugin-dev）

1. ステップ1：振り返りと発見の特定：
   • 最近のセッションで処理されたパッケージを特定します。
   • エージェントが調査または推論する必要があった特定の仕組みを抽出します：
     • 関係するテーブルとモデル、リレーション、ビジネスフック。
     • ViewStateService またはテーブルフィルターの特異性。
     • 新しく導入された時間サービス、ジョブ、オブザーバー。
     • 解決された落とし穴やエッジケース（例：親フィルターの省略による計算の歪み）。
2. ステップ2：文書ギャップの評価：
   • これらの発見を modules/[PkgName]/[PkgName]_IA_CONTEXT.md の既存コンテンツと比較します。
   • スキル（feature-dev）やルールが追加のガイドラインの恩恵を受けるかどうかを確認します。
3. ステップ3：強化計画の提案：
   • 設計者に、提案された追加内容を詳細に説明する、明確で構造化された計画を提出します：
     • [PkgName]_IA_CONTEXT.md 用（新しいサービス、主要フィルター、「落とし穴と推奨事項」セクション）。
     • 該当する場合はスキル用。
4. ステップ4：承認後の実行：
   • 承認後すぐに、[PkgName]_IA_CONTEXT.md ファイルを強化し、将来のすべてのメンテナンスセッションがこの獲得された知識をすぐに利用できるようにします。

6. 曖昧さの管理と決定

• リソース配置の裁定（スキル vs エージェント）：
  • リソースが特定のスキルによって排他的に利用される場合（例：ライターの編集テンプレート、独自の技術カタログ） ➔ 必須配置場所：<skill>/resources/[file].md（スキルのセクション3で必要に応じて読み込まれる）。
  • リソースが2つ以上のスキルで共有される横断的なエンジニアリング標準を定義する場合 ➔ 配置場所：.agents/references/conventions/ または .agents/references/architecture/。
• スキル vs ルールの裁定：
  • 指示が恒久的な制約または横断的なセーフガードである場合（例：スキルの表示、応答スタイル、移行の禁止） ➔ ルール（.agents/rules/）を作成。
  • 指示が、オンデマンドのトリガー、入力、ステップバイステップのロジック、成果物を備えたツール化されたシーケンスを説明する場合 ➔ スキル（SKILL.md）を作成。
• 要求されたルールが Solicode LMS に固有の場合：グローバルハブの標準を変更せず、.agents/rules/ および .agents/references/conventions/project-conventions.md に記録します。

7. 出力形式と成果物

• 完全な SKILL.md ファイル、またはルールファイル（.agents/rules/*.md）。
• catalog.yaml と CHANGELOG.md の更新。
• validate-skills.js スクリプトの実行結果（エラー0）。

8. 品質管理（二値チェックリスト）

• スキルのYAMLフロントマターに完全な inspiration ブロック（ソース、プラグイン、パターン）が含まれていますか？
• 説明は三人称で、起動する場合としない場合を明確に示していますか？
• 10の標準セクションがすべて存在し、記入されていますか？
• SSOT（Single Source of Truth）原則とDRYルールが尊重されていますか（ファイル間で重複した指示はありませんか）？
• .agents/references/ ディレクトリは最小限であり、単一スキルのリソースが含まれていませんか？
• 単一スキルのリソースは厳密に <skill>/resources/ にカプセル化されていますか？
• ルールの場合、簡潔で、critical-rules と矛盾せず、明確な例が付属していますか？
• node scripts/validate-skills.js スクリプトが正常にパスしますか？

9. 頻出エラーの管理

典型的なエラー	原因	即時解決策
エージェントレベルに固有リソースを配置	カプセル化の粒度不足	ファイルを <skill>/resources/ に移動し、内部リソースとして参照する
単なる受動的なルールに対してスキルを作成	ルールとツール化されたフローの混同	指示を .agents/rules/ に移行する
inspiration メタデータの忘れ	不注意	フロントマターに inspiration ブロックを体系的に追加する
ローカルルールがハブ標準と競合	事前監査の欠如	ルールを正式化する前に .agents/rules/critical-rules.md を監査する

10. 具体的な例（Few-Shot）

呼び出し例A（スキル）： 「content-authoring に触発された tutorial-writer スキルを作成して。」 動作： エージェントは anthropic-skill-patterns.md を読み込み、構造化ライティングパターンを抽出し、inspiration: { plugin: "content-authoring" } を持つ10セクションを作成し、教育テンプレートを tutorial-writer/resources/ に分離し、スキルを catalog.yaml に登録します。

呼び出し例B（ルール）： 「各メッセージの終わりに使用されたスキルを表示することを義務付けるルールを追加して。」 動作： エージェントは plugin-dev のパスCを適用し、.agents/rules/display-skills.md を作成し、.agents/rules/critical-rules.md を更新し、直ちに必要な形式を適用します。