feat: initial copilot workspace setup

- User settings.json with 9 senior-dev behavior rules - 9 prompt files: requirements, architecture, new-feature, code-review, debug, refactor, write-tests, done-check, docker - git-templates for .github/ and .vscode/ auto-copy on git init - deploy.sh (macOS/bash) and deploy.fish (Linux/fish) scripts - copilot-bootstrap.fish for existing/cloned repos
2026-05-29 08:19:50 +00:00 · 2026-05-29 08:19:50 +00:00 · 9838c7a0b3
commit 9838c7a0b3
18 changed files with 975 additions and 0 deletions
--- a/.gitignore
+++ b/.gitignore
@ -0,0 +1,2 @@
+.env
+*.local
--- a/README.md
+++ b/README.md
@ -0,0 +1,166 @@
+# rd13_copilot_setup
+
+GitHub Copilot Workspace-Konfiguration für maximale Produktivität – portierbar auf alle Maschinen und Repositories.
+
+## Was ist das?
+
+Dieses Repo enthält alle Konfigurationsdateien die nötig sind um GitHub Copilot wie ein Team aus Senior-Entwicklern arbeiten zu lassen:
+
+- **User-Level Settings** – Copilot-Flags und Senior-Dev-Grundverhalten (per Settings Sync auf alle Geräte)
+- **Prompt Files** – 9 wiederverwendbare Agent-Workflows (`/requirements`, `/new-feature`, `/architecture`, etc.)
+- **Git-Templates** – automatisch in jedes neue Repo kopiert via `git init`
+- **Bootstrap-Skript** – bestehende und geclonte Repos in Sekunden ausstatten
+
+---
+
+## Schnellstart
+
+### Ersteinrichtung (Linux / macOS)
+
+```bash
+# 1. Repo klonen
+git clone <this-repo> ~/dotfiles/copilot-setup
+cd ~/dotfiles/copilot-setup
+
+# 2. Deploy-Skript ausführen
+bash scripts/deploy.sh        # macOS (bash)
+fish scripts/deploy.fish      # Linux mit fish
+```
+
+Das Skript legt alles an den richtigen Orten ab.
+
+### Bestehende oder geclonte Repos ausstatten
+
+```bash
+cd /path/to/existing-repo
+fish ~/.local/bin/copilot-bootstrap.fish
+# → legt .github/copilot-instructions.md + .vscode/ an, überschreibt nichts
+```
+
+### VS Code Settings Sync aktivieren (einmalig pro Gerät)
+
+`Ctrl+Shift+P` → **Settings Sync: Turn On** → Mit GitHub-Account einloggen → Alle Elemente auswählen
+
+---
+
+## Struktur
+
+```
+rd13_copilot_setup/
+├── user-settings/
+│   └── settings.json              ← In ~/.config/Code/User/settings.json (Linux)
+│                                     oder ~/Library/Application Support/Code/User/ (macOS)
+├── prompts/                        ← In VS Code User/prompts/ ablegen (Settings Sync)
+│   ├── requirements.prompt.md      /requirements  – Requirements Engineering Workshop
+│   ├── architecture.prompt.md      /architecture  – Architektur-Review + ADR erstellen
+│   ├── new-feature.prompt.md       /new-feature   – Vollständiger Feature-Workflow
+│   ├── code-review.prompt.md       /code-review   – Security + Qualitäts-Review
+│   ├── debug.prompt.md             /debug         – Root-Cause-Analyse + Fix
+│   ├── refactor.prompt.md          /refactor      – Refactoring ohne Behavior-Change
+│   ├── write-tests.prompt.md       /write-tests   – Test-Generierung
+│   ├── done-check.prompt.md        /done-check    – Definition of Done Checkliste
+│   └── docker.prompt.md            /docker        – Docker/Compose-Aufgaben
+├── git-templates/                  ← Wird via git config --global init.templateDir gesetzt
+│   ├── .github/
+│   │   └── copilot-instructions.md ← Template mit TODO-Feldern
+│   └── .vscode/
+│       ├── settings.json
+│       └── extensions.json
+└── scripts/
+    ├── deploy.sh                   ← Deployment-Skript (bash, für macOS)
+    ├── deploy.fish                 ← Deployment-Skript (fish, für Linux)
+    └── copilot-bootstrap.fish      ← Einzelnes Repo ausstatten
+```
+
+---
+
+## Architektur: 3-Schichten-Modell
+
+```
+┌─────────────────────────────────────────────────────────┐
+│  Layer 1: Immer aktiv (User settings.json)               │
+│  • 9 Senior-Dev-Grundregeln in codeGeneration.instructions│
+│  • Commit-Format, Review-Standard, Test-Standard         │
+│  • Copilot Feature-Flags                                 │
+├─────────────────────────────────────────────────────────┤
+│  Layer 2: Auf Abruf (Prompt Files)                       │
+│  • /requirements  /architecture  /new-feature            │
+│  • /code-review   /debug         /refactor               │
+│  • /write-tests   /done-check    /docker                 │
+├─────────────────────────────────────────────────────────┤
+│  Layer 3: Repo-spezifisch (.github/copilot-instructions) │
+│  • Stack, Konventionen, ADR-Entscheidungen               │
+│  • Definition of Done für dieses Projekt                 │
+│  • NFRs (Performance, Availability, Security)            │
+└─────────────────────────────────────────────────────────┘
+```
+
+**Layer 1** gilt automatisch für jede Anfrage ohne Prompt-File.  
+**Layer 2** wird per `/prompt-name` im Chat aufgerufen.  
+**Layer 3** ist git-tracked, liegt im Repo und wird von Copilot automatisch geladen.
+
+---
+
+## Prompt Files – Wann was verwenden
+
+| Prompt | Aufruf | Wann verwenden |
+|---|---|---|
+| `requirements` | `/requirements` | Vor dem Start – User Stories, ACs, NFRs erarbeiten |
+| `architecture` | `/architecture` | Bei nicht-trivialen Entscheidungen → ADR erstellen |
+| `new-feature` | `/new-feature` | Feature starten – alle 5 Phasen von Req bis Commit |
+| `code-review` | `/code-review` | Vor dem Merge – OWASP + Qualität + Performance |
+| `debug` | `/debug` | Bug analysieren – Root Cause, kein Symptom-Fix |
+| `refactor` | `/refactor` | Code verbessern ohne Behavior-Change |
+| `write-tests` | `/write-tests` | Test-Coverage-Lücken schließen |
+| `done-check` | `/done-check` | Abnahme-Check vor dem Merge (7-Punkte-Checkliste) |
+| `docker` | `/docker` | Docker/Compose analysieren, debuggen, erweitern |
+
+---
+
+## Neues Repo einrichten – Checkliste
+
+Nach `git clone` oder `git init`:
+
+```bash
+# Option A: Bootstrap-Skript (empfohlen)
+fish ~/.local/bin/copilot-bootstrap.fish
+
+# Option B: Manuell
+mkdir -p .github .vscode
+cp ~/dotfiles/copilot-setup/git-templates/.github/copilot-instructions.md .github/
+cp ~/dotfiles/copilot-setup/git-templates/.vscode/settings.json .vscode/
+cp ~/dotfiles/copilot-setup/git-templates/.vscode/extensions.json .vscode/
+```
+
+Danach: TODO-Felder in `.github/copilot-instructions.md` ausfüllen.
+
+---
+
+## .github/copilot-instructions.md ausfüllen
+
+Die wichtigsten Felder:
+
+```markdown
+## Project
+[1-2 Sätze was das Projekt macht]
+
+## Stack
+- Language: TypeScript / Python / Go / ...
+- Framework: Next.js / FastAPI / ...
+- Database: PostgreSQL / Redis / ...
+
+## Architecture
+- Pattern: Hexagonal / MVC / Event-driven
+- Key constraints: [z.B. "stateless services", "no ORM"]
+
+## Conventions
+- Branch: feat/<ticket>-description
+- Commits: Conventional Commits
+- Naming: camelCase functions, PascalCase classes
+
+## Non-Functional Requirements
+- Response time: <200ms p95
+- Availability: 99.9%
+```
+
+Je mehr Kontext hier steht, desto besser arbeitet Copilot ohne Nachfragen.
--- a/git-templates/.github/copilot-instructions.md
+++ b/git-templates/.github/copilot-instructions.md
@ -0,0 +1,76 @@
+# GitHub Copilot – Project Instructions
+
+## Project
+<!-- TODO: Beschreibe das Projekt in 1-2 Sätzen -->
+
+## Stack
+<!-- TODO: Sprachen, Frameworks, wichtige Tools -->
+- Language:
+- Framework:
+- Database:
+- Infrastructure:
+
+## Architecture
+<!-- TODO: Relevante Architekturentscheidungen -->
+- Pattern (MVC / Hexagonal / Event-driven / ...):
+- Key constraints:
+- ADR location: `docs/adr/`
+
+## Conventions
+<!-- TODO: Projekt-spezifische Konventionen -->
+- Branch naming: `feat/<ticket>-description`, `fix/<ticket>-description`
+- Commit format: Conventional Commits (`feat|fix|chore|docs|refactor|test|ci`)
+- File structure:
+- Naming:
+
+## Engineering Process
+
+### Before starting any task
+1. Clarify requirements – user story + acceptance criteria vorhanden?
+2. Impact analysis – welche bestehenden Komponenten sind betroffen?
+3. Architecture check – passt die geplante Lösung zur bestehenden Architektur?
+4. Test strategy – wie wird das Feature getestet?
+
+### Definition of Ready (DoR)
+A task can only be started when:
+- [ ] Acceptance criteria are clear and unambiguous
+- [ ] Non-functional requirements defined (performance, security, scalability)
+- [ ] Architectural approach agreed upon
+- [ ] No unresolved external blockers
+
+### Definition of Done (DoD)
+A task is only done when ALL of the following are true:
+- [ ] Code implements the acceptance criteria
+- [ ] Unit tests written and passing
+- [ ] Integration tests (where applicable) passing
+- [ ] No linter / type errors
+- [ ] No secrets or credentials in code
+- [ ] OWASP Top 10 reviewed
+- [ ] Relevant documentation updated (README, API docs, ADR if applicable)
+- [ ] Commit message follows Conventional Commits
+- [ ] No dead code, no TODOs left behind (or tracked as issues)
+
+## Testing Strategy
+<!-- TODO: Anpassen auf das Projekt -->
+- Framework:
+- Coverage target: ≥ 80% (critical paths: 100%)
+- Test pyramid: unit > integration > e2e
+- Test location: `tests/` mirroring source structure
+
+## Security
+- No secrets in code or config files – use environment variables
+- Validate all inputs at system boundaries
+- Principle of least privilege for all permissions
+- Dependency vulnerabilities: check before adding new deps
+
+## Documentation Standards
+- Code comments: explain WHY, not WHAT
+- Public APIs: always documented
+- Architecture decisions: write ADR in `docs/adr/` (template: `docs/adr/000-template.md`)
+- CHANGELOG.md: update with every release
+
+## Non-Functional Requirements
+<!-- TODO: Anpassen -->
+- Response time:
+- Availability:
+- Data retention:
--- a/git-templates/.vscode/extensions.json
+++ b/git-templates/.vscode/extensions.json
@ -0,0 +1,6 @@
+{
+  "recommendations": [
+    "github.copilot",
+    "github.copilot-chat"
+  ]
+}
--- a/git-templates/.vscode/settings.json
+++ b/git-templates/.vscode/settings.json
@ -0,0 +1,7 @@
+{
+  // Repo-specific overrides only. Global Copilot settings are in User/settings.json (Settings Sync).
+  "editor.rulers": [100],
+
+  // YAML schema validation – adjust to your stack
+  "yaml.schemas": {}
+}
--- a/prompts/architecture.prompt.md
+++ b/prompts/architecture.prompt.md
@ -0,0 +1,66 @@
+---
+mode: agent
+description: Architektur-Review und Architecture Decision Record (ADR) erstellen
+tools:
+  - codebase
+  - editFiles
+---
+
+# Architecture Review & ADR
+
+**Entscheidung:** ${input:decision:Welche architektonische Entscheidung steht an?}
+**Kontext:** ${input:context:Warum wird diese Entscheidung gerade getroffen?}
+
+---
+
+## 1. Kontext & Problem
+
+Beschreibe:
+- Den aktuellen Zustand des Systems (relevante Teile lesen mit `codebase`)
+- Was sich ändern soll und warum
+- Welche Constraints existieren (Performance, Security, Teamgröße, Time-to-Market)
+
+## 2. Optionen
+
+Evaluiere **mindestens 3 Ansätze** (inkl. Status-Quo als Option):
+
+### Option A: [Name]
+**Beschreibung:**
+**Vorteile:**
+**Nachteile:**
+**Risiken:**
+
+### Option B: [Name]
+**Beschreibung:**
+**Vorteile:**
+**Nachteile:**
+**Risiken:**
+
+### Option C: [Name / Status Quo beibehalten]
+**Beschreibung:**
+**Vorteile:**
+**Nachteile:**
+**Risiken:**
+
+## 3. Entscheidung
+
+**Gewählte Option:** [A / B / C]
+
+**Begründung:** (Warum ist das die beste Option gegeben den Constraints?)
+
+**Trade-offs die wir bewusst eingehen:**
+
+## 4. Konsequenzen
+
+**Positiv:**
+**Negativ / Akzeptierte Risiken:**
+**Folgeentscheidungen die nötig werden:**
+
+---
+
+## ADR-Datei erstellen
+
+Erstelle die ADR unter `docs/adr/NNN-[kurzer-titel].md` mit obigem Inhalt im
+[MADR-Format](https://adr.github.io/madr/).
+
+Nummerierung: nächste freie Nummer in `docs/adr/` verwenden.
--- a/prompts/code-review.prompt.md
+++ b/prompts/code-review.prompt.md
@ -0,0 +1,46 @@
+---
+mode: agent
+description: Gründliches Code-Review – Qualität, Security (OWASP), Performance
+tools:
+  - codebase
+  - problems
+---
+
+# Code Review
+
+**Ziel:** ${input:target:Datei, Funktion oder Feature-Bereich}
+
+## Checkliste
+
+### Korrektheit
+- Logikfehler oder unbehandelte Edge-Cases?
+- Fehlerbehandlung vollständig und sinnvoll?
+- Alle Inputs an Systemgrenzen validiert?
+
+### Security (OWASP Top 10)
+- Injection-Risiken (SQL, Command, XSS)?
+- Secrets oder Credentials im Code?
+- Broken Access Control?
+- Vulnerable Dependencies?
+
+### Performance
+- N+1 Queries oder unnötige DB-Roundtrips?
+- Blocking I/O in async Kontext?
+- Unnötige Re-Renders oder recalculations?
+
+### Code-Qualität
+- Funktionen >50 Zeilen → aufteilen?
+- Duplizierter Code (DRY)?
+- Naming klar und konsistent?
+- Dead Code?
+
+## Output-Format
+
+Für jedes gefundene Problem:
+```
+[CRITICAL|HIGH|MEDIUM|LOW] datei.ts:42
+Problem: ...
+Fix: ...
+```
+
+Abschluss: Gesamtbewertung (1–10) + die 3 wichtigsten Maßnahmen.
--- a/prompts/debug.prompt.md
+++ b/prompts/debug.prompt.md
@ -0,0 +1,32 @@
+---
+mode: agent
+description: Root-Cause-Analyse und gezielter Fix für Bugs und unerwartetes Verhalten
+tools:
+  - codebase
+  - editFiles
+  - runCommands
+  - problems
+  - terminalLastCommand
+---
+
+# Debug & Fix
+
+**Problem:** ${input:problem:Beschreibe den Fehler oder das unerwartete Verhalten}
+
+**Fehlermeldung / Stack-Trace** (optional einfügen):
+```
+${input:stacktrace:Stack-Trace oder Fehlermeldung hier – oder leer lassen}
+```
+
+## Debugging-Strategie
+
+1. **Reproduce** – Unter welchen Bedingungen tritt der Fehler auf?
+2. **Isolate** – Kleinsten betroffenen Code-Bereich identifizieren
+3. **Root Cause** – Eigentliche Ursache finden (nicht nur Symptom bekämpfen)
+4. **Fix** – Minimaler, gezielter Fix ohne Refactoring nebenbei
+5. **Verify** – Fix löst das Problem, keine Regression
+
+## Regeln
+- Nicht den ersten offensichtlichen Fix wählen – erst Root Cause verstehen
+- Nie mehr Code ändern als für den Fix notwendig
+- Wenn der Fix >10 Zeilen braucht: hinterfrage ob das Symptom nicht woanders liegt
--- a/prompts/docker.prompt.md
+++ b/prompts/docker.prompt.md
@ -0,0 +1,30 @@
+---
+mode: agent
+description: Docker / Compose Service analysieren, debuggen oder erweitern
+tools:
+  - codebase
+  - editFiles
+  - runCommands
+  - terminalLastCommand
+---
+
+# Docker / Infrastructure
+
+**Aufgabe:** ${input:task:Was soll analysiert, gefixt oder gebaut werden?}
+
+## Kontext
+- Basis: Docker Compose
+- Umgebung: Linux-Server (remote via VS Code Server)
+- Typische Services: Datenbank, App-Container, Reverse Proxy
+
+## Workflow
+1. Bestehende `docker-compose.yml` und `.env`-Dateien lesen
+2. Logs / Fehlermeldungen analysieren (terminalLastCommand)
+3. Minimale Änderung umsetzen
+4. Validierung: `docker compose config` für Syntax, Service-Status prüfen
+
+## Sicherheitsregeln
+- Keine Secrets in docker-compose.yml – immer `.env` oder Docker Secrets
+- Ports nur soweit nötig exponieren
+- Container nie als root (außer explizit begründet)
+- Images immer mit Tag pinnen (kein `:latest` in Produktion)
--- a/prompts/done-check.prompt.md
+++ b/prompts/done-check.prompt.md
@ -0,0 +1,66 @@
+---
+mode: agent
+description: Definition of Done – vollständige Abnahme-Checkliste vor dem Merge
+tools:
+  - codebase
+  - runCommands
+  - problems
+---
+
+# Definition of Done – Abnahme-Check
+
+**Task / Feature:** ${input:task:Was wurde implementiert?}
+
+Führe alle Checks durch. Behebe gefundene Probleme bevor du abschließt.
+
+---
+
+## 1. Funktionalität
+- [ ] Alle Acceptance Criteria erfüllt (gegen ursprüngliche ACs prüfen)
+- [ ] Happy Path funktioniert
+- [ ] Edge Cases behandelt
+- [ ] Error Cases mit sinnvollen Fehlermeldungen
+
+## 2. Code-Qualität
+- [ ] Kein roter Code (`problems`-Tool)
+- [ ] Kein Dead Code, keine auskommentierten Blöcke
+- [ ] Keine TODOs ohne zugehöriges Issue
+- [ ] Funktionen ≤ 50 Zeilen, Klassen ≤ 200 Zeilen
+- [ ] Naming: klar, konsistent, keine Abkürzungen
+
+## 3. Tests
+- [ ] Unit-Tests für alle neuen/geänderten Funktionen
+- [ ] Integration-Tests wo Services zusammenspielen
+- [ ] Alle Tests grün
+- [ ] Keine Tests deaktiviert/übersprungen ohne Begründung
+- [ ] Coverage nicht gesunken
+
+## 4. Security (OWASP Top 10)
+- [ ] Keine Secrets, API-Keys, Passwörter im Code
+- [ ] Alle Inputs an System-Grenzen validiert
+- [ ] SQL/Command-Injection nicht möglich
+- [ ] Auth/Authz korrekt
+- [ ] Keine neuen Abhängigkeiten mit bekannten CVEs
+
+## 5. Dokumentation
+- [ ] Code-Kommentare erklären das WHY (nicht das WHAT)
+- [ ] Public APIs dokumentiert
+- [ ] README aktualisiert (wenn Verhalten sich ändert)
+- [ ] ADR erstellt (wenn architektonische Entscheidung getroffen wurde)
+- [ ] CHANGELOG.md aktualisiert (wenn Release-relevant)
+
+## 6. Git
+- [ ] Commits atomar (ein Commit = eine logische Änderung)
+- [ ] Commit-Messages: Conventional Commits Format
+- [ ] Keine unrelated changes im Branch
+- [ ] Branch up-to-date mit main/master
+
+## 7. Nicht-funktionale Anforderungen
+- [ ] Performance: keine Regression (bekannte Benchmarks)
+- [ ] Keine neuen Warnungen in Logs
+- [ ] Ressourcenverbrauch vertretbar (CPU, Memory, DB-Queries)
+
+---
+
+**Ergebnis:** Wenn alle Punkte ✓ → Task ist Done. Jeden offenen Punkt mit konkretem
+Problem und Fix-Vorschlag benennen.
--- a/prompts/new-feature.prompt.md
+++ b/prompts/new-feature.prompt.md
@ -0,0 +1,88 @@
+---
+mode: agent
+description: Neues Feature – vollständiger Engineering-Prozess von Requirements bis Commit
+tools:
+  - codebase
+  - editFiles
+  - runCommands
+  - problems
+---
+
+# New Feature – Full Engineering Workflow
+
+**Feature Request:** ${input:feature_description:Beschreibe das gewünschte Feature}
+
+---
+
+## Phase 1 – Requirements Engineering
+
+Bevor eine Zeile Code geschrieben wird:
+
+**User Story:**
+> Als [Rolle] möchte ich [Aktion], damit [Nutzen].
+
+**Acceptance Criteria** (konkret, testbar, kein Interpretationsspielraum):
+- [ ] AC1:
+- [ ] AC2:
+- [ ] AC3:
+
+**Non-Functional Requirements:**
+- Performance: (z.B. Response <200ms unter Last X)
+- Security: (z.B. Auth erforderlich, Input-Validierung)
+- Scalability: (z.B. muss bei Y gleichzeitigen Usern funktionieren)
+
+**Out of Scope** (explizit ausschließen):
+-
+
+→ Prüfe: Sind alle ACs klar und unambiguös? Wenn nicht, stelle Rückfragen.
+
+---
+
+## Phase 2 – Architecture Review
+
+**Bestandsanalyse:** Lies relevante bestehende Dateien mit dem `codebase`-Tool.
+
+**Ansätze** (mindestens 2 evaluieren):
+| Ansatz | Vorteile | Nachteile | Empfehlung |
+|---|---|---|---|
+| A | | | |
+| B | | | |
+
+**Entscheidung:** [Begründung warum Ansatz X gewählt wird]
+
+**Impact Analysis:**
+- Welche bestehenden Komponenten werden berührt?
+- Gibt es Breaking Changes?
+- Datenbankmigrationen erforderlich?
+
+---
+
+## Phase 3 – Implementation
+
+Implementiere gemäß dem gewählten Ansatz. Halte dich strikt an:
+- Bestehende Code-Patterns und Naming-Konventionen
+- Kein Code außerhalb des definierten Scopes
+- Jeden Schritt kompilierbar lassen
+
+---
+
+## Phase 4 – Tests (nicht überspringen)
+
+Test-Strategie für dieses Feature:
+- **Unit Tests:** Alle neuen Funktionen mit Arrange/Act/Assert
+- **Integration Tests:** Zusammenspiel der Komponenten
+- **Edge Cases:** Leer-Input, Grenzwerte, Fehlerszenarien
+
+Tests müssen grün sein bevor weitergemacht wird.
+
+---
+
+## Phase 5 – Definition of Done
+
+Bevor der Task als abgeschlossen gilt:
+- [ ] Alle Acceptance Criteria erfüllt
+- [ ] Alle Tests grün, keine `problems`-Fehler
+- [ ] Keine Secrets im Code
+- [ ] OWASP Top 10 geprüft
+- [ ] Dokumentation aktualisiert (README / API-Docs / ADR falls nötig)
+- [ ] Commit mit Conventional Commits Format erstellt
--- a/prompts/refactor.prompt.md
+++ b/prompts/refactor.prompt.md
@ -0,0 +1,33 @@
+---
+mode: agent
+description: Refactoring – Code verbessern ohne Verhalten zu ändern
+tools:
+  - codebase
+  - editFiles
+  - problems
+---
+
+# Refactoring
+
+**Ziel:** ${input:target:Was soll refactored werden und warum?}
+
+## Grundregeln (nicht verhandelbar)
+- **Kein Behavior-Change** – Tests müssen vorher und nachher grün sein
+- Scope klar definieren – nichts außerhalb des Ziels anfassen
+- Inkrementell vorgehen – nach jedem Schritt kompilierbar/lauffähig
+
+## Was ist erwünscht?
+Wähle was zutrifft (oder beschreibe selbst):
+- Lesbarkeit verbessern (Naming, Struktur)
+- Duplizierung eliminieren (DRY)
+- Komplexität reduzieren (Cyclomatic Complexity)
+- Performance-kritischen Pfad optimieren
+- Testbarkeit erhöhen (Dependency Injection, Pure Functions)
+
+## Prozess
+1. Analyse: Aktuelle Probleme konkret benennen
+2. Plan: Welche Änderungen in welcher Reihenfolge
+3. Durchführung: Schrittweise, jeder Schritt single-purpose
+4. Verifikation: `problems`-Tool, kein roter Code
+
+Nach dem Refactoring: diff-Zusammenfassung mit Begründung für jede wesentliche Änderung.
--- a/prompts/requirements.prompt.md
+++ b/prompts/requirements.prompt.md
@ -0,0 +1,73 @@
+---
+mode: agent
+description: Requirements Engineering Workshop – User Stories, ACs und NFRs erarbeiten
+tools:
+  - codebase
+---
+
+# Requirements Engineering Workshop
+
+**Ausgangspunkt:** ${input:raw_request:Was wurde grob angefragt oder gewünscht?}
+
+Führe einen strukturierten Requirements-Workshop durch. Stelle Rückfragen wo nötig,
+aber arbeite so weit wie möglich mit dem vorhandenen Kontext.
+
+---
+
+## 1. Problem Statement
+
+**Problem:** Was ist das eigentliche Problem, das gelöst werden soll?
+**Betroffene Nutzer:** Wer hat dieses Problem?
+**Aktueller Workaround:** Wie lösen Nutzer das Problem heute?
+**Impact:** Was passiert wenn wir es nicht lösen?
+
+## 2. User Stories
+
+Erstelle User Stories im Format:
+> Als **[Rolle]** möchte ich **[Aktion/Feature]**, damit **[geschäftlicher Nutzen]**.
+
+Identifiziere: Wer sind die Nutzer-Rollen in diesem System?
+
+## 3. Acceptance Criteria
+
+Für jede User Story: konkrete, testbare, unambiguöse ACs.
+
+**Format:** `Given [Vorbedingung], When [Aktion], Then [Erwartetes Ergebnis]`
+
+Checkliste für gute ACs:
+- [ ] Eindeutig – nur eine mögliche Interpretation
+- [ ] Testbar – kann automatisch oder manuell verifiziert werden
+- [ ] Vollständig – Happy Path + wichtigste Error-Cases abgedeckt
+- [ ] Kein "wie" – ACs beschreiben WAS, nicht WIE
+
+## 4. Non-Functional Requirements
+
+| Kategorie | Anforderung | Messbar? |
+|---|---|---|
+| Performance | z.B. Response <200ms bei 100 concurrent users | |
+| Security | z.B. Auth erforderlich, keine PII in Logs | |
+| Availability | z.B. 99.9% uptime, <1h RTO | |
+| Scalability | z.B. skaliert bis 10.000 Einträge ohne Perf-Degradation | |
+| Maintainability | z.B. neue Entwickler können in <1h onboarden | |
+
+## 5. Out of Scope (explizit)
+
+Was wird explizit **nicht** gebaut (jetzt):
+-
+
+## 6. Open Questions & Risiken
+
+Offene Fragen die vor dem Start beantwortet werden müssen:
+-
+
+Bekannte Risiken:
+-
+
+## 7. Definition of Ready
+
+Dieser Task ist ready to start wenn:
+- [ ] Alle ACs klar und unambiguös
+- [ ] NFRs definiert
+- [ ] Scope abgegrenzt
+- [ ] Open Questions geklärt
+- [ ] Architektureller Ansatz skizziert
--- a/prompts/write-tests.prompt.md
+++ b/prompts/write-tests.prompt.md
@ -0,0 +1,34 @@
+---
+mode: agent
+description: Tests schreiben – Unit, Integration oder E2E für bestehenden Code
+tools:
+  - codebase
+  - editFiles
+  - runCommands
+  - problems
+---
+
+# Tests schreiben
+
+**Ziel:** ${input:target:Welcher Code soll getestet werden?}
+**Test-Typ:** ${input:test_type:unit / integration / e2e}
+
+## Strategie
+
+1. **Analyse** – Bestehende Tests lesen, Test-Framework und Patterns verstehen
+2. **Coverage-Lücken** – Welche Fälle sind ungetestet?
+3. **Test-Cases** – Happy Path + Edge Cases + Error Cases definieren
+4. **Implementierung** – Tests schreiben, bestehende Patterns und Helpers nutzen
+5. **Ausführen** – Tests laufen grün
+
+## Gute Tests
+- **Arrange / Act / Assert** – klare Struktur
+- Ein Test = eine Assertion (oder eng verwandte Gruppe)
+- Test-Namen beschreiben das erwartete Verhalten: `should return empty array when input is null`
+- Keine Implementation Details testen – nur Verhalten
+- Keine Mocks wo Echte Objekte möglich sind
+
+## Nicht erwünscht
+- Tests die nur Code paraphrasieren ohne Mehrwert
+- Fragile Tests die bei jedem Refactor brechen
+- Tests mit versteckten Abhängigkeiten zwischen sich
--- a/scripts/copilot-bootstrap.fish
+++ b/scripts/copilot-bootstrap.fish
@ -0,0 +1,49 @@
+#!/usr/bin/env fish
+# copilot-bootstrap.fish
+# Fügt Copilot-Grundkonfiguration zu einem bestehenden oder neu geklonten Repo hinzu.
+#
+# Usage:
+#   fish copilot-bootstrap.fish                  # aktuelles Verzeichnis
+#   fish copilot-bootstrap.fish /path/to/repo    # anderes Verzeichnis
+
+set TEMPLATE_DIR /home/rd13server/.git-templates
+set TARGET (test (count $argv) -gt 0; and echo $argv[1]; or echo (pwd))
+
+if not test -d "$TARGET/.git"
+    echo "Error: $TARGET is not a git repository"
+    exit 1
+end
+
+echo "Bootstrapping Copilot config in: $TARGET"
+
+# .github/copilot-instructions.md
+if not test -f "$TARGET/.github/copilot-instructions.md"
+    mkdir -p "$TARGET/.github"
+    cp "$TEMPLATE_DIR/.github/copilot-instructions.md" "$TARGET/.github/copilot-instructions.md"
+    echo "  ✓ .github/copilot-instructions.md created (fill in TODO sections)"
+else
+    echo "  ─ .github/copilot-instructions.md already exists, skipping"
+end
+
+# .vscode/settings.json
+if not test -f "$TARGET/.vscode/settings.json"
+    mkdir -p "$TARGET/.vscode"
+    cp "$TEMPLATE_DIR/.vscode/settings.json" "$TARGET/.vscode/settings.json"
+    echo "  ✓ .vscode/settings.json created"
+else
+    echo "  ─ .vscode/settings.json already exists, skipping"
+end
+
+# .vscode/extensions.json
+if not test -f "$TARGET/.vscode/extensions.json"
+    mkdir -p "$TARGET/.vscode"
+    cp "$TEMPLATE_DIR/.vscode/extensions.json" "$TARGET/.vscode/extensions.json"
+    echo "  ✓ .vscode/extensions.json created"
+else
+    echo "  ─ .vscode/extensions.json already exists, skipping"
+end
+
+echo ""
+echo "Done. Next steps:"
+echo "  1. Fill in TODO sections in .github/copilot-instructions.md"
+echo "  2. git add .github .vscode && git commit -m 'chore: add copilot workspace config'"
--- a/scripts/deploy.fish
+++ b/scripts/deploy.fish
@ -0,0 +1,65 @@
+#!/usr/bin/env fish
+# deploy.fish – Copilot-Setup auf Linux mit fish-Shell deployen
+# Usage: fish scripts/deploy.fish
+
+set REPO_DIR (dirname (status filename))/..
+set REPO_DIR (realpath $REPO_DIR)
+
+echo "=== Copilot Setup Deploy (Linux/fish) ==="
+echo "Source: $REPO_DIR"
+
+# ── 1. VS Code User-Verzeichnis ermitteln ─────────────────────────────────────
+# Remote (VS Code Server)
+if test -d /home/(whoami)/.vscode-server/data/User
+    set VSCODE_USER /home/(whoami)/.vscode-server/data/User
+# Flatpak
+else if test -d $HOME/.var/app/com.visualstudio.code/config/Code/User
+    set VSCODE_USER $HOME/.var/app/com.visualstudio.code/config/Code/User
+# Standard Linux
+else
+    set VSCODE_USER $HOME/.config/Code/User
+end
+
+echo "VS Code User dir: $VSCODE_USER"
+
+# ── 2. User settings.json mergen / anlegen ────────────────────────────────────
+if test -f $VSCODE_USER/settings.json
+    echo "  ─ settings.json exists – skipping (merge manually if needed)"
+    echo "    Reference: $REPO_DIR/user-settings/settings.json"
+else
+    mkdir -p $VSCODE_USER
+    cp $REPO_DIR/user-settings/settings.json $VSCODE_USER/settings.json
+    echo "  ✓ settings.json deployed"
+end
+
+# ── 3. Prompt Files ───────────────────────────────────────────────────────────
+mkdir -p $VSCODE_USER/prompts
+for f in $REPO_DIR/prompts/*.prompt.md
+    set fname (basename $f)
+    if test -f $VSCODE_USER/prompts/$fname
+        echo "  ─ prompts/$fname already exists, skipping"
+    else
+        cp $f $VSCODE_USER/prompts/$fname
+        echo "  ✓ prompts/$fname deployed"
+    end
+end
+
+# ── 4. Git-Templates ──────────────────────────────────────────────────────────
+set GIT_TEMPLATE_DIR $HOME/.git-templates
+mkdir -p $GIT_TEMPLATE_DIR/.github $GIT_TEMPLATE_DIR/.vscode
+cp $REPO_DIR/git-templates/.github/copilot-instructions.md $GIT_TEMPLATE_DIR/.github/
+cp $REPO_DIR/git-templates/.vscode/settings.json $GIT_TEMPLATE_DIR/.vscode/
+cp $REPO_DIR/git-templates/.vscode/extensions.json $GIT_TEMPLATE_DIR/.vscode/
+git config --global init.templateDir $GIT_TEMPLATE_DIR
+echo "  ✓ git-templates deployed → $GIT_TEMPLATE_DIR"
+echo "  ✓ git config init.templateDir set"
+
+# ── 5. Bootstrap-Skript ───────────────────────────────────────────────────────
+mkdir -p $HOME/.local/bin
+cp $REPO_DIR/scripts/copilot-bootstrap.fish $HOME/.local/bin/copilot-bootstrap.fish
+chmod +x $HOME/.local/bin/copilot-bootstrap.fish
+echo "  ✓ copilot-bootstrap.fish installed to ~/.local/bin/"
+
+echo ""
+echo "=== Done ==="
+echo "Next: Activate Settings Sync in VS Code (Ctrl+Shift+P → 'Settings Sync: Turn On')"
--- a/scripts/deploy.sh
+++ b/scripts/deploy.sh
@ -0,0 +1,65 @@
+#!/usr/bin/env bash
+# deploy.sh – Copilot-Setup auf macOS oder Linux mit bash deployen
+# Usage: bash scripts/deploy.sh
+
+set -euo pipefail
+
+REPO_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")/.." && pwd)"
+echo "=== Copilot Setup Deploy (bash) ==="
+echo "Source: $REPO_DIR"
+
+# ── 1. VS Code User-Verzeichnis ermitteln ─────────────────────────────────────
+if [[ "$OSTYPE" == "darwin"* ]]; then
+    VSCODE_USER="$HOME/Library/Application Support/Code/User"
+    # VS Code Server (Cursor, Codium, etc.)
+    VSCODE_USER_ALT="$HOME/Library/Application Support/Cursor/User"
+elif [[ -d "$HOME/.vscode-server/data/User" ]]; then
+    # Remote / VS Code Server
+    VSCODE_USER="$HOME/.vscode-server/data/User"
+else
+    VSCODE_USER="$HOME/.config/Code/User"
+fi
+
+echo "VS Code User dir: $VSCODE_USER"
+mkdir -p "$VSCODE_USER"
+
+# ── 2. User settings.json ─────────────────────────────────────────────────────
+if [[ -f "$VSCODE_USER/settings.json" ]]; then
+    echo "  ─ settings.json exists – skipping (merge manually if needed)"
+    echo "    Reference: $REPO_DIR/user-settings/settings.json"
+else
+    cp "$REPO_DIR/user-settings/settings.json" "$VSCODE_USER/settings.json"
+    echo "  ✓ settings.json deployed"
+fi
+
+# ── 3. Prompt Files ───────────────────────────────────────────────────────────
+mkdir -p "$VSCODE_USER/prompts"
+for f in "$REPO_DIR/prompts/"*.prompt.md; do
+    fname="$(basename "$f")"
+    if [[ -f "$VSCODE_USER/prompts/$fname" ]]; then
+        echo "  ─ prompts/$fname already exists, skipping"
+    else
+        cp "$f" "$VSCODE_USER/prompts/$fname"
+        echo "  ✓ prompts/$fname deployed"
+    fi
+done
+
+# ── 4. Git-Templates ──────────────────────────────────────────────────────────
+GIT_TEMPLATE_DIR="$HOME/.git-templates"
+mkdir -p "$GIT_TEMPLATE_DIR/.github" "$GIT_TEMPLATE_DIR/.vscode"
+cp "$REPO_DIR/git-templates/.github/copilot-instructions.md" "$GIT_TEMPLATE_DIR/.github/"
+cp "$REPO_DIR/git-templates/.vscode/settings.json" "$GIT_TEMPLATE_DIR/.vscode/"
+cp "$REPO_DIR/git-templates/.vscode/extensions.json" "$GIT_TEMPLATE_DIR/.vscode/"
+git config --global init.templateDir "$GIT_TEMPLATE_DIR"
+echo "  ✓ git-templates deployed → $GIT_TEMPLATE_DIR"
+echo "  ✓ git config init.templateDir set"
+
+# ── 5. Bootstrap-Skript ───────────────────────────────────────────────────────
+mkdir -p "$HOME/.local/bin"
+cp "$REPO_DIR/scripts/copilot-bootstrap.fish" "$HOME/.local/bin/copilot-bootstrap.fish"
+chmod +x "$HOME/.local/bin/copilot-bootstrap.fish"
+echo "  ✓ copilot-bootstrap.fish installed to ~/.local/bin/"
+
+echo ""
+echo "=== Done ==="
+echo "Next: Activate Settings Sync in VS Code (Cmd+Shift+P → 'Settings Sync: Turn On')"
--- a/user-settings/settings.json
+++ b/user-settings/settings.json
@ -0,0 +1,71 @@
+{
+    // ── Copilot: Agent & Features (gilt für ALLE Workspaces) ─────────────
+    "github.copilot.chat.agent.runTasks": true,
+    "github.copilot.chat.codesearch.enabled": true,
+    "github.copilot.chat.search.semanticTextResults": true,
+    "github.copilot.chat.editor.temporalContext.enabled": true,
+    "github.copilot.chat.scopeSelection": "multipleFiles",
+    "github.copilot.chat.codeGeneration.useInstructionFiles": true,
+    // ── Senior Dev Team Grundverhalten – gilt für JEDE Interaktion ────────
+    "github.copilot.chat.codeGeneration.instructions": [
+        {
+            "text": "You are part of a team of senior engineers with high standards. Never implement anything without first understanding the full context. Read relevant existing code before writing new code."
+        },
+        {
+            "text": "Requirements first: If a request is ambiguous, ask clarifying questions before writing code. Identify: (1) What is the expected behavior? (2) What are the edge cases? (3) What are the non-functional requirements (performance, security, scalability)?"
+        },
+        {
+            "text": "Architecture before implementation: For any non-trivial change, briefly state the architectural approach and why. If multiple approaches exist, name the trade-offs and recommend one. Never just start coding."
+        },
+        {
+            "text": "Testing is not optional: Every function gets a test. Use the test pyramid: many unit tests, fewer integration tests, minimal e2e. Write tests before or alongside implementation, never after as an afterthought."
+        },
+        {
+            "text": "Definition of Done: A task is only done when: code works, tests pass, no linter errors, relevant documentation updated, commit message follows Conventional Commits."
+        },
+        {
+            "text": "Security first: Apply OWASP Top 10 thinking to every change. No secrets in code. Validate all inputs at system boundaries. Principle of least privilege."
+        },
+        {
+            "text": "No over-engineering: Implement the simplest solution that satisfies the requirements. No speculative features, no premature abstractions. YAGNI."
+        },
+        {
+            "text": "Code comments explain WHY, not WHAT. The code itself should be readable enough to explain what it does. Document surprising decisions and non-obvious constraints."
+        },
+        {
+            "text": "Responses: short and precise. No padding, no repetition. Code comments in English. Chat explanations can be in German."
+        }
+    ],
+    // Commit-Messages immer als Conventional Commits
+    "github.copilot.chat.commitMessageGeneration.instructions": [
+        {
+            "text": "Conventional Commits: type(scope): description. Types: feat|fix|chore|docs|refactor|test|ci. Scope optional aber hilfreich. Imperativ, max 72 Zeichen."
+        }
+    ],
+    // Review: Security-fokussiert mit Severity-Levels
+    "github.copilot.chat.reviewSelection.instructions": [
+        {
+            "text": "Security-first Review. OWASP Top 10 immer prüfen. Format für jeden Fund: [CRITICAL|HIGH|MEDIUM|LOW] datei:zeile – Problem: ... – Fix: ..."
+        }
+    ],
+    // Tests: Klare Struktur, Verhalten nicht Implementation testen
+    "github.copilot.chat.testGeneration.instructions": [
+        {
+            "text": "Tests mit Arrange/Act/Assert. Ein Test = ein Verhalten. Test-Namen beschreiben erwartetes Ergebnis: 'should return X when Y'. Keine Implementation-Details testen."
+        }
+    ],
+    // ── Completions: wo aktiv, wo nicht ──────────────────────────────────
+    "github.copilot.enable": {
+        "*": true,
+        "plaintext": false,
+        "markdown": true,
+        "yaml": true,
+        "dockerfile": true,
+        "dotenv": false
+    },
+    // ── Editor-Defaults ───────────────────────────────────────────────────
+    "editor.formatOnSave": true,
+    "files.trimTrailingWhitespace": true,
+    "files.insertFinalNewline": true,
+    "git.autofetch": true
+}