Zuverlässiger AI-Workflow mit GitHub Copilot: Ein vollständiger Leitfaden mit Beispielen

Hallo! Heute teile ich eine kurze Anleitung zum Einrichten eines Projekts für die Arbeit mit GitHub Copilot.

Zuverlässiger AI-Workflow mit GitHub Copilot: Ein vollständiger Leitfaden mit Beispielen

Diese Anleitung zeigt, wie Sie mit Agenten-Primitiven und Kontext-Engineering vorhersagbare und reproduzierbare KI-Prozesse (Workflows) in Ihrem Repository und Ihrer IDE/CLI erstellen. Hier finden Sie Dateistrukturen, fertige Vorlagen, Sicherheitsregeln und Befehle.

⚠️ Hinweis: Die Funktionalität von Prompt-Dateien und dem Agentenmodus in IDE/CLI kann sich ändern – passen Sie die Anleitung an die spezifischen Versionen von Copilot und VS Code an, die Sie verwenden.

1) Überblick: Was macht einen Workflow aus?

Das Hauptziel ist es, die Arbeit eines Agenten in transparente und kontrollierbare Schritte zu zerlegen. Dafür gibt es folgende Werkzeuge:

• Custom Instructions (.github/copilot-instructions.md) – Globale Projektregeln (wie man baut, testet, Code-Stil, PR-Richtlinien).
• Path-specific Instructions (.github/instructions/*.instructions.md) – Regeln für bestimmte Bereiche, angewendet über applyTo (Glob-Muster).
• Chat Modes (.github/chatmodes/*.chatmode.md) – Spezialisierte Chat-Modi (z. B. Plan/Frontend/DBA) mit festen Werkzeugen und Modellen.
• Prompt Files (.github/prompts/*.prompt.md) – Wiederverwendbare Szenarien/„Programme“ für typische Aufgaben (Review, Refactoring, Generierung).
• Context helpers (docs/*.spec.md, docs/*.context.md, docs/*.memory.md) – Spezifikationen, Referenzen und Projektspeicher für präzisen Kontext.
• MCP servers (.vscode/mcp.json oder über UI) – Werkzeuge und externe Ressourcen, die der Agent nutzen kann.

2) Projektdateistruktur

Die folgende Struktur entspricht den oben beschriebenen Werkzeugen und hilft beim Aufbau eines vollständigen Workflows für Agenten.

1.github/
2  copilot-instructions.md
3  instructions/
4    backend.instructions.md
5    frontend.instructions.md
6    actions.instructions.md
7  prompts/
8    implement-from-spec.prompt.md
9    security-review.prompt.md
10    refactor-slice.prompt.md
11    test-gen.prompt.md
12  chatmodes/
13    plan.chatmode.md
14    frontend.chatmode.md
15.vscode/
16  mcp.json
17docs/
18  feature.spec.md
19  project.context.md
20  project.memory.md

3) Dateien und ihre Zwecke – Technische Erklärung

Nun betrachten wir jedes Werkzeug einzeln und seine Rolle. Unten wird erklärt, wie all das hinter den Kulissen funktioniert: was diese Dateien sind, warum sie existieren, wie sie das Aufgabenverständnis des Agenten beeinflussen und in welcher Reihenfolge sie kombiniert / überschrieben werden. Die folgenden Code-Beispiele entsprechen der Spezifikation.

Reihenfolge der Regel- und Konfigurationszusammenführung: Prompt Frontmatter → Chat-Modus → Repo/Pfad-Anweisungen → Standardwerte.

Und nun betrachten wir jedes Werkzeug einzeln.

3.1. Globale Regeln – .github/copilot-instructions.md

Was es ist: Eine Markdown-Datei mit kurzen, überprüfbaren Regeln: wie man baut, testet, Code-Stil und PR-Richtlinien.

Warum: Damit alle Antworten auf einem einheitlichen Standard basieren (ohne Duplizierung in jedem Prompt).

Wie es funktioniert: Die Datei wird automatisch Teil des Systemkontextes für alle Anfragen innerhalb des Repositorys. Es gibt kein applyTo (dazu weiter unten) – es wird überall angewendet.

Minimalbeispiel:

1# Repository coding standards
2- Build: `npm ci && npm run build`
3- Tests: `npm run test` (coverage ≥ 80%)
4- Lint/Typecheck: `npm run lint && npm run typecheck`
5- Commits: Conventional Commits; keep PRs small and focused
6- Docs: update `CHANGELOG.md` in every release PR

Tipps.

1. Halten Sie die Punkte kurz.
2. Vermeiden Sie allgemeine Phrasen.
3. Fügen Sie nur hinzu, was das Ergebnis beeinflussen kann (Build/Test/Lint/Typ/PR-Richtlinie).

3.2. Pfad-spezifische Anweisungen – .github/instructions/*.instructions.md

Was es ist: Modulare Regeln mit YAML-Frontmatter applyTo – Glob-Muster von Dateien, für die sie gelten.

Warum: Zur Differenzierung von Standards in verschiedenen Bereichen (Frontend/Backend/CI). Ermöglicht die Kontrolle des Kontexts je nach Aufgabentyp.

Wie es funktioniert: Bei der Verarbeitung einer Aufgabe findet Copilot alle *.instructions.md, deren applyTo mit dem aktuellen Kontext (Dateien, die Sie diskutieren/bearbeiten) übereinstimmt. Passende Regeln werden zu den globalen hinzugefügt.

Beispiel:

1---
2applyTo: "apps/web/**/*.{ts,tsx},packages/ui/**/*.{ts,tsx}"
3---
4- React: function components and hooks
5- State: Zustand; data fetching with TanStack Query
6- Styling: Tailwind CSS; avoid inline styles except dynamic cases
7- Testing: Vitest + Testing Library; avoid unstable snapshots

Hinweis.

1. Vermeiden Sie die Duplizierung bereits vorhandener globaler Regeln.
2. Stellen Sie sicher, dass das Glob tatsächlich auf die richtigen Pfade abzielt.

3.3. Chat-Modi – .github/chatmodes/*.chatmode.md

Was es ist: Konfigurationsdateien, die den Betriebsmodus des Agenten für den Dialog festlegen: kurze Beschreibung, Modell (falls erforderlich) und Liste der zulässigen Werkzeuge.

Warum: Zur Trennung von Arbeitsphasen (Planung/Frontend/DBA/Sicherheit) und zur Begrenzung der Werkzeuge in jeder Phase. Dies macht die Ergebnisse vorhersagbarer.

Dateistruktur:

1---
2description: "Plan - analyze code/specs and propose a plan; read-only tools"
3model: GPT-4o
4tools:[ "search/codebase"]
5---
6In this mode:
7- Produce a structured plan with risks and unknowns
8- Do not edit files; output a concise task list instead

Wie es funktioniert:

• Der Chat-Modus wird auf den aktuellen Chat in der IDE angewendet.
• Wenn Sie eine Prompt-Datei aktivieren, hat deren Frontmatter Priorität über den Chat-Modus (kann das Modell ändern und tools einschränken).
• Die effektive Liste der zulässigen Werkzeuge: Werkzeuge des Chat-Modus, eingeschränkt durch die Werkzeuge des Prompts und die CLI-Flags --allow/--deny.

Verwaltung und Umschaltung:

• In der IDE (VS Code):

1. Öffnen Sie das Copilot Chat-Panel.
2. Wählen Sie in der oberen Zeile den gewünschten Chat-Modus aus der Dropdown-Liste (die Liste wird aus .github/chatmodes/*.chatmode.md + integrierten Modi erstellt).
3. Der Modus wird nur auf diesen Dialog-Thread angewendet. Zum Ändern – wählen Sie einen anderen oder erstellen Sie einen neuen Thread mit dem gewünschten Modus.
4. Überprüfen Sie den aktiven Modus in der Kopfzeile/im Gesprächspanel; in References wird die Datei *.chatmode.md sichtbar sein.

• In der CLI: (etwas hakelig, besser über Prompts)

  • Es gibt normalerweise kein spezielles CLI-Flag zum Umschalten von Modi; kodieren Sie die gewünschten Einschränkungen im Frontmatter der Prompt-Datei und/oder über die Flags --allow-tool/--deny-tool.
  • Sie können in der ersten Zeile angeben: „Verwenden Sie den i18n-Chat-Modus.“ – wenn die Version dies unterstützt, kann der Agent umschalten; wenn nicht, wendet der Prompt-Frontmatter trotzdem Werkzeugeinschränkungen an.

• Ohne Moduswechsel: Starten Sie den Prompt mit den gewünschten tools: im Frontmatter – dies schränkt die Werkzeuge unabhängig vom Chat-Modus ein.

Diagnose: Wenn der Agent „unnötige“ Werkzeuge verwendet oder benötigte nicht sieht – überprüfen Sie: (1) welcher Chat-Modus gewählt ist; (2) tools im Prompt-Frontmatter; (3) CLI-Flags --allow/--deny; (4) References in der Antwort (sichtbare Dateien *.chatmode.md/*.prompt.md).

3.4. Prompt-Dateien – .github/prompts/*.prompt.md

Was es ist: Szenario-Dateien für wiederverwendbare Aufgaben. Bestehen aus YAML-Frontmatter (Konfiguration) und Body (Anweisungen/Schritte/Akzeptanzkriterien). Werden im Chat über /name oder über CLI aufgerufen.

Wann zu verwenden: Wenn ein vorhersagbarer, automatisierbarer Prozess benötigt wird: PR-Review, Testgenerierung, Funktionsimplementierung nach Spezifikation usw.

Frontmatter-Struktur

• description – kurzes Ziel des Szenarios.
• mode – ask (Q&A, keine Dateibearbeitung) · edit (lokale Bearbeitung offener Dateien) · agent (mehrstufiger Prozess mit Werkzeugen).
• model – gewünschtes Modellprofil.
• tools – Liste der zulässigen Werkzeuge für das Szenario (schränkt selbst das ein, was der Chat-Modus erlaubt hat).

Ausführungsalgorithmus (Reihenfolge)

1. Wo ausführen:

• Im Chat: Geben Sie /prompt-name und Argumente in das Nachrichtenfeld ein.
• In der CLI: Rufen Sie copilot auf und übergeben Sie die Zeichenkette /prompt-name … (interaktiv oder über heredoc / Flag -p).

2. Kontext sammeln: Copilot baut den Ausführungskontext in folgender Reihenfolge auf: repo-instructions → path-instructions (applyTo) → chat mode → prompt frontmatter (Prompt-Frontmatter hat die höchste Priorität und kann Werkzeuge einschränken/Modell ändern).

3. Parameter-Parsing (wo und wie):

   • Im Chat: Parameter folgen im selben Nachricht nach dem Namen, z. B.: /security-review prNumber=123 target=apps/web.
   • In der CLI: Parameter folgen in derselben Zeile /… in stdin oder nach dem Flag -p.
   • Innerhalb der Prompt-Datei sind sie als ${input:name} verfügbar. Wenn ein obligatorischer Parameter fehlt, kann der Prompt ihn im Dialogtext anfordern.

4. Werkzeugrechtezuweisung:

• Effektive Liste der zulässigen Werkzeuge: Werkzeuge des Chat-Modus, eingeschränkt durch die Werkzeuge des Prompts und die CLI-Flags --allow/--deny.
• Wenn ein Werkzeug verboten ist, wird der entsprechende Schritt übersprungen oder erfordert eine Bestätigung / Richtlinienänderung.

5. Ausführung der Schritte aus dem Prompt-Body: Der Agent folgt streng der Schrittreihenfolge und führt nur das aus, was durch Richtlinien/Werkzeuge erlaubt ist (Suche in der Codebasis, Generierung von Diffs, Ausführen von Tests usw.). Für potenziell riskante Aktionen fordert er eine Bestätigung an.

6. Validierungs-Gates: Am Ende führt der Prompt Prüfungen durch (Build/Tests/Lint/Typecheck). Wenn die Prüfung fehlschlägt – gibt der Agent eine Liste von Problemen zurück und schlägt weitere Schritte vor (ohne automatische Zusammenführung/Speicherung von Änderungen).

7. Wo das Ergebnis erscheint (was und wo sichtbar ist):

• Hauptantwort – im Chat-Panel (IDE) oder in stdout (CLI): Tabellen, Listen, Textberichte, Codeblöcke mit diff.
• Dateiänderungen – in Ihrem Arbeitsverzeichnis: In der IDE sind Diffs/vorgeschlagene Patches sichtbar; in der CLI werden Dateien lokal geändert (wenn durch Werkzeuge erlaubt).
• Zusätzliche Artefakte – z. B. ein Kommentar zum PR, wenn GitHub-Werkzeuge erlaubt sind und der Prompt dies angibt.

Ausgabeformat und Prüfungen (Empfehlungen)

• Geben Sie immer das Ausgabeformat an (z. B. Tabelle „issue | file | line | severity | fix“).
• Fügen Sie Validierungs-Gates hinzu: Build/Tests/Lint/Typecheck; fordern Sie Unified-Diff für vorgeschlagene Änderungen an; eine TODO-Liste für ungelöste Probleme.

Beispiel für eine vollständige Prompt-Datei

1---
2mode: 'agent'
3model: GPT-4o
4tools: ['search/codebase']
5description: 'Implement a feature from a spec'
6---
7Goal: Implement the feature described in @docs/feature.spec.md.
8
9Steps:
101) Read @docs/feature.spec.md and produce a short implementation plan (bullets)
112) List files to add/modify with paths
123) Propose code patches as unified diff; ask before installing new deps
134) Generate minimal tests and run them (report results)
14
15Validation gates:
16- Build, tests, lint/typecheck must pass
17- Output includes the final diff and a TODO list for anything deferred

Antipatterns

• Vage Beschreibungen: Halten Sie description kurz (1–2 Zeilen).
• Fehlendes Ausgabeformat.
• Zu viele Werkzeuge: Erlauben Sie nur die benötigten (tools).

Schneller Einstieg

• Chat: /implement-from-spec
• CLI: copilot <<<'/implement-from-spec' oder copilot -p "Run /implement-from-spec"

3.5. Kontextdateien – specs/context/memory

Was es ist: Hilfreiche Markdown-Dateien (keine speziellen Typen), die Sie im Dialog/Prompt über @ erwähnen. Werden normalerweise als Dokumentation gespeichert.

• docs/*.spec.md – genaue Aufgabenstellungen (Ziel, Akzeptanzkriterien, Randfälle, Nicht-Ziele).
• docs/*.context.md – kurze Referenzen (API-Richtlinien, Sicherheit, UI-Styleguide, SLA).
• docs/*.memory.md – „Entscheidungsprotokoll“ mit Daten und Begründungen, damit der Agent nicht zu lange gelöste Probleme wieder aufgreift.

Beispiel:

1# Feature: Export report to CSV
2Goal: Users can export the filtered table to CSV.
3Acceptance criteria:
4- "Export CSV" button on /reports
5- Server generates file ≤ 5s for 10k rows
6- Column order/headers match UI; locale-independent values
7Edge cases: empty values, large numbers, special characters
8Non-goals: XLSX, multi-column simultaneous filters

3.6. MCP – .vscode/mcp.json

Was es ist: Konfiguration von Model Context Protocol-Servern (z. B. GitHub MCP), die dem Agenten Werkzeuge bereitstellen.

Warum: Damit der Agent PRs/Issues lesen, Tests ausführen, mit Datenbanken/Browsern interagieren kann – im Rahmen der erlaubten Rechte.

Beispiel:

1{
2  "servers": {
3    "github-mcp": {
4      "type": "http",
5      "url": "https://api.githubcopilot.com/mcp"
6    }
7  }
8}

Sicherheit. Verbinden Sie nur vertrauenswürdige Server; verwenden Sie Allow/Deny-Listen für Werkzeuge in Prompts/Chat-Modi/CLI.

3.7. Allgemeine Reihenfolge der Kontextzusammenführung und Prioritäten (Regeln & Werkzeuge)

1. Instructions: copilot-instructions + alle *.instructions.md mit applyTo, die mit den aktuellen Pfaden übereinstimmen. Eine spezifische Anweisung wird zum allgemeinen Kontext hinzugefügt.
2. Chat-Modus: schränkt die Werkzeugauswahl und (falls erforderlich) das Modell für die Sitzung ein.
3. Prompt Frontmatter: hat die höchste Priorität; kann Werkzeuge einschränken und das Modell überschreiben.
4. Kontext: Alles, was Sie über @ erwähnen, wird vom Modell garantiert berücksichtigt.

Diagnose. Überprüfen Sie den Abschnitt References in den Ausgaben – dort steht, welche Anweisungsdateien berücksichtigt wurden und welcher Prompt ausgeführt wurde.

3.8. Beispiel: Vollständiger i18n-Zyklus mit Goman MCP (Erstellung/Aktualisierung/Löschung)

Unten finden Sie den genauen Prozess und Vorlagen, um Folgendes sicherzustellen: (a) Beim Erstellen von UI-Komponenten werden Lokalisierungsschlüssel in Goman erstellt/aktualisiert; (b) Beim Löschen von Komponenten werden ungenutzte Einträge erkannt und (nach Bestätigung) gelöscht.

Code-Fragmente und Frontmatter – auf Englisch.

3.8.1. MCP-Konfiguration – Goman-Verbindung

/.vscode/mcp.json

1{
2  "servers": {
3    "goman-mcp": {
4      "type": "http",
5      "url": "https://mcp.goman.live/mcp",
6      "headers": {
7        "apiKey": "<YOUR_API_KEY>",
8        "applicationid": "<YOUR_APPLICATION_ID>"
9      }
10    }
11  }
12}

3.8.2. Repo/Pfad-Regeln – Standardmäßiges i18n erzwingen

/.github/instructions/frontend.instructions.md (Ergänzung)

1---
2applyTo: "apps/web/**/*.{ts,tsx}"
3---
4- All user-facing strings **must** use i18n keys (no hardcoded text in JSX/TSX)
5- Key naming: `<ui_component_area>.<n>` (e.g., `ui_button_primary.label`)
6- When creating components, run `/i18n-component-scaffold` and commit both code and created keys
7- When deleting components, run `/i18n-prune` and confirm removal of unused keys

3.8.3. Chat-Modus – Eingeschränkte i18n-Werkzeuge

/.github/chatmodes/i18n.chatmode.md

1---
2description: "i18n - manage localization keys via Goman MCP; enforce no hardcoded strings"
3model: GPT-4o
4tools:
5  - "files"
6  - "goman-mcp:*"
7---
8In this mode, prefer:
9- Creating/updating keys in Goman before writing code
10- Checking for existing keys and reusing them
11- Producing a table of changes (created/updated/skipped)

3.8.4. Prompt – Scaffolding eines Components + Keys in Goman

/.github/prompts/i18n-component-scaffold.prompt.md

1---
2mode: 'agent'
3model: GPT-4o
4tools: ['files','goman-mcp:*']
5description: 'Scaffold a React component with i18n keys synced to Goman'
6---
7Inputs: componentName, namespace (e.g., `ui.button`), path (e.g., `apps/web/src/components`)
8
9Goal: Create a React component and ensure all user-visible strings use i18n keys stored in Goman.
10
11Steps:
121) Plan the component structure and list all user-visible strings
132) For each string, propose a key under `${namespace}`; reuse if it exists
143) Using Goman MCP, create/update translations for languages: en, be, ru (values may be placeholders)
154) Generate the component using `t('<key>')` and export it; add a basic test
165) Output a Markdown table: key | en | be | ru | action(created/updated/reused)
17
18Validation gates:
19- No hardcoded literals in the produced .tsx
20- Confirm Goman actions succeeded (report tool responses)
21- Tests and typecheck pass

