GitHub Copilot CLI-Plug-In-Referenz

Eine Übersicht darüber, was Plug-Ins sind und wie sie über Copilot Clients hinweg funktionieren, finden Sie unter Informationen zu GitHub Copilot Plug-Ins.

CLI-Befehle

Sie können die folgenden Befehle im Terminal verwenden, um Plug-Ins für Copilot CLI zu verwalten. copilot plugin und copilot plugins sind austauschbar – verwenden Sie die Variante, die sich für den Unterbefehl besser liest.

Im nicht interaktiven Modus bieten copilot plugins enable NAME --plugin, copilot plugins disable NAME --plugin und copilot plugins remove NAME --plugin dieselben Vorgänge zum Aktivieren, Deaktivieren und Deinstallieren. --plugin ist der Standardtyp und kann für diese drei Befehle weggelassen werden. Siehe GitHub Copilot CLI-Befehlsreferenz zu den nicht interaktiven Typen --mcp und --skill, die diese Befehle auf MCP-Server und Skills ausweiten.

Plug-In-Spezifikation für install Befehl

copilot plugins install-Optionen

Neben der Installation eines Plugins aus einer Spezifikation kann copilot plugins install mit --skill eine einzelne Fertigkeit aus einer Datei, URL oder einem Verzeichnis installieren. Eine Qualifikationsinstallation ist keine Plug-In-Installation und geht nicht durch einen Marketplace – Details zu Fähigkeiten selbst finden Sie unter GitHub Copilot CLI-Befehlsreferenz .

Durch die Installation eines Verzeichnisses wird es als benutzerdefinierte Qualifikationsquelle registriert, anstatt es zu kopieren; Durch die Installation einer Datei oder URL werden die Inhalte des Qualifikationsinhalts in Ihr persönliches Oder Projektfähigkeitsverzeichnis kopiert.

MCP-Server werden aus einer per Richtlinie konfigurierten Registry installiert, die Authentifizierung und die interaktive Eingabe von Geheimnissen erfordert. Verwenden Sie das /plugins Dashboard (Online-Modus) oder den /mcp Slash-Befehl, um MCP-Server statt copilot plugins install hinzuzufügen.

copilot plugins update-Optionen

copilot plugins marketplace Unterbefehle

Integrierte Standard-Marketplaces werden mit der Laufzeit ausgeliefert und können nicht entfernt werden.

plugin.json

Alle Plug-Ins bestehen aus einem Plug-In-Verzeichnis, das mindestens eine Manifestdatei mit dem Namen plugin.json enthält, die sich im Stammverzeichnis des Plug-In-Verzeichnisses befindet. Siehe Erstellen eines Plug-Ins für GitHub Copilot-CLI.

Pflichtfeld

Optionale Metadatenfelder

Komponentenpfadfelder

Diese teilen der CLI mit, wo sie die Komponenten Ihres Plug-Ins finden. Alle sind optional. Die CLI verwendet Standardkonventionen, wenn sie weggelassen werden.

Beispieldatei für plugin.json

{
  "name": "my-dev-tools",
  "description": "React development utilities",
  "version": "1.2.0",
  "author": {
    "name": "Jane Doe",
    "email": "jane@example.com"
  },
  "license": "MIT",
  "keywords": ["react", "frontend"],
  "agents": "agents/",
  "skills": ["skills/", "extra-skills/"],
  "hooks": "hooks.json",
  "mcpServers": ".mcp.json"
}

{
  "name": "my-dev-tools",
  "description": "React development utilities",
  "version": "1.2.0",
  "author": {
    "name": "Jane Doe",
    "email": "jane@example.com"
  },
  "license": "MIT",
  "keywords": ["react", "frontend"],
  "agents": "agents/",
  "skills": ["skills/", "extra-skills/"],
  "hooks": "hooks.json",
  "mcpServers": ".mcp.json"
}

LSP-Serverkonfiguration

Um LSP-Server (Language Server Protocol) in ein Plugin einzubinden, erstellen Sie eine lsp-config/servers.json-Datei im Plugin-Verzeichnis oder geben Sie über das Feld lspServers in plugin.json einen Pfad oder ein Inline-Objekt an.

Beispiel lsp-config/servers.json (oder inline über lspServers in plugin.json):

{
    "lspServers": {
        "my-lsp": {
            "command": "my-language-server",
            "fileExtensions": { ".myext": "mylang" }
        }
    }
}

