devetai/better-plugin-gen

Better Plugin Generator (better-plugin-gen)

このスキルは、ユーザーがプラグインを作成するのを支援します。プラグインとは、スキル、エージェント、フック、MCPサーバーなどの複数のコンポーネントをパッケージ化したディレクトリで、1つのコマンドでコーディングエージェントにインストールできます。このスキルは3つのホスト（プラグインを読み込むエージェントツール：Claude Code、Codex、Antigravity）をサポートします。各ホストには独自のマニフェストがあります。スキルは共通の skills/ ディレクトリを使用し、選択された各ホスト用のマニフェストを生成します。

以下の template.md、references/、examples/、scripts/ へのパスはすべて、この SKILL.md ファイルが置かれているディレクトリからの相対パスです。

---

1. 基本原則

1. 事前に質問し、その後生成する。 構造化された質問ツールが利用可能なセッションではそれを使用して、すべての選択肢をユーザーに尋ねます。利用できない場合は、番号付きの選択肢を列挙し、推奨事項を明記した上で、回答を待ちます。質問の前には、これから作成するプラグインの目的、質問の内容、およびその質問が発生した理由を簡潔に説明します。不明な点を推測してファイルを生成してはいけません。
2. ホストの仕様を推測しない。 ファイルの場所、マニフェストの形式、MCPの設定は references/hosts.md に従います。「未確認」と記載されている点はユーザーに報告する必要があります。
3. 主要なロジックはスキルに配置する。 スキルは3つのホストすべてで実行される唯一のコンポーネントです。エージェント、コマンド、フック、LSPは、ユーザーが必要とし、かつホストがサポートしている場合にのみ追加します。
4. 最小限の実行可能なフレームワークを提供する。 生成される各コンポーネントはすぐに実行可能である必要がありますが、内容は簡潔にします。プロジェクトに better-skill-gen または better-agent-gen スキルが存在する場合は、プラグインが動作した後、それらを使用してスキルやエージェントを詳細に記述するようユーザーに提案します。
5. 自己検証。 プラグインは scripts/validate.sh が終了コード 0 を返した場合にのみ引き渡されます。
6. 外部への副作用を発生させない。 スキルは指定されたプラグインディレクトリ（およびユーザーが選択した場合はリポジトリルートのマーケットプレイスファイル）にのみファイルを書き込みます。git commit、git push は実行せず、プラグインのインストールも行わず、ユーザーのホスト設定も変更しません。ユーザーが自分で実行するためのコマンドを表示するだけです。

---

2. 入力

• 必須: プラグインの目的（一文でも可）、またはコンポーネントを追加するための既存プラグインへのパス。ユーザーのリクエストから取得します。
• 未指定の場合に質問する項目: ターゲットホスト、ディレクトリの場所、コンポーネントのリスト、マーケットプレイスの有無、プラグイン名、作者、ライセンス。
• 情報が不足している場合: セクション3のステップ2に従って質問します。回答が得られない場合は、処理を停止して回答を待ちます。

---

3. 処理フロー

ステップ1: モードの特定と現状の読み取り

• 新規作成: ユーザーがプラグインを説明しており、まだディレクトリが存在しません。
• コンポーネント/ホストの追加: ユーザーが .claude-plugin/plugin.json、.codex-plugin/plugin.json、または plugin.json を含むパスを提供します。すべてのマニフェストを読み取り、既存のコンポーネントをリストアップし、シェルコマンド bash scripts/validate.sh <dir> を実行して、修正前に既存のエラーを把握します。
• マーケットプレイスの作成: ユーザーは既にプラグインを持っており、公開のみが必要です。上記と同様にプラグインを読み取り、ステップ6に進みます。
• references/hosts.md を読み取ります。「検証日」が30日より古い場合、またはプラグインにファイルにない機能が必要な場合：そのファイルのセクション6に記載されている情報源をWeb上で確認し、ファイルと検証日を更新し、変更点をユーザーに報告します。

ステップ2: ユーザーへの質問

理解した内容（プラグインの目的、誰が使うか、いつ実行するか）を要約し、第1ラウンドの質問を行います。ユーザーが既に明確に回答した質問はスキップします。

質問	タイプ	選択肢（推奨を先頭に）
プラグインはどのホストで動作しますか？	複数選択	Claude Code; Codex; Antigravity。スキルとMCPのみを含むプラグインの場合は3つすべてを推奨。フック、LSP、userConfig が必要な場合はClaude Codeのみを推奨。
プラグインはどこに配置しますか？	単一選択	専用リポジトリ、プラグインはルート (./<name>/)；マーケットプレイスリポジトリ内 (plugins/<name>/)；テスト用に現在のプロジェクト内
プラグインにはどのコンポーネントを含めますか？	複数選択	スキル；エージェント；フック；MCPサーバー；コマンド；LSP；userConfig
公開用のマーケットプレイスを作成しますか？	単一選択	はい、選択したホスト用に；いいえ、ローカルでのテストのみ

第2ラウンド（必要な場合）：プラグイン名（説明からkebab-caseの名前を提案）、作者とGitHubリポジトリの所有者、ライセンス、各コンポーネントの詳細（スキルの機能、エージェントが使用するツール、フックがトリガーされるイベント、MCPサーバーとトークンの必要性など）。

質問時のルール：

• ユーザーがClaude Code以外のホストと一緒にフックを選択した場合：references/hosts.md のセクション4にある競合を事前に警告し、フックを維持するかどうかを尋ねます。
• プラグインにトークンやパスワードが必要な場合：提供方法を尋ねます（Claude Code：sensitive: true の userConfig；その他のホスト：READMEに記載する環境変数）。秘密の値をファイルに書き込んではいけません。
• Claude Codeの予約語（references/hosts.md セクション2.1）と名前が競合する場合：別の名前を提案します。
• ターゲットディレクトリに既存のファイルがある場合：上書きされるファイルをリストアップし、書き込み前に確認を取ります。