Beispiel für Komponenten-Code:

1import { t } from '@/i18n';
2import React from 'react';
3
4type Props = { onClick?: () => void };
5
6export function PrimaryButton({ onClick }: Props) {
7  return (
8    <button aria-label={t('ui.button.primary.aria')} onClick={onClick}>
9      {t('ui.button.primary.label')}
10    </button>
11  );
12}

3.8.5. Prompt – Löschen ungenutzter Schlüssel beim Löschen von Komponenten

/.github/prompts/i18n-prune.prompt.md

1---
2mode: 'agent'
3model: GPT-4o
4tools: ['files','goman-mcp:*']
5description: 'Find and prune unused localization keys in Goman after code deletions'
6---
7Inputs: pathOrDiff (e.g., a deleted component path or a PR number)
8
9Goal: Detect keys that are no longer referenced in the codebase and remove them from Goman after confirmation.
10
11Steps:
121) Compute the set of removed/renamed UI elements (scan git diff or provided paths)
132) Infer candidate keys by namespace (e.g., `ui.<component>.*`) and check code references
143) For keys with **zero** references, ask for confirmation and delete them via Goman MCP
154) Produce a Markdown table: key | status(kept/deleted) | reason | notes
16
17Validation gates:
18- Never delete keys that still have references
19- Require explicit confirmation before deletion
20- Provide a rollback list of deleted keys