Für plattformübergreifende Unterstützung verwenden Sie bash und powershell anstelle von command:

{
    "lspServers": {
        "my-lsp": {
            "bash": "${PLUGIN_ROOT}/scripts/start-lsp.sh",
            "powershell": "${PLUGIN_ROOT}/scripts/start-lsp.ps1",
            "fileExtensions": { ".myext": "mylang" }
        }
    }
}

(*) Mindestens einer von command, bashoder powershell ist erforderlich. Wenn sowohl bash als auch powershell angegeben werden, wird die plattformgerechte Option automatisch ausgewählt (PowerShell auf Windows, Bash an anderer Stelle).

Verwenden Sie ${PLUGIN_ROOT}, um auf Pfade innerhalb des Plugin-Verzeichnisses zu verweisen.

marketplace.json

Sie können einen Plug-In-Marketplace erstellen , mit dem Benutzer Ihre Plug-Ins entdecken und installieren können, indem Sie eine marketplace.json Datei erstellen und im .github/plugin/ Verzeichnis des Repositorys speichern. Sie können die marketplace.json Datei auch in Ihrem lokalen Dateisystem speichern. Speichern Sie die Datei beispielsweise als /PATH/TO/my-marketplace/.github/plugin/marketplace.json, um sie mit dem folgenden Befehl zur CLI hinzuzufügen:

copilot plugin marketplace add /PATH/TO/my-marketplace

Weitere Informationen findest du unter Erstellen eines Plugin-Marketplace für GitHub Copilot-CLI.

Beispieldatei für marketplace.json

{
  "name": "my-marketplace",
  "owner": {
    "name": "Your Organization",
    "email": "plugins@example.com"
  },
  "metadata": {
    "description": "Curated plugins for our team",
    "version": "1.0.0"
  },
  "plugins": [
    {
      "name": "frontend-design",
      "description": "Create a professional-looking GUI ...",
      "version": "2.1.0",
      "source": "./plugins/frontend-design"
    },
    {
      "name": "security-checks",
      "description": "Check for potential security vulnerabilities ...",
      "version": "1.3.0",
      "source": "./plugins/security-checks"
    }
  ]
}

{
  "name": "my-marketplace",
  "owner": {
    "name": "Your Organization",
    "email": "plugins@example.com"
  },
  "metadata": {
    "description": "Curated plugins for our team",
    "version": "1.0.0"
  },
  "plugins": [
    {
      "name": "frontend-design",
      "description": "Create a professional-looking GUI ...",
      "version": "2.1.0",
      "source": "./plugins/frontend-design"
    },
    {
      "name": "security-checks",
      "description": "Check for potential security vulnerabilities ...",
      "version": "1.3.0",
      "source": "./plugins/security-checks"
    }
  ]
}

marketplace.json Felder

Felder auf oberster Ebene

Plug-In-Eintragsfelder (Objekte innerhalb des plugins Arrays)

Plug-In-Quelltypen

Das source Feld eines Plug-In-Eintrags akzeptiert eine relative Pfadzeichenfolge oder ein Objekt, das ein Repository oder eine GitHub Git-URL-Quelle beschreibt:

{
    "source": {
        "source": "github",
        "repo": "owner/repo",
        "ref": "v1.0.0",
        "path": "plugins/my-plugin"
    }
}

Sowohl die Quelltypen github als auch url akzeptieren ein optionales Feld sha, um Installationen zusätzlich zu ref (oder anstelle davon) an einen exakten Commit anzuheften:

{
    "source": {
        "source": "github",
        "repo": "owner/repo",
        "sha": "a94a8fe5ccb19ba61c4c0873d391e987982fbbd3",
        "path": "plugins/my-plugin"
    }
}

sha muss ein vollständiger Commit-SHA mit 40 Zeichen sein. Pinnen Sie auf sha, um reproduzierbare Installationen zu gewährleisten, die gegen Force-Pushes oder Verschiebungen von Tags/Branches immun sind.

Dateispeicherorte

Ladereihenfolge und Priorität

Wenn Sie mehrere Plug-Ins installieren, ist es möglich, dass einige benutzerdefinierte Agents, Fähigkeiten, MCP-Server oder Tools, die über MCP-Server bereitgestellt werden, doppelte Namen haben. In diesem Fall bestimmt die CLI, welche Komponente basierend auf einer Rangfolge verwendet werden soll.

