Conrad Schulz
2a72e08c13
- Add .github/copilot-instructions.md with project-specific context - Add .github/prompts/ with 9 reusable agent prompt files - Add .vscode/extensions.json recommending copilot extensions - Update .vscode/settings.json with rulers and YAML schema - Remove tracked .DS_Store
88 lines
2.2 KiB
Markdown
88 lines
2.2 KiB
Markdown
---
|
||
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
|