3.8.6. Prompt – Synchronisation und Prüfung fehlender Übersetzungen (optional)

/.github/prompts/i18n-sync.prompt.md

1---
2mode: 'agent'
3model: GPT-4o
4tools: ['files','goman-mcp:*']
5description: 'Sync new/changed i18n keys and check for missing translations'
6---
7Goal: Compare code references vs Goman and fill gaps.
8
9Steps:
101) Scan code for `t('...')` keys under provided namespaces
112) For missing keys in Goman - create them (placeholder text ok)
123) For missing languages - create placeholders and report coverage
134) Output coverage table: key | en | be | de | missing

4) Verwendung (IDE und CLI)

4.1. In VS Code / anderer IDE

• Öffnen Sie Copilot Chat – wählen Sie Agent/Edit/Ask in der Dropdown-Liste.
• Für Prompt-Dateien geben Sie einfach /dateiname ohne Erweiterung ein (z. B. /security-review).
• Fügen Sie Kontext über @-Erwähnungen von Dateien und Verzeichnissen hinzu.
• Wechseln Sie den Chat-Modus (Plan/Frontend/DBA) beim Wechsel des Aufgabentyps.

4.2. In Copilot CLI (Terminal)

• Installationsbeispiel: npm install -g @github/copilot → starten Sie copilot.
• Interaktiv: „Run /implement-from-spec on @docs/feature.spec.md“.
• Programmatisch / in CI: copilot -p "Implement feature from @docs/feature.spec.md" --deny-tool shell("rm*").
• Fügen Sie Werkzeuge hinzu / schränken Sie sie ein über Flags: --allow-all-tools, --allow-tool, --deny-tool (global oder nach Muster, z. B. shell(npm run test:*)).