• Agenten und Skills nutzen das Prinzip 'Wer zuerst kommt, mahlt zuerst'.

  Wenn Sie über einen benutzerdefinierten Agent auf Projektebene oder eine Fähigkeit mit demselben Namen oder derselben ID wie eines in einem Plug-In verfügen, das Sie installieren, wird der Agent oder die Fähigkeit im Plug-In im Hintergrund ignoriert. Das Plug-In kann keine Konfigurationen auf Projektebene oder persönliche Konfigurationen außer Kraft setzen. Benutzerdefinierte Agents werden mit ihrer ID dedupliziert, die von ihrem Dateinamen abgeleitet wird (z. B. wenn die Datei benannt reviewer.agent.mdist, die Agent-ID ist reviewer). Fähigkeiten werden durch ihr Namensfeld innerhalb der SKILL.md-Datei dedupliziert.

• MCP-Server verwenden das Last-Wins-Prinzip.

  Wenn Sie ein Plug-In installieren, das einen MCP-Server mit demselben Servernamen wie einen bereits installierten MCP-Server definiert, hat die Definition des Plug-Ins Vorrang. Sie können die --additional-mcp-config Befehlszeilenoption verwenden, um eine MCP-Serverkonfiguration mit demselben Namen außer Kraft zu setzen, die mit einem Plug-In installiert wird. Wenn zwei oder mehr Plug-Ins einen MCP-Server mit demselben Namen deklarieren, verwendet die CLI die Version des Plug-Ins, das zuletzt geladen wurde, und zeigt eine Warnung an, die jedes vorherige Plug-In benennt, das es definiert hat.

• Integrierte Tools und Agents sind immer vorhanden und können nicht von benutzerdefinierten Komponenten außer Kraft gesetzt werden.

Das folgende Diagramm veranschaulicht die Ladereihenfolge und Rangfolgeregeln.

┌──────────────────────────────────────────────────────────────────┐
│  BUILT-IN - HARDCODED, ALWAYS PRESENT                            │
│  • tools: bash, view, apply_patch, glob, rg, task, ...           │
│  • agents: explore, task, code-review, general-purpose, research │
└────────────────────────┬─────────────────────────────────────────┘
                         │
  ┌──────────────────────▼──────────────────────────────────────────────┐
  │  CUSTOM AGENTS - FIRST LOADED IS USED (dedup by ID)                 │
  │  1. ~/.copilot/agents/           (user, .github convention)         │
  │  2. <project>/.github/agents/    (project)                          │
  │  3. <parents>/.github/agents/    (inherited, monorepo)              │
  │  4. <project>/.claude/agents/    (project)                          │
  │  5. <parents>/.claude/agents/    (inherited, monorepo)              │
  │  6. PLUGIN: agents/ dirs         (plugin, by install order)         │
  │  7. Remote org/enterprise agents (remote, via API)                  │
  └──────────────────────┬──────────────────────────────────────────────┘
                         │
  ┌──────────────────────▼──────────────────────────────────────────────┐
  │  AGENT SKILLS - FIRST LOADED IS USED (dedup by name)                │
  │  1. <project>/.github/skills/        (project)                      │
  │  2. <project>/.agents/skills/        (project)                      │
  │  3. <project>/.claude/skills/        (project)                      │
  │  4. <parents>/.github/skills/ etc.   (inherited)                    │
  │  5. ~/.copilot/skills/               (personal-copilot)             │
  │  6. ~/.agents/skills/                (personal-agents)              │
  │  7. PLUGIN: skills/ dirs             (plugin)                       │
  │  8. COPILOT_SKILLS_DIRS env + config (custom)                       │
  │  --- then commands (.claude/commands/), skills override commands ---│
  └──────────────────────┬──────────────────────────────────────────────┘
                         │
  ┌──────────────────────▼──────────────────────────────────────────────┐
  │  MCP SERVERS - LAST LOADED IS USED (dedup by server name)           │
  │  1. ~/.copilot/mcp-config.json       (lowest priority)              │
  │  2. PLUGIN: MCP configs              (plugins)                      │
  │  3. --additional-mcp-config flag     (highest priority)             │
  └─────────────────────────────────────────────────────────────────────┘

Weiterführende Lektüre

• Informationen zu unternehmensverwalteten Plug-In-Standards
• GitHub Copilot-CLI
• GitHub Copilot CLI-Befehlsreferenz
• Programmgesteuerte Referenz für die GitHub Copilot-CLI