89 lines
2.2 KiB
Markdown
89 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
|