ki-copilot/05-mcp-skills-hooks-agents-plugins.md

Kapitel 5

MCP, Skills, Hooks, Agents und Plugins

Kern in einem Satz: Erweitere Copilot CLI nur so hart wie nötig – Instructions für Normen, Skills für Workflows, MCP für neue Fähigkeiten, Hooks zum Erzwingen, Agents für Spezialisierung, Plugins zum Bündeln.

Kapitel 4 hat die Leitplanken (Settings, Trust, Sandbox). Hier kommen die Erweiterungen: mehr Tools, wiederholbare Abläufe, Guardrails im Lebenszyklus, spezialisierte Personas und verteilbare Pakete. Parallelisierung mit /fleet gehört dazu – sie ist kein Autopilot-Ersatz, sondern ein Orchestrator-Muster.

Stand: Mitte/Ende 2026 · Primär: docs.github.com/en/copilot · Feature-Matrix intern: Comparing Copilot CLI customization features. Namen und Slash-Commands können driften – /help, /mcp, /skills, /agent.

---

5.1 Entscheidungsmatrix: Härtegrade

Du stehst vor der Frage: „Wohin schreibe ich das?“ Starte weich; werde nur härter, wenn weich nicht reicht.

Bedarf	Mittel	Härte
Immer gültige Normen, Stil, Repo-Konventionen	Custom Instructions	weich, session-weit geladen
Wiederholbarer Task on-demand	Skill (SKILL.md)	weich, just-in-time
Neue externe Fähigkeiten / Datenquellen	MCP-Server	Tools + Angriffsfläche
Erzwingen / Guardrail / Telemetrie	Hook	hart, Code im Lifecycle
Spezial-Persona, Tool-Subset, eigenes Kontextfenster	Custom Agent	Profil + Subagent
Bundle verteilen / installieren	Plugin	Paket aus dem oberen

Warum die Reihenfolge? Instructions und Skills steuern Verhalten über Text. MCP gibt dem Agenten neue Aktionen. Hooks laufen unabhängig vom Modellwillen. Agents bündeln Persona + oft engeres Toolset. Plugins sind Distribution, kein eigener „Intelligenz-Modus“.

Hebel am Gelenk (sparsam): Scope eng, Diff vor Merge, Deny vor YOLO, weich vs. hart bewusst trennen.

---

5.2 MCP – externe Tools andocken

Was und wann

MCP (Model Context Protocol) liefert dem Agenten zusätzliche Tools und Kontextquellen. Der GitHub MCP Server ist in Copilot CLI eingebaut – Issues, PRs und GitHub-Aktionen brauchen dafür oft keine Extra-Config. Weitere Server lohnen sich, wenn Built-ins nicht reichen (Browser-Automation, interne APIs, Doku-Indizes, …).

{width=90%}

Wo konfigurieren

Ort	Rolle
~/.copilot/mcp-config.json	User-weit, alle Sessions
.github/mcp.json	Repo, team-geteilt (nach Trust)
.mcp.json	Checkout-lokal; von CWD bis Git-Root gesucht

Bei Namenskonflikt: Projekt-Definitionen schlagen User; näher am CWD schlägt weiter oben. In untrusted Directories werden Project-MCP-Server still übersprungen. Prompt-Mode (copilot -p): Project-MCP nur wenn Directory bereits trusted (oder Env laut Doku, z. B. Workspace-MCP-Flag).

Beispiel User-Config (Platzhalter, nicht committen mit echten Secrets):

{
  "mcpServers": {
    "example-filesystem": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "/path/to/allowed/dir"],
      "env": {
        "EXAMPLE_TOKEN": "YOUR_TOKEN"
      }
    }
  }
}

Vorlage: vorlagen/mcp-config.beispiel.json.

Verwalten

Interaktiv:

/mcp
/mcp show
/mcp add
/mcp disable SERVER-NAME

Terminal: copilot mcp list, copilot mcp add …, copilot mcp remove ….

Registry-Suche (/mcp search) kann experimentell sein – ggf. --experimental / /experimental.