4.3. Befehlsrezepte für CLI (Chat-Modi und Prompts)

Unten finden Sie fertige Rezepte. Alle Befehle sollten vom Stammverzeichnis des Repositorys aus gestartet werden und Ihre Deny/Allow-Listen respektieren.

A. Starten einer Prompt-Datei in einer interaktiven Sitzung

1copilot
2# innerhalb der Sitzung (geben Sie die Zeichenkette genau so ein)
3/security-review prNumber=123

B. Starten einer Prompt-Datei im nicht-interaktiven Modus (heredoc)

1copilot <<'EOF'
2/security-review prNumber=123
3EOF

C. Übergeben von Parametern an eine Prompt-Datei

1copilot <<'EOF'
2/implement-from-spec path=@docs/feature.spec.md target=apps/web
3EOF

Innerhalb des Prompts können Werte als ${input:target} und ${input:path} gelesen werden.

D. Starten eines Prompts mit sicheren Werkzeugrechten

1copilot --allow-tool "shell(npm run test:*)" \
2        --deny-tool  "shell(rm*)" \
3        <<'EOF'
4/security-review prNumber=123
5EOF

E. Verwendung eines Chat-Modus (spezialisierter Modus) in der CLI

1copilot
2# innerhalb der Sitzung – bitten Sie darum, zum gewünschten Modus zu wechseln und den Prompt zu starten
3Use the i18n chat mode.
4/i18n-component-scaffold componentName=PrimaryButton namespace=ui.button path=apps/web/src/components

