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
This commit is contained in:
commit
9838c7a0b3
18 changed files with 975 additions and 0 deletions
2
.gitignore
vendored
Normal file
2
.gitignore
vendored
Normal file
|
|
@ -0,0 +1,2 @@
|
||||||
|
.env
|
||||||
|
*.local
|
||||||
166
README.md
Normal file
166
README.md
Normal file
|
|
@ -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.
|
||||||
76
git-templates/.github/copilot-instructions.md
vendored
Normal file
76
git-templates/.github/copilot-instructions.md
vendored
Normal file
|
|
@ -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:
|
||||||
6
git-templates/.vscode/extensions.json
vendored
Normal file
6
git-templates/.vscode/extensions.json
vendored
Normal file
|
|
@ -0,0 +1,6 @@
|
||||||
|
{
|
||||||
|
"recommendations": [
|
||||||
|
"github.copilot",
|
||||||
|
"github.copilot-chat"
|
||||||
|
]
|
||||||
|
}
|
||||||
7
git-templates/.vscode/settings.json
vendored
Normal file
7
git-templates/.vscode/settings.json
vendored
Normal file
|
|
@ -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": {}
|
||||||
|
}
|
||||||
66
prompts/architecture.prompt.md
Normal file
66
prompts/architecture.prompt.md
Normal file
|
|
@ -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.
|
||||||
46
prompts/code-review.prompt.md
Normal file
46
prompts/code-review.prompt.md
Normal file
|
|
@ -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.
|
||||||
32
prompts/debug.prompt.md
Normal file
32
prompts/debug.prompt.md
Normal file
|
|
@ -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
|
||||||
30
prompts/docker.prompt.md
Normal file
30
prompts/docker.prompt.md
Normal file
|
|
@ -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)
|
||||||
66
prompts/done-check.prompt.md
Normal file
66
prompts/done-check.prompt.md
Normal file
|
|
@ -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.
|
||||||
88
prompts/new-feature.prompt.md
Normal file
88
prompts/new-feature.prompt.md
Normal file
|
|
@ -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
|
||||||
33
prompts/refactor.prompt.md
Normal file
33
prompts/refactor.prompt.md
Normal file
|
|
@ -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.
|
||||||
73
prompts/requirements.prompt.md
Normal file
73
prompts/requirements.prompt.md
Normal file
|
|
@ -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
|
||||||
34
prompts/write-tests.prompt.md
Normal file
34
prompts/write-tests.prompt.md
Normal file
|
|
@ -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
|
||||||
49
scripts/copilot-bootstrap.fish
Executable file
49
scripts/copilot-bootstrap.fish
Executable file
|
|
@ -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'"
|
||||||
65
scripts/deploy.fish
Normal file
65
scripts/deploy.fish
Normal file
|
|
@ -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')"
|
||||||
65
scripts/deploy.sh
Normal file
65
scripts/deploy.sh
Normal file
|
|
@ -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')"
|
||||||
71
user-settings/settings.json
Normal file
71
user-settings/settings.json
Normal file
|
|
@ -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
|
||||||
|
}
|
||||||
Loading…
Add table
Reference in a new issue