Allow / Deny und Angriffsfläche

MCP-Tools unterliegen denselben Permission-Regeln wie andere Tools:

copilot --allow-tool='My-MCP-Server' \
  --deny-tool='My-MCP-Server(dangerous_tool)'

Gespeicherte Approvals: permissions-config.json, kind: "mcp", serverName, toolName oder null für alle Tools des Servers (Kap. 4).

Achtung: Ein MCP-Server ist Code und oft Netzwerk. Installiere nur Quellen, denen du vertraust; begrenze Tools; halte Tokens in Env/Secret-Store, nicht im Repo. Org-Allowlists/Registry-Policies gelten auch für die CLI.

---

5.3 Skills – Workflows on demand

{width=90%}

Was und wann

Ein Skill ist ein Ordner mit SKILL.md (Pflichtname) und optional Scripts/Ressourcen. Copilot lädt ihn, wenn die description zur Aufgabe passt – oder wenn du ihn explizit mit /skillname im Prompt nennst. Ideal für „manchmal, aber dann immer gleich“: Verify, Release-Notes, Incident-Checkliste.

Nicht Skills: Dinge, die immer gelten → Instructions. Dinge, die erzwungen werden müssen → Hooks.

Orte

Scope	Pfade (Auswahl)
Projekt	.github/skills/, auch .agents/skills (+ Kompat-Pfade laut Doku)
User	~/.copilot/skills/, ggf. ~/.agents/skills

Ein Skill pro Unterordner, Name lowercase mit Bindestrichen:

.github/skills/verify/SKILL.md

Frontmatter und Body

---
name: verify
description: Run lint and unit tests for this repository. Use when asked to verify, check tests, or before commit.
---

# Verify

1. Lint ausführen, falls vorhanden.
2. Unit-Tests ausführen.
3. Fehler mit Datei:Zeile zusammenfassen.
4. Nicht committen/pushen, außer explizit verlangt.

Vorlage: vorlagen/skills/verify/SKILL.md.

Optional allowed-tools im Frontmatter (z. B. shell), damit freigegebene Tools ohne erneutes Fragen laufen.

Achtung: allowed-tools: shell (oder bash) nur, wenn du Skill und alle Scripts geprüft hast. Sonst bleibt die Bestätigung Pflicht – Prompt-Injection und fremde Skills sind reale Risiken.

Befehle

/skills list
/skills info verify
/skills reload

Terminal: copilot skill list, copilot skill add …. Skill im Prompt: Use the /verify skill before we commit.

---

5.4 Hooks – Lifecycle erzwingen

Was und wann

Hooks starten deine Shell-Kommandos an festen Punkten – unabhängig davon, ob das Modell „mitspielt“. Das ist der harte Gegenpol zu Instructions.

Event	Wann
sessionStart / sessionEnd	Session beginnt / endet
userPromptSubmitted	User-Prompt abgesendet
preToolUse / postToolUse	vor / nach Tool
errorOccurred	Fehler
agentStop	Hauptagent stoppt ohne Fehler

Weitere Events (z. B. Subagent-Stop) können hinzukommen – Hooks-Reference und aktuelle Doku prüfen.

Orte und Format

