Der Spickzettel zum Seminar GitHub Copilot CLI Praxis — für alle, die agentisch im Terminal arbeiten und den einen Befehl suchen, der gerade fehlt. Maßgeblich ist die Originaldoku unter docs.github.com/copilot; Modellnamen und Befehlsbestand ändern sich dort schneller, als ein Blatt folgen kann. Was bleibt, sind die Entscheidungen: welcher Modus, wie viel Rechte, was in den Kontext gehört.
Installation und Anmeldung
npm install -g @github/copilot # Node 22 oder neuer
brew install --cask copilot-cli # Alternative: Homebrew
cd ~/projekte/mein-projekt # immer im Projekt starten
copilot # interaktiv
Die Anmeldung läuft über /login in der laufenden Sitzung (Gerätecode im
Browser, bei Organisationen zusätzlich SSO bestätigen). Für Skripte und CI
stattdessen COPILOT_GITHUB_TOKEN setzen — nicht über die Shell-History.
Ohne aktives Copilot-Abo startet die CLI nicht, und jede Antwort kostet AI-Credits.
Modul: Einstieg & Setup
Die vier Interaktionsmodi
| Modus | Wofür er gedacht ist |
|---|---|
| Standard | Der Alltag: fragen, antworten, nachfassen |
| Plan | Neue Features und Greenfield — erst Plan, dann Code |
| Programmatic | Einzelne Antwort für Skripte und CI, ohne Sitzung |
| Autopilot | Ein fertiger Plan läuft ohne Zwischenfragen durch |
Shift+Tab wechselt im laufenden Betrieb zwischen Standard, Plan und
Autopilot; die Statuszeile zeigt den aktiven Modus.
# Programmatic: eine Antwort, keine Sitzung
copilot -p "Schreibe eine Commit-Nachricht für die
nicht eingecheckten Änderungen." > nachricht.txt
# Autopilot mit Leitplanken
copilot --autopilot --yolo \
--max-autopilot-continues 10 \
-p "Setze plan.md vollständig um."
--yolo (alias --allow-all) erteilt alle Rechte. Das Schrittlimit ist kein
Zubehör: Ohne es verbrennt ein Irrlauf still das Kontingent, und geprüft wird
am Ende über git diff, nicht über die Zusammenfassung des Agenten.
Modul: Interaktionsmodi & Befehle
Slash-Befehle im Alltag
| Befehl | Wirkung |
|---|---|
/help | Vollständige Liste der Befehle und Tastenkürzel |
/login | Anmeldung starten oder wechseln |
/model | Modell der laufenden Sitzung wechseln |
/plan | In den Plan-Modus wechseln, ohne Shift+Tab |
/context | Auslastung des Kontextfensters anzeigen |
/compact | Verlauf zusammenfassen und Platz schaffen |
/new · /clear | Neue Unterhaltung beginnen |
/exit | Sitzung sauber beenden |
Mit ! läuft ein Shell-Befehl, ohne die Sitzung zu verlassen. Die Modellliste
ändert sich laufend — /model fragen statt Namen aus Tutorials übernehmen.
Modul: Interaktionsmodi & Befehle
Kontextfenster und Referenzen
| Bestandteil | Anmerkung |
|---|---|
| Systemanweisungen | Von der CLI gesetzt, nicht verhandelbar |
| Eigene Anweisungen | Aus den Instructions-Dateien des Projekts |
| Werkzeugdefinitionen | Auch MCP-Server belegen hier Platz |
| Verlauf | Deine Prompts und die Antworten |
| Referenzen | Alles, was @ und # hereingeholt haben |
| Reserve | Puffer, damit das Fenster nicht überläuft |
/context zeigt diese Aufteilung samt Auslastung in Prozent.
> Wie robust ist @stations-api.js gegenüber
Zeitüberschreitungen?
> Prüfe @tests auf Lücken bei der Filterlogik.
> Setze #142 um und halte dich an den Diff.
@ nimmt Dateien und Ordner (auch absolute Pfade), # holt Issues herein.
Ohne Referenz sucht der Agent selbst — das kostet Werkzeugaufrufe und Zeit.
Modul: Arbeiten mit Kontext
Sessions fortsetzen und verdichten
| Befehl | Wirkung |
|---|---|
/compact | Verlauf zusammenfassen, Platz zurückgewinnen |
/session checkpoints | Gespeicherte Verdichtungen ansehen |
/resume | Frühere Session aus einer Liste auswählen |
copilot --continue | Zuletzt geschlossene Session sofort fortsetzen |
Verdichtung läuft auch automatisch — /compact ist der Handbetrieb. Nach
mehreren Verdichtungen fehlen Details; dann ist /new ehrlicher als
Weiterreden.
Modul: Arbeiten mit Kontext
Eingebaute Agenten
| Agent | Wofür |
|---|---|
/plan | Implementierungsplan vor der ersten Codezeile |
/review | Code-Review der Änderungen oder des Projekts |
/rubber-duck | Unabhängige Zweitmeinung aus mehreren Modellen |
/research | Recherche zu einem Thema statt Änderungen am Code |
/agent | Liste aller Agenten samt Herkunft und Status |
Modul: Agenten & Skills
Agent oder Skill?
| Merkmal | Unterschied |
|---|---|
| Rolle | Agent: du wechselst hinein · Skill: bleibt im Hintergrund |
| Auslösung | Agent: bewusst · Skill: auch automatisch über die Beschreibung |
| Umfang | Agent: Haltung und Werkzeuge · Skill: Ablauf für eine Aufgabe |
| Ablage | .agent.md als Datei · Skill als Ordner mit SKILL.md |
| Kontext | Agent: eigener Kontext · Skill: nur Name und Beschreibung vorab |
Beides schließt sich nicht aus — ein Agent darf Skills nutzen. Ablageorte:
Agenten projektweit unter .github/agents/, persönlich unter
~/.copilot/agents/; Skills entsprechend unter .github/skills/ bzw.
~/.copilot/skills/.
---
name: a11y-reviewer
description: Prüft UI-Code auf Barrierefreiheit.
tools: [read, search]
---
Du bist Spezialist für barrierearme Oberflächen.
Prüfe Kontraste, Fokusreihenfolge und Labels.
Melde Funde nach Schweregrad, ohne Code zu ändern.
Die description ist die Fundstelle, nicht Deko: Sie entscheidet, ob ein Skill
automatisch geladen wird. Ohne tools-Angabe darf der Spezialist alles, was
die Sitzung darf.
Modul: Agenten & Skills
MCP-Server verwalten
| Befehl | Wirkung |
|---|---|
/mcp show | Alle Server mit Status auflisten |
/mcp show <name> | Status und Werkzeuge eines Servers |
/mcp add | Server über ein Formular hinzufügen |
/mcp edit <name> | Konfiguration ändern |
/mcp disable <name> | Vorübergehend abschalten, nicht löschen |
/mcp delete <name> | Server entfernen |
copilot mcp list | Bestand ohne Sitzung anzeigen |
copilot mcp get <name> | Typ, Status und Werkzeuge ausgeben |
/mcp search durchsucht die GitHub-MCP-Registry (experimentell), und
copilot mcp add <name> -- <befehl> geht ganz ohne Sitzung.
{
"mcpServers": {
"ladenetz": {
"type": "local",
"command": "npx",
"args": ["-y", "@firma/ladenetz-mcp"],
"tools": ["stationen_suchen", "belegung_lesen"]
}
}
}
"tools": ["*"] gibt alles frei — eine Liste ist die schärfere Wahl. Liegt
derselbe Server in Benutzer- und Projektdatei, gewinnt die Projektfassung
still. Im Prompt den Server ausdrücklich nennen, sonst bleibt unklar, woher
eine Antwort stammt; in der Ausgabe steht, welches Werkzeug wirklich lief.
Modul: Externe Datenquellen mit MCP
Typische Fallen
- Copilot außerhalb des Projektordners starten — dann fehlt der Kontext, den man eigentlich meint.
- Node älter als 22: die npm-Installation bricht ab oder startet nicht.
- Ohne Organisationsfreigabe (SSO) bleibt der Zugriff trotz Login verwehrt.
- Das teuerste Modell für einfache Aufgaben —
autonimmt das günstigste passende. - Berechtigungsdialoge wegklicken: „Nicht mehr fragen” wirkt über den Moment hinaus.
--yoloin fremden Repos ist kein Komfort, sondern ein Risiko.- Autopilot ohne Erfolgskriterium und Schrittlimit läuft am Ziel vorbei und verbrennt still Credits.
- Im programmatischen Modus nachfassen wollen — Rückfragen werden nicht gestellt, sondern abgelehnt.
- Einen ganzen Ordner referenzieren, ohne hineingesehen zu haben.
- Alles in einer Session erledigen — der Verlauf wächst und trübt die Antworten.
- Jeder aktive MCP-Server belegt Kontext, bevor die erste Frage gestellt ist; ungenutzte abschalten.
- Zugangsdaten in die Projektdatei schreiben statt in Variablen.
- Von der CLI erzeugte Skills ungeprüft übernehmen — sie beschreiben Wunschzustände.
Module: Einstieg & Setup · Interaktionsmodi & Befehle · Arbeiten mit Kontext · Agenten & Skills · Externe Datenquellen mit MCP
Dieses Thema als Schulung für Ihr Team
Dieser Beitrag erklärt das Thema. Damit Ihr Team es danach auch anwendet, gibt es GitHub Copilot CLI Praxis als Schulung — an Ihrem eigenen Code, mit den Fragen, die ein Text nicht beantwortet. Sie wählen die Module, wir bauen daraus ein Programm.
2 Tage·ab 900 EUR netto pro Tag (bis 3 Teilnehmende) ·Termin nach Vereinbarung
Als Team-Schulung anfragenZum Seminar GitHub Copilot CLI Praxis →