Wenn Ihr Client die Modusauswahl über ein Menü unterstützt – wählen Sie i18n, bevor Sie den Prompt starten. Wenn nicht – geben Sie die Einschränkungen im Prompt-Frontmatter an (tools und Regeln im Prompt-Body).

F. Übergeben von Datei-/Diff-Referenzen als Kontext

1copilot <<'EOF'
2Please review these changes:
3@apps/web/src/components/PrimaryButton.tsx
4@docs/feature.spec.md
5/security-review prNumber=123
6EOF

G. Modellwechsel für einen bestimmten Lauf

Wir empfehlen, das Modell im Prompt-Frontmatter anzugeben. Wenn unterstützt, können Sie auch ein Modell-Flag während der Ausführung übergeben:

1copilot --model GPT-4o <<'EOF'
2/implement-from-spec
3EOF

H. i18n-Zyklus mit Goman MCP (CHAT)

Führen Sie nacheinander in einem Chat-Thread aus:

1/i18n-component-scaffold componentName=PrimaryButton namespace=ui.button path=apps/web/src/components
2/i18n-prune pathOrDiff=@last-diff
3/i18n-sync namespace=ui.button

Was Sie erhalten:

• endgültige Tabellen/Berichte im Chat-Panel;
• Codeänderungen in Ihrem Arbeitsverzeichnis (IDE zeigt Diff);
• CLI-Befehle für Goman MCP sind hier nicht erforderlich.

5) Kontext-Engineering: Wie man nicht mit unnötigem Kontext „überlädt“

1. Trennen Sie Sitzungen nach Phasen: Plan → Implementierung → Review/Tests. Jede Phase hat ihren eigenen Chat-Modus.
2. Hängen Sie nur notwendige Anweisungen an: Verwenden Sie pfad-spezifische *.instructions.md anstelle von allem zu laden.
3. Projektspeicher: Schreiben Sie kurze ADRs in project.memory.md – das reduziert das „Vergessen“ des Agenten zwischen Aufgaben.
4. Kontexthelfer: Häufige Referenzen (API/Sicherheit/UI) speichern Sie in *.context.md und verweisen Sie darauf aus Prompt-Dateien.
5. Fokus auf die Aufgabe: Geben Sie in Prompt-Dateien immer Ziel, Schritte und Ausgabeformat an (Tabelle, Diff, Checkliste).

6) Sicherheit und Werkzeugverwaltung

• Fordern Sie explizite Bestätigung vor der Ausführung von Befehlen/Werkzeugen an. In CI verwenden Sie standardmäßig --deny-tool und fügen Sie lokale Allow-Listen hinzu.
• Rechte-Muster: Erlauben Sie nur das Notwendige (shell(npm run test:*), playwright:*), verbieten Sie gefährliche Muster (shell(rm*)).
• Geheimnisse: Legen Sie keine Schlüssel in Prompts und Anweisungen; verwenden Sie GitHub Environments oder lokale Geheimnismanager und .env mit .gitignore.
• Jedes MCP – nur aus vertrauenswürdigen Quellen; überprüfen Sie Code/Konfiguration vor der Verbindung.
• Patch-Prüfungen: Fordern Sie Unified-Diff und Erklärungen in Prompt-Dateien an – dies vereinfacht das Review.

7) CI/CD-Rezept (optionales Beispiel)

Stellen Sie sicher, dass „alles gebaut wird“: Starten Sie Copilot CLI im sicheren Modus, um einen Kommentar für den PR zu generieren.

1# .github/workflows/ai-review.yml
2name: AI Review (Copilot CLI)
3on:
4  pull_request:
5    types: [opened, synchronize, reopened]
6
7jobs:
8  ai_review:
9    runs-on: ubuntu-latest
10    permissions:
11      contents: read
12      pull-requests: write
13    steps:
14      - uses: actions/checkout@v4
15      - uses: actions/setup-node@v4
16        with:
17          node-version: 22
18      - name: Install Copilot CLI
19        run: npm install -g @github/copilot
20      - name: Run security review prompt (no dangerous tools)
21        env:
22          PR: ${{ github.event.pull_request.number }}
23        run: |
24          copilot -p "Run /security-review with prNumber=${PR}" \
25            --deny-tool shell("rm*") --deny-tool shell("curl*") \
26            --allow-tool shell("npm run test:*") \
27            --allow-tool "github:*" \
28            > ai-review.txt || true
29      - name: Comment PR with results
30        if: always()
31        run: |
32          gh pr comment ${{ github.event.pull_request.number }} --body-file ai-review.txt

Tipp: Halten Sie dichte Deny/Allow-Listen ein; geben Sie dem Agenten in CI keine „volle Freiheit“.

8) Kleine Szenarien und nützliche Tipps

• Von der Idee bis zum PR: /plan – Plan besprechen – /implement-from-spec → lokale Tests – PR – /security-review.
• Wartung: /refactor-slice für lokale Verbesserungen ohne Verhaltensänderung.
• Tests: /test-gen für neue Module + manuelle Ergänzungen für Randfälle.
• Schrittweise Einführung: Beginnen Sie mit 1-2 Prompt-Dateien und einem Chat-Modus; erweitern Sie später.

9) Qualitätsprüfungen (Validierungs-Gates)

In jeder Prompt-Datei legen Sie fest, „was als fertig gilt“:

• Ausgabeformat: Risikotabelle, Unified-Diff, Checkliste.
• Automatische Prüfungen: Build, Unit-/Integrationstests, Lint/Typecheck.
• Manuelle Prüfung: „OK to merge?“ mit Begründung und Restrisiken.

10) Antipatterns und Hacks

• Antipattern: ein riesiges instructions.md. Bevorzugen Sie mehrere *.instructions.md mit applyTo.
• Antipattern: allgemeine Worte statt Regeln. Bevorzugen Sie konkrete Befehle/Schritte.
• Antipattern: Ausführen gefährlicher Shell-Befehle ohne Prüfung. Verwenden Sie deny/allow und manuelle Bestätigung.
• Antipattern: vergessene Spezifikationen/Speicher. Pflegen Sie feature.spec.md und project.memory.md.
• Antipattern: Vermischung von Aufgaben in einer Sitzung. Erstellen Sie für jede Phase einen Chat-Modus.

11) Checkliste zur Implementierung

1. Fügen Sie .github/copilot-instructions.md hinzu (mindestens 5-8 Punkte zu Build/Tests/Stil).
2. Erstellen Sie 1-2 *.instructions.md mit applyTo (Frontend/Backend oder Workflows).
3. Fügen Sie plan.chatmode.md und einen Prompt hinzu (z. B. implement-from-spec.prompt.md).
4. Erstellen Sie docs/feature.spec.md und docs/project.memory.md.
5. Verbinden Sie MCP (mindestens GitHub MCP) über .vscode/mcp.json.
6. Starten Sie den Workflow in VS Code: /implement-from-spec – prüfen – PR.
7. (Optional) Fügen Sie ein einfaches KI-Review in CI über Copilot CLI mit strengen Deny/Allow-Listen hinzu.

12) Fragen und Antworten (FAQ)

F: Wie stelle ich sicher, dass Copilot meine Anweisungen „sieht“? A: Überprüfen Sie die Zusammenfassung/Referenzen in der Antwort; halten Sie die Regeln kurz und konkret.

F: Kann ich Parameter dynamisch an Prompt-Dateien übergeben? A: Ja, normalerweise über Platzhalter-Variablen (wie ${prNumber}) oder einfach über eine Textanfrage beim Starten von /prompt im Chat.

F: Wo speichere ich Geheimnisse für MCP? A: In GitHub Environments oder lokalen Geheimnismanagern; nicht in .prompt.md/.instructions.md.

F: Was wählen: Chat-Modus oder Prompt-Datei? A: Chat-Modus legt den „Rahmen“ fest (Modell/Werkzeuge/Rolle). Prompt-Datei ist das „Szenario“ innerhalb dieses Rahmens.

13) Nächste Schritte

• Fügen Sie einen zweiten Prompt für Ihren häufigsten manuellen Prozess hinzu.
• Machen Sie project.memory.md nach allen Architektur-Entscheidungen obligatorisch.
• Verschieben Sie nach und nach kollektives Wissen in *.context.md und verweisen Sie darauf aus Prompt-Dateien.

Anhang A – Schnelleinstiegs-Vorlagen

Alle Schlüssel, Pfade und Flags entsprechen der Dokumentation (28. Oktober 2025).

/.github/copilot-instructions.md – Regeln für das gesamte Repository

1# Repository coding standards
2- Build: `npm ci && npm run build`
3- Tests: `npm run test` (coverage ≥ 80%)
4- Lint/Typecheck: `npm run lint && npm run typecheck`
5- Commits: Conventional Commits; keep PRs small and focused
6- Docs: update `CHANGELOG.md` in every release PR

/.github/instructions/frontend.instructions.md – Anweisungen für bestimmte Pfade

1---
2applyTo: "apps/web/**/*.{ts,tsx},packages/ui/**/*.{ts,tsx}"
3---
4- React: function components and hooks
5- State: Zustand; data fetching with TanStack Query
6- Styling: Tailwind CSS; avoid inline styles except dynamic cases
7- Testing: Vitest + Testing Library; avoid unstable snapshots

/.github/instructions/backend.instructions.md – Anweisungen für bestimmte Pfade

1---
2applyTo: "services/api/**/*.{ts,js},packages/server/**/*.{ts,js}"
3---
4- HTTP: Fastify; version APIs under `/v{N}`
5- DB access: Prisma; migrations via `prisma migrate`
6- Security: schema validation (Zod), rate limits, audit logs
7- Testing: integration tests via `vitest --config vitest.integration.ts`

/.github/instructions/actions.instructions.md – GitHub Actions

1---
2applyTo: ".github/workflows/**/*.yml"
3---
4- Keep jobs small; reuse via composite actions
5- Cache: `actions/setup-node` + built-in cache for npm/pnpm
6- Secrets: only through GitHub Environments; never hardcode

/.github/chatmodes/plan.chatmode.md – benutzerdefinierter Chat-Modus

1---
2description: "Plan - analyze code/specs and propose a plan; read-only tools"
3model: GPT-4o
4tools:
5  - "search/codebase"
6---
7In this mode:
8- Produce a structured plan with risks and unknowns
9- Do not edit files; output a concise task list instead

/.github/prompts/security-review.prompt.md – Prompt-Datei

1---
2mode: 'agent'
3model: GPT-4o
4tools: ['search/codebase']
5description: 'Perform a security review of a pull request'
6---
7Goal: Review PR ${input:prNumber} for common security issues.
8
9Checklist:
10- Authentication/authorization coverage
11- Input validation and output encoding (XSS/SQLi)
12- Secret management and configuration
13- Dependency versions and known CVEs
14
15Output:
16- A Markdown table: issue | file | line | severity | fix
17- If trivial, include a unified diff suggestion

/.github/prompts/implement-from-spec.prompt.md – Prompt-Datei

1---
2mode: 'agent'
3model: GPT-4o
4tools: ['search/codebase']
5description: 'Implement a feature from a spec'
6---
7Your task is to implement the feature described in @docs/feature.spec.md.
8
9Steps:
101) Read @docs/feature.spec.md and summarize the plan
112) List files to add or modify
123) Propose code changes; ask before installing new dependencies
134) Generate minimal tests and run them
14
15Validation gates:
16- Build, tests, lint/typecheck must pass
17- Provide a TODO list for anything deferred

/.github/prompts/refactor-slice.prompt.md – Prompt-Datei

1---
2mode: 'agent'
3model: GPT-4o
4description: 'Refactor a specific code slice without changing behavior'
5---
6Goal: Improve readability and reduce side effects in @src/feature/* while keeping behavior unchanged.
7Criteria: fewer side effects, clearer structure, all tests pass.

/.github/prompts/test-gen.prompt.md – Prompt-Datei

1---
2mode: 'agent'
3model: GPT-4o-mini
4description: 'Generate tests for a given file/module'
5---
6Ask the user to @-mention the target file; generate unit/integration tests and edge cases.

/docs/feature.spec.md – Vorlage für Spezifikationen

1# Feature: Export report to CSV
2Goal: Users can export the filtered table to CSV.
3Acceptance criteria:
4- "Export CSV" button on /reports
5- Server generates file ≤ 5s for 10k rows
6- Column order/headers match UI; locale-independent values
7Edge cases: empty values, large numbers, special characters
8Non-goals: XLSX, multi-column simultaneous filters

/.vscode/mcp.json – Minimale MCP-Konfiguration

1{
2  "servers": {
3    "github-mcp": {
4      "type": "http",
5      "url": "https://api.githubcopilot.com/mcp"
6    }
7  }
8}

Anhang B – Operative Ergänzungen (CLI- & CI-Beispiele)

Diese Beispiele ergänzen Anhang A; sie beschreiben die Verwendung bei der Ausführung / Automatisierung und duplizieren nicht die obigen Vorlagen.

Copilot CLI – Sichere Werkzeugrechte (interaktiv / CI)

1# Starten einer interaktiven Sitzung in Ihrem Repository
2copilot
3
4# Erlauben/Verbieten spezifischer Werkzeuge (genaue Flags gemäß GitHub-Dokumentation)
5copilot --allow-tool "shell(npm run test:*)" --deny-tool "shell(rm*)"
6
7# Starten einer Prompt-Datei im nicht-interaktiven Modus (Beispiel)
8copilot <<'EOF'
9/security-review prNumber=123
10EOF

GitHub Actions – Kommentieren von Review-Ergebnissen im PR

1name: AI Security Review (Copilot CLI)
2on:
3  pull_request:
4    types: [opened, synchronize, reopened]
5
6jobs:
7  review:
8    runs-on: ubuntu-latest
9    permissions:
10      contents: read
11      pull-requests: write
12    steps:
13      - uses: actions/checkout@v4
14      - uses: actions/setup-node@v4
15        with:
16          node-version: 22
17      - name: Install Copilot CLI
18        run: npm install -g @github/copilot
19      - name: Run security review prompt
20        env:
21          PR: ${{ github.event.pull_request.number }}
22        run: |
23          copilot --allow-tool "shell(npm run test:*)" --deny-tool "shell(rm*)" <<'EOF'
24          /security-review prNumber=${PR}
25          EOF
26      - name: Post results
27        run: |
28          gh pr comment ${{ github.event.pull_request.number }} --body "Copilot review completed. See artifacts/logs for details."

14) Konfiguration des Kontexts für ein bestehendes Projekt

Dieser Abschnitt löst eine spezifische Aufgabe: Sie nehmen ein bereits bestehendes Projekt und erstellen in einem Durchgang einen vollständigen Kontext und Anweisungen für GitHub Copilot. Wir erfinden nichts – alles wird aus dem genommen, was bereits im Code vorhanden ist.

Jeder Schritt ist ein Prompt, der in VS Code im Agenten-Modus ausgeführt wird. Jeder nachfolgende Schritt hängt vom Ergebnis des vorherigen ab, daher ist die Reihenfolge wichtig.

14.1. Schritt 1 – Projekt-Audit

Ziel: Eine objektive Projektkarte erhalten. Ohne sie ist alles Weitere eine Vermutung.

Was wir tun: Wir öffnen Copilot Chat, wählen den Agenten-Modus, hängen den Stammordner über @ an und starten:

1@/
2
3Analyse structure of this project. Determine:
4
5- stack: language, frameworks, package manager
6- build, test, lint commands (exact, from package.json / pom.xml / Makefile etc.)
7- existing CI workflows (.github/workflows) – what runs there
8- main folders and their purpose
9- existing configurations: lint, prettier, typescript, and similar
10
11Return the result as a structured list.
12Do not infer – only what is actually visible in the files.

Ergebnis: Speichern Sie die Antwort – sie wird in Schritt 2 benötigt. Dies ist die „Ausgangskarte“, von ihr hängt die Qualität alles Folgenden ab.

14.2. Schritt 2 – Generierung globaler Anweisungen

Ziel: Erstellen Sie .github/copilot-instructions.md – eine einzige Quelle für Regeln für das gesamte Repository.

Was wir tun: Nehmen Sie das Ergebnis von Schritt 1 und starten Sie:

1Based on this project audit:
2
3[insert result from step 1]
4
5Create the file .github/copilot-instructions.md
6
7Requirements:
8- only facts from the audit, nothing invented
9- build, test, lint commands – exact, copied from config files
10- code style – only if prettier/eslint config exists, and only what's fixed there
11- commit policy – only if commitlint or similar exists
12- 8-12 points maximum
13- each point – one specific line

Ergebnis: Die Datei .github/copilot-instructions.md wird erstellt und im Arbeitsverzeichnis festgeschrieben.

14.3. Schritt 3 – Generierung pfad-spezifischer Anweisungen

Ziel: Erstellen Sie separate Regeln für verschiedene Codebereiche, die automatisch nach Pfadmuster angewendet werden.

Wann benötigt: Wenn das Projekt mindestens zwei logisch getrennte Bereiche hat – Frontend und Backend, Apps und Pakete, mehrere Dienste. Wenn das Projekt homogen ist – überspringen Sie diesen Schritt.

Was wir tun: Hängen Sie für jeden Bereich den entsprechenden Ordner an und starten Sie einen separaten Prompt. Beispiel für Frontend:

1@src/components/
2@src/pages/
3
4Analyze this part of the project and determine:
5
6- what framework and how components are written
7- state management patterns (if visible)
8- how tests are structured (if they exist)
9- import and file naming conventions
10
11Create the file .github/instructions/frontend.instructions.md
12
13Requirements:
14- applyTo – an exact glob covering precisely these folders
15- rules – only from what you see in the code
16- does not duplicate what is already in copilot-instructions.md
17- no more than 6-8 points

Ein ähnlicher Prompt für das Backend, falls vorhanden, mit entsprechenden Ordnern unter @.

Ergebnis: Dateien in .github/instructions/ für jeden Bereich.

14.4. Schritt 4 – Generierung eines Projektverzeichnisses

Ziel: Erstellen Sie docs/project.context.md – ein stabiles Nachschlagewerk, das das „Rauschen“ in Chats reduziert und keine Aktualisierung bei jeder Änderung erfordert.

Was wir tun:

1@/
2@README.md
3@package.json
4
5Create the file docs/project.context.md –
6this is a project reference for the AI assistant.
7
8Include:
9- brief description: what the project does, for whom
10- key architectural patterns, if they are visible in the folder structure and imports
11- external dependencies and their roles (why specifically these, if understandable from context)
12- things NOT to do: deprecated folders, crowded patterns, known limitations
13
14Limitations:
15- max 30-40 lines
16- only what is objectively visible in the project
17- no assumptions or recommendations

Ergebnis: Die Datei docs/project.context.md.

14.5. Schritt 5 – Generierung des Projektspeichers

Ziel: Entscheidungen festhalten, die bereits getroffen wurden, damit der Agent nicht wieder darauf zurückkommt.

Was wir tun:

1@/
2
3Look at the project and find decisions that are already recorded in the code:
4
5- choice of libraries – if obvious alternatives are visible in lock files or comments
6- folder structure – if it's non-standard for this stack
7- any TODOs or FIXMEs that have context why
8- configurations that have comments with justification
9
10Create the file docs/project.memory.md in the format:
11
12## [date or "unknown"] | Decision | Why
13
14Each entry – max 2 lines.
15No more than 10-12 entries.
16Only what is actually visible.

Ergebnis: Die Datei docs/project.memory.md.

14.6. Schritt 6 – Erste Prompt-Datei

Ziel: Eine funktionierende Prompt für die häufigste Aufgabe erstellen. Nicht sofort alle fünf aus den Vorlagen – beginnen Sie mit einer und fügen Sie bei Bedarf weitere hinzu.

Wann welcher Prompt: Wenn das Team häufiger neue Features implementiert – nehmen Sie implement-from-spec. Wenn häufiger PRs revidiert werden – nehmen Sie security-review. Wählen Sie das, was täglich verwendet wird.

Was wir tun (Beispiel für implement-from-spec):

1@.github/copilot-instructions.md
2
3Create the file .github/prompts/implement-from-spec.prompt.md
4for this project.
5
6Requirements:
7- mode: agent
8- tools: only search/codebase
9- steps should use the build and test commands
10  from copilot-instructions.md
11- validation gates: build, tests, lint should pass
12- description – one line

Ergebnis: Die Datei .github/prompts/implement-from-spec.prompt.md, angepasst an den spezifischen Projekt-Stack.

14.7. Ergebnis und nächste Schritte

Nach diesen sechs Schritten gibt es im Repository:

1.github/
2  copilot-instructions.md          ← global rules (step 2)
3  instructions/
4    frontend.instructions.md       ← rules for frontend (step 3)
5    backend.instructions.md        ← rules for backend (step 3)
6  prompts/
7    implement-from-spec.prompt.md  ← first prompt (step 6)
8docs/
9  project.context.md               ← project reference (step 4)
10  project.memory.md                ← memory of decisions (step 5)

Dies ist ein minimal funktionsfähiges Set. Weiter – iterativ:

• Fügen Sie Prompt-Dateien hinzu, sobald neue typische Aufgaben auftauchen.
• Aktualisieren Sie project.memory.md nach jeder Architektur-Entscheidung.
• Fügen Sie Chat-Modi hinzu, wenn Sie feststellen, dass verschiedene Arbeitsphasen sich gegenseitig behindern.
• Schließen Sie MCP erst an, nachdem der Basis-Kontext funktioniert.

Alles, was oben beschrieben wurde, passt in eine einzige Arbeitssitzung. Jeder Prompt kann nacheinander ausgeführt werden, ohne manuell zwischen Dateien zu wechseln – der Agent erstellt die Dateien im Arbeitsverzeichnis selbst.

Quellen

Benutzerdefinierte Chat-Modi in VS Code

Verwendung von MCP-Servern in VS Code

Hinzufügen von benutzerdefinierten Repository-Anweisungen für GitHub Copilot

Wie man zuverlässige KI-Workflows mit Agenten-Primitiven und Kontext-Engineering erstellt

🙌 PS:

Danke, dass Sie bis zum Ende gelesen haben! Wenn das Material hilfreich war, würden wir uns freuen, wenn Sie:

Technologien werden zugänglicher, wenn sie verstanden werden. Und Sie haben bereits den ersten wichtigen Schritt gemacht 💪