• Repo: .github/hooks/*.json (version 1)
• User: ~/.copilot/hooks/ (bzw. $COPILOT_HOME/hooks/)
• Inline: hooks-Key in User-settings.json

Änderungen werden beim CLI-Start geladen – nach Edits neu starten.

{
  "version": 1,
  "hooks": {
    "preToolUse": [
      {
        "type": "command",
        "bash": "bash .github/hooks/scripts/block-rm.sh",
        "powershell": "pwsh -File .github/hooks/scripts/block-rm.ps1",
        "cwd": ".",
        "timeoutSec": 10
      }
    ]
  }
}

bash und powershell angeben, wenn das Team gemischt arbeitet. Default-Timeout oft 30 s – bei Formattern erhöhen.

Vorlagen:

• vorlagen/hooks/guard-pretool.example.json
• vorlagen/hooks/format-posttool.example.json

disableAllHooks: true in Settings schaltet alle Hooks ab (Debug) – im Team sparsam und bewusst.

Wann nicht: reine Prompt-Normen (Instructions/Skills reichen). Hooks sind Betrieb und Policy; falsch gebaute Hooks blocken die Arbeit oder geben falsche Sicherheit.

---

5.5 Custom Agents und Built-ins

Was und wann

Ein Custom Agent ist ein Profil (Persona + Anweisungen + optional Tool-Subset / MCP). Die Arbeit läuft typischerweise in einem Subagent mit eigenem Kontextfenster – der Hauptagent bleibt schlank und orchestriert.

{width=90%}

Datei: *.agent.md (CLI-Konvention).

Scope	Pfad
Projekt	.github/agents/
User	~/.copilot/agents/

Org/Enterprise-Agenten (z. B. über .github / .github-private) sind Team-Thema (Kap. 6).

Nutzen

/agent

Explizit im Prompt: Use the security-reviewer agent on src/…
Programmatisch:

copilot --agent security-reviewer -p "Review auth handlers only"

Nach manueller Erstellung oft CLI neu starten, damit das Profil geladen wird. Namenskollisionen User vs. Project: in der laufenden Version mit /agent und Doku prüfen, welche Variante aktiv ist.

Vorlage: vorlagen/agents/security-reviewer.agent.md.

Subagent vs. Custom Agent

Begriff	Was es ist
Subagent	Ausführung: eigener Agent-Prozess mit eigenem Kontextfenster, den der Hauptagent spinnt
Custom Agent	Definition: Persona, Anweisungen, optional Tool-Subset, MCP, Auto-Delegation

Der Hauptagent kann Subagents auch ohne dein Custom-Profil starten (Built-ins). Dein *.agent.md steuert, wie ein Subagent denkt und welche Tools er darf.

Typisches Frontmatter (Felder und Defaults: Custom-Agents-Reference – driften kann):

---
name: security-reviewer
description: Security-focused review for auth and data paths.
# infer: true   # optional: Hauptagent darf automatisch delegieren, wenn die Task passt
# tools: …      # optional: eingeschränktes Toolset (read-only-Reviewer)
---

Setting (Konzept)	Wirkung
infer: true	Auto-Delegation, wenn die Aufgabe zur description passt – sparsam; unklare Descriptions triggern zu oft
infer: false / weggelassen	nur explizit (/agent, Prompt, --agent)
Tool-Subset	z. B. Reviewer ohne Write – härter als „bitte nur lesen“ in Instructions

Wann Custom Agent statt Skill? Wenn du Spezialisierung plus eigenes Kontextfenster und ggf. eingeschränkte Tools brauchst. Nur Text-Workflow → Skill reicht.

Built-in Agents (Überblick)

Die CLI bringt spezialisierte Built-ins mit, die der Hauptagent als Subagents einsetzen kann. Konzeptnamen und Auto-Trigger driften – die Tabelle ist Orientierung, keine Spezifikation. Aktuelle Labels und Verfügbarkeit: /agent, ? / /help und die Doku About custom agents / Comparing CLI features (Stand Mitte/Ende 2026).

Agent (Konzept)	Rolle kurz
Explore	schnelle, read-only Codebase-Erkundung
Task	Commands (Test/Build/Lint) ausführen, Ergebnis verdichten
General purpose	volle Fähigkeiten, separates Kontextfenster
Code review	high-signal Review (Bugs/Security); oft über /review (Kap. 3)
Research	tiefgehende Recherche; typisch über /research (nächster Abschnitt)
Rubber duck	konstruktive Gegenmeinung zu Plänen/Code (zweites Modell)

Built-ins erscheinen nicht unbedingt in der gleichen Liste wie deine Custom Agents unter /agent.

/research – tiefe Recherche, kein Code-Edit

/research What is the architecture of this codebase?
/research How is persistence implemented in todo/store.py?

/research aktiviert den Research-Agent: Codebase, zugängliche GitHub-Repos und Web – Ergebnis ist ein Markdown-Report mit Zitationen plus Kurzsummary in der CLI. Das ist absichtlich depth over speed: viele Tool-Calls, oft längere Laufzeit und Credits.

Nutze /research	Nutze normalen Prompt / Explore
Architektur, Org-Patterns, Tech-Vergleich	„Was macht diese Funktion?“
sharebarer Report als Artefakt	schnelle Antwort im Flow
How-to / Deep-Dive mit Citations	Code ändern, Tests fixen

Grenzen (laut Docs): Research ändert keinen Produktcode (Report speichern ja, Feature-Implementierung nein). Modell des Research-Agents ist oft fest verdrahtet – /model der Hauptsession gilt dort nicht. Reports hängen an der Session (session-state/…/research/); teilen z. B. mit /share gist research oder /share file research. Report anzeigen: Link nach Abschluss oder Shortcut laut Doku (häufig Ctrl+Y – Env COPILOT_EDITOR / VISUAL / EDITOR).

---

5.6 /fleet – parallel, aber nicht blind

Idee

/fleet zerlegt eine geeignete Anfrage in Teilaufgaben und lässt Subagents parallel arbeiten; der Hauptagent orchestriert Abhängigkeiten.

{width=90%}

Wann sinnvoll

• Unabhängige Arbeit: viele Dateien refaktorieren, Test-Suiten pro Modul, parallele Analysen
• Großer Plan mit klar trennbaren Strängen
• Oft kombiniert mit Plan-Freigabe und Autopilot – aber: Fleet ≠ Autopilot

Feature	Fokus
Autopilot	autonom weiterarbeiten, weniger Rückfragen
/fleet	Parallelisierung über Subagents

Credits: mehr Subagents ⇒ mehr Modell-Interaktionen ⇒ oft mehr AI Credits. Sequentielle Arbeit parallel zu erzwingen spart keine Zeit und kostet mehr.

Typischer Flow:

1. Plan Mode (Shift+Tab / /plan)
2. Plan prüfen
3. Optionen wie „Accept plan and build on autopilot + /fleet“, wenn angeboten und der Plan parallelisierbar ist

Custom Agents können in Teilaufgaben landen; in Prompts gezielt @agent-name bzw. laut Doku spezifizieren.

---

5.7 Plugins und Marketplaces

Plugins bündeln Skills, Hooks, Agents, MCP-Configs (Kombinationen). Installation und Updates über Plugin-Kommandos der CLI (interaktiv und copilot plugin … – exakte Subcommands: Command Reference).

Installierte Dateien liegen unter ~/.copilot/installed-plugins/ (Marketplace-Name/Plugin bzw. _direct/). Metadaten in der verwalteten config.json – deinstallieren über die CLI, nicht nur Ordner löschen.

Achtung: Vor Trust Inhalt prüfen (Scripts, Hooks, MCP-Commands, allowed-tools). Ein Plugin ist Remote-Code in deinem Harness. Team-Policy und bekannte Marketplaces bevorzugen; experimentelle Quellen isoliert testen.

Settings-Keys wie enabledPlugins und extraKnownMarketplaces steuern Auto-Install und zusätzliche Quellen – nur Keys setzen, die copilot help config kennt.

Eigenes Plugin (Team-Pfad)

Wenn mehrere Customizations als Paket reisen sollen (Onboarding, Incident-Skill + Reviewer-Agent + internes MCP):

1. Plugin-Struktur laut How-to Creating a plugin for GitHub Copilot CLI anlegen (Manifest + gebündelte Skills/Agents/Hooks/MCP).
2. Lokal installieren/testen (copilot plugin … – Subcommands: Command Reference).
3. Inhalt reviewen wie Dependencies: Scripts, Hooks, erlaubte Tools.
4. Optional: Team-Marketplace (Creating a plugin marketplace) für Install/Update statt manueller Ordnerkopien.

Minimales Skeleton im Buch: vorlagen/plugins/team-baseline/ (nur Verify). Fleet als Session-Rezept: beispiele/rezepte/05-fleet-skizze.md.

Für ein einzelnes Skill oder einen Agenten im Repo reicht oft kein Plugin – erst bündeln, wenn Distribution und Versionierung wehtun. Marketplace betreiben ist Admin-Thema; die meisten Teams konsumieren nur.

---

So baust du das nach

1. Matrix anwenden: eine Team-Norm → Instruction; Verify-Ablauf → Skill; „nie rm -rf ohne Guard“ → Hook; Security-Persona → Agent.
2. Verify-Skill nach vorlagen/skills/verify/ nach .github/skills/verify/ kopieren; /skills reload; Use /verify.
3. Guard-Hook aus vorlagen/hooks/ anpassen, Scripts ausführbar machen, CLI neu starten, riskanten Befehl provozieren.
4. Security-Reviewer aus vorlagen/agents/ nach .github/agents/ legen, Session neu, copilot --agent security-reviewer -p "…".
5. Optional ein MCP nur mit engem Pfad/Token; /mcp show; Deny für unnötige Tools.
6. Fleet nur an einer Aufgabe mit unabhängigen Teilschritten testen; Credits mit /usage im Blick behalten.
7. Optional: /research auf eine Architekturfrage – Report lesen, nicht als Implementierungs-Auftrag missbrauchen.

Checkliste

• Weiß ich, warum ich dieses Mittel und nicht das weichere gewählt habe?
• Sind MCP- und Plugin-Quellen vertrauenswürdig?
• Haben Skills kein unnötiges allowed-tools: shell?
• Laden Hooks nach Restart? JSON version: 1?
• Ist der Agent-Scope eng (Pfade, nur Review vs. Rewrite)?

Häufige Fehler

Symptom	Typische Ursache
Skill wird nie genutzt	schwache description; nicht /skills reload
Hook feuert nicht	Dateiort, JSON, Start ohne Reload, disableAllHooks
MCP fehlt im Prompt-Mode	Directory untrusted
Fleet „bringt nichts“	stark sequentielle Aufgabe
Agent ändert zu viel	fehlende Scope-Anweisung im Profil

---

Jetzt selbst machen

1. Schreibe in einem Satz: „Für unser Repo ist X Instruction, Y Skill, Z Hook.“
2. Installiere den Verify-Skill im Mini-Projekt beispiele/todo-cli/ (oder deinem Repo) und rufe ihn vor einem Commit auf.
3. Aktiviere einen preToolUse-Guard gegen ein bewusstes Anti-Pattern deines Stacks.
4. Lass den Security-Reviewer nur über eine Datei laufen – Diff lesen, nicht blind mergen.

---

Was du jetzt kannst

• Customization-Härtegrade unterscheiden und die passende Schicht wählen.
• MCP konfigurieren, listen und per Allow/Deny begrenzen.
• Skills mit Frontmatter anlegen, reloaden und gezielt aufrufen.
• Hooks version 1 für Guardrails und Format am Lifecycle hängen.
• Custom Agents vs. Subagents, infer und Tool-Subset einordnen.
• /research vs. Explore unterscheiden und Reports teilen.
• /fleet für parallele, unabhängige Arbeit nutzen und Credits mitdenken.
• Plugins installieren, vor Trust prüfen und optional als Team-Paket bauen.

Nächste Schritte

Kapitel 6 zieht die Fäden in Teams, Enterprise und CI: gemeinsame Baseline, MDM, programmatic copilot -p, Token-Regeln und Cloud-Agent mit menschlichem Merge. Kapitel 7 vertieft Context, Sessions und Troubleshooting, wenn Skills, Hooks oder Permissions „nicht greifen“.

Vorlagen dieses Kapitels:

• vorlagen/mcp-config.beispiel.json
• vorlagen/skills/verify/SKILL.md
• vorlagen/hooks/guard-pretool.example.json
• vorlagen/hooks/format-posttool.example.json
• vorlagen/agents/security-reviewer.agent.md
• vorlagen/plugins/team-baseline/