commit 9838c7a0b3b5157cc6647daf3df95e0763731a5a Author: Conrad Schulz Date: Fri May 29 08:19:50 2026 +0000 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 diff --git a/.gitignore b/.gitignore new file mode 100644 index 0000000..c25e649 --- /dev/null +++ b/.gitignore @@ -0,0 +1,2 @@ +.env +*.local diff --git a/README.md b/README.md new file mode 100644 index 0000000..986455d --- /dev/null +++ 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 ~/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/-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. diff --git a/git-templates/.github/copilot-instructions.md b/git-templates/.github/copilot-instructions.md new file mode 100644 index 0000000..a3baeb4 --- /dev/null +++ b/git-templates/.github/copilot-instructions.md @@ -0,0 +1,76 @@ +# GitHub Copilot – Project Instructions + +## Project + + +## Stack + +- Language: +- Framework: +- Database: +- Infrastructure: + +## Architecture + +- Pattern (MVC / Hexagonal / Event-driven / ...): +- Key constraints: +- ADR location: `docs/adr/` + +## Conventions + +- Branch naming: `feat/-description`, `fix/-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 + +- 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 + +- Response time: +- Availability: +- Data retention: diff --git a/git-templates/.vscode/extensions.json b/git-templates/.vscode/extensions.json new file mode 100644 index 0000000..6c5e755 --- /dev/null +++ b/git-templates/.vscode/extensions.json @@ -0,0 +1,6 @@ +{ + "recommendations": [ + "github.copilot", + "github.copilot-chat" + ] +} diff --git a/git-templates/.vscode/settings.json b/git-templates/.vscode/settings.json new file mode 100644 index 0000000..a641e7a --- /dev/null +++ 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": {} +} diff --git a/prompts/architecture.prompt.md b/prompts/architecture.prompt.md new file mode 100644 index 0000000..c55945e --- /dev/null +++ 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. diff --git a/prompts/code-review.prompt.md b/prompts/code-review.prompt.md new file mode 100644 index 0000000..7b160f5 --- /dev/null +++ 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. diff --git a/prompts/debug.prompt.md b/prompts/debug.prompt.md new file mode 100644 index 0000000..a669abf --- /dev/null +++ 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 diff --git a/prompts/docker.prompt.md b/prompts/docker.prompt.md new file mode 100644 index 0000000..6351cab --- /dev/null +++ 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) diff --git a/prompts/done-check.prompt.md b/prompts/done-check.prompt.md new file mode 100644 index 0000000..8373ba8 --- /dev/null +++ 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. diff --git a/prompts/new-feature.prompt.md b/prompts/new-feature.prompt.md new file mode 100644 index 0000000..2f1337d --- /dev/null +++ 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 diff --git a/prompts/refactor.prompt.md b/prompts/refactor.prompt.md new file mode 100644 index 0000000..4c25d2f --- /dev/null +++ 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. diff --git a/prompts/requirements.prompt.md b/prompts/requirements.prompt.md new file mode 100644 index 0000000..df81559 --- /dev/null +++ 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 diff --git a/prompts/write-tests.prompt.md b/prompts/write-tests.prompt.md new file mode 100644 index 0000000..b8b2c3d --- /dev/null +++ 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 diff --git a/scripts/copilot-bootstrap.fish b/scripts/copilot-bootstrap.fish new file mode 100755 index 0000000..eb4cd8d --- /dev/null +++ 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'" diff --git a/scripts/deploy.fish b/scripts/deploy.fish new file mode 100644 index 0000000..491ddff --- /dev/null +++ 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')" diff --git a/scripts/deploy.sh b/scripts/deploy.sh new file mode 100644 index 0000000..8e5c673 --- /dev/null +++ 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')" diff --git a/user-settings/settings.json b/user-settings/settings.json new file mode 100644 index 0000000..7ee4861 --- /dev/null +++ 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 +} \ No newline at end of file