ステップ3: 設計の確定

チャット内に要約を記述します：名前、ホスト、場所、作成予定のディレクトリツリー（各ファイルのホストを注釈）、各コンポーネントがどのホストで実行されるか、エージェントが自動設定する値、未確認の点。回答によって新たな不明点が生じた場合は、さらに質問し、ファイルはまだ生成しません。

ステップ4: ファイルの生成

1. template.md（各ファイルのテンプレート）と references/components.md（各コンポーネントの形式）を読み取ります。examples/sample.md を読み取り、期待される詳細レベルを把握します。
2. 選択された各ホストのマニフェストを書き込みます。name、version、description はすべてのマニフェストで同一にします。
3. コンポーネントはプラグインのルートに書き込みます（.claude-plugin/ や .codex-plugin/ 内には配置しません）：
   • スキル： skills/<name>/SKILL.md、frontmatterは name と description のみで、どのホストからも読み取り可能にします。
   • MCP： Claude CodeとCodex用に .mcp.json、Antigravity用に mcp_config.json（リモートサーバーは serverUrl を使用）。両方のファイルに同一のサーバーリストを記述します。
   • フック： hooks/hooks.json をキー "hooks" でラップし、常に matcher を持ち、"${CLAUDE_PLUGIN_ROOT}"（Claude Codeの変数）を使用してスクリプトを呼び出します。スクリプトは scripts/ に配置し、shebangを持ちます。
   • エージェント、コマンド、LSP、userConfig：references/components.md に従います。
4. README.md をテンプレート（ファイル8）から書き込みます。最低40語以上で、ホスト別のコンポーネント表と各ホストのインストールコマンドを含めます（references/publishing.md セクション5）。
5. コンポーネント追加モード：新しいファイルのみを追加し、マニフェスト内の必要なキーのみを修正します。プラグインが既に公開されている場合は、すべてのマニフェストの version を上げます（パッチバージョン）。

ステップ5: 自己検証

1. シェルコマンド HOSTS="<選択されたホスト>" bash scripts/validate.sh <plugin-or-repo-directory> を実行します。例： HOSTS="claude codex antigravity"。
2. スクリプトは check_plugin.py（マニフェスト、名前、パス、MCP、フック、スキル、エージェント、マーケットプレイス、プレースホルダー、秘密文字列）を実行し、その後、マシンにインストールされていれば claude plugin validate と agy plugin validate を実行します。
3. [FAIL] があるか、CLIがエラーを報告した場合：ファイルを修正し、終了コードが 0 になるまで再実行します。
4. 各 [WARN] を読み取り：修正可能なものは修正します。保持する場合（例：複数ホストでのフック警告をユーザーに既に通知済み）、その理由を引き継ぎ報告書に記載します。
5. 一時ファイルが必要な場合は、ユーザーの指示で指定された一時ディレクトリに書き込みます。指定がない場合は、OSの一時ディレクトリを使用します。検証完了後すぐに削除します。

ステップ6: マーケットプレイス（選択された場合）

• Claude Code： .claude-plugin/marketplace.json をリポジトリルートに作成（テンプレートファイル9）。
• Codex： .agents/plugins/marketplace.json をリポジトリルートに作成（テンプレートファイル10）。
• Antigravity：ファイルは不要。READMEにGitHubリポジトリURLを含む agy plugin install コマンドを記載します（例： https://github.com/phucbui/pr-review-kit）。
• マーケットプレイスも検証するために、リポジトリルートディレクトリでステップ5を再実行します。

ステップ7: 引き渡し

template.md 末尾の「引き渡し報告書」テンプレートに従って報告書を出力します：ディレクトリ、ホスト、検証結果、ファイル一覧、未確認の点、ローカルテストコマンド、ユーザーが自分で実行する公開コマンド（references/publishing.md セクション3～6）。プロジェクトに better-skill-gen または better-agent-gen がある場合は、それらを使用してコンポーネントを詳細に記述する方法を1行で提案します。

---

4. 制約

• 必須：
  • ファイルを作成する前に、ホスト、場所、コンポーネント、マーケットプレイスについて質問すること。不明な点を自分で決定しないこと。
  • プラグインのターゲットディレクトリと、リポジトリルートのマーケットプレイスファイルにのみ書き込むこと。他の場所にサンプルファイルを作成しないこと。サンプルはこのスキルの examples/ ディレクトリ内にのみ存在します。
  • git commit、git push、claude plugin install、agy plugin install、codex plugin marketplace add を実行しないこと。コマンドを表示するのみとすること。
  • トークン、パスワード、APIキーをファイルに書き込まないこと。
  • scripts/validate.sh が終了コード 0 を返した場合にのみ引き渡すこと。
• 推奨：
  • プラグイン、スキル、エージェントの名前はkebab-caseにすること。初回バージョンは 0.1.0。
  • プラグインは1つの目的に集中させること。ユーザーが無関係な機能をまとめようとした場合は、プラグインを分割することを提案すること。
  • READMEに、どのコンポーネントがどのホストで実行されるかを明確に記載すること。
• 避けるべきこと：
  • Claude Code固有のフィールドを含む SKILL.md をそのままCodexやAntigravity用のプラグインにコピーしないこと。
  • マニフェスト、フック、MCPで絶対パスや .. を使用しないこと。
  • プラグインのルートに CLAUDE.md を配置しないこと。読み込みが必要な指示はスキルに含めること。