Copilot Memory oder benutzerdefinierte Anweisungen: Wo die Gedächtniseinträge liegen und wie Sie sie löschen

Alle 12 Schritte: vom Ordner auf der Festplatte bis zur committeten Anweisungsvorlage

Eine Vorlage für benutzerdefinierte Anweisungen, die die sechs Dinge abdeckt, die Copilot wirklich braucht

GitHubs eigene Empfehlung lautet: Halten Sie die Datei kurz und konkret – welcher Stack verwendet wird, wie man Dinge ausführt, wo der Code liegt, welche Konventionen verbindlich sind und was zu vermeiden ist. Die folgenden Bausteine sind zum Kopieren und anschließenden Kürzen gedacht – löschen Sie jede Zeile, die der Agent durch Lesen des Repositorys selbst herausfinden könnte, denn eine aufgeblähte Instructions-Datei verwässert die Regeln, auf die es ankommt. Speichern Sie sie als .github/copilot-instructions.md im Repository-Stamm.

# .github/copilot-instructions.md

## Project and stack
- Next.js 15 app router, TypeScript strict, Node 22.
- Package manager: pnpm. Never run npm or yarn install.

## Commands
- Build: pnpm build
- Lint: pnpm lint
- Test everything: pnpm test
- Test one file: pnpm test -- path/to/file.test.ts

## Layout
- Routes: src/app/**
- UI components: src/components/**
- Data access: src/lib/db.ts and src/lib/repositories/**
- Tests live next to the file they cover: *.test.ts

## Conventions
- Named exports only; no default exports from src/lib.
- Handle errors at the boundary and return early instead of nesting.
- Import order: node builtins, external packages, then @/ aliases.

## Testing and review
- Every behaviour change ships with a test in the same pull request.
- Run the single-file test before requesting review.
- Commit messages follow Conventional Commits.

## Do not
- Do not edit files under src/generated/**.
- Do not add a dependency without calling it out in the pull request.
- Do not log secrets, tokens or full request bodies.

• 1Projekt und Stack – nennen Sie Framework, Sprachmodus und Paketmanager in einer Zeile. Dieser Baustein verhindert, dass der Agent zwischen npm, pnpm und yarn rät und eine Lockdatei erzeugt, die Sie nicht angefordert haben.
• 2Befehle – die genauen Befehle für Build, Lint, Tests und Tests einzelner Dateien, kopiert aus Ihrer CI-Konfiguration statt aus dem Gedächtnis. Nichts ist teurer, als den Testbefehl falsch anzugeben oder wegzulassen.
• 3Layout – wo Routen, Komponenten, Datenzugriff und Tests liegen. Verweisen Sie auf Verzeichnisse, statt die Architektur in Prosa zu beschreiben; ein Pfad ist überprüfbar, ein Absatz nicht.
• 4Konventionen – Namensgebung, Fehlerbehandlung, Importreihenfolge und Formatierungsregeln, die Ihr Team tatsächlich durchsetzt. Formulieren Sie jede Regel binär: Der Code hält sie ein oder nicht.
• 5Tests und Review – was mit einem Test ausgeliefert werden muss, was ein Review prüfen soll und welche Commit- oder Branch-Konvention gilt. Dieser Baustein verwandelt einen Gedächtniseintrag, den Sie sonst bräuchten, in eine Garantie.
• 6Nicht tun – die Anti-Patterns. Generierte Dateien, neue Abhängigkeiten ohne Erwähnung, themenfremde Refactorings, Geheimnisse in Logs. Verbotsregeln sind der günstigste Weg, eine ganze Klasse schlechter Pull Requests zu verhindern.

Mit einer zweiten Datei eingrenzen

Halten Sie die Repository-Datei kurz, indem Sie ordnerspezifische Regeln in eigene Dateien unter .github/instructions/ auslagern. Das Frontmatter macht das möglich: applyTo hängt die Datei automatisch an passende Pfade an, und description lässt den Agenten sie für die richtige Aufgabe hinzuziehen. VS Code dokumentiert name, description und applyTo als unterstützte Felder.

---
name: 'React components'
description: 'Use when creating or updating components under src/components.'
applyTo: 'src/components/**/*.tsx'
---

# React components
- One component per file, named after the file.
- Props are typed with an explicit interface; no React.FC.
- Colocate styles with the component; no global class names.

Eigene Vorlieben gehören nicht in die Repository-Datei

Alles, was Sie betrifft und nicht das Projekt – Antwortlänge, Tonfall, die Art, wie Diffs erklärt werden sollen –, gehört in die persönlichen Anweisungen. Copilot CLI und der Agent-Host lesen ~/.copilot/copilot-instructions.md; auf github.com öffnen Sie Copilot Chat, klicken auf Ihr Profilbild und wählen Personal instructions. Dort liefert GitHub außerdem Vorlagen mit Platzhaltern wie [format] mit. Persönliche Anweisungen haben Vorrang vor Repository- und Organisationsanweisungen; eine dort hinterlegte Vorliebe muss also nicht in jedem Repository wiederholt werden.

Zwei letzte Regeln gelten für jeden Baustein: Legen Sie niemals Geheimnisse, Tokens oder Kundendaten in einer committeten Instructions-Datei ab, und lassen Sie Repository-Anweisungen und einen Gedächtniseintrag nie Unterschiedliches aussagen – bei einem Konflikt folgt Copilot beiden Kontextsätzen so gut es geht, und das Ergebnis ist unvorhersehbar. Widerspricht ein Gedächtniseintrag immer wieder einer Regel, die Sie geschrieben haben, löschen Sie den Gedächtniseintrag, statt die Regel abzuschwächen.