feat: pipeline improvements + remove deployment phase

- Complexity Gate: S/M/L in Phase 1, S skips QA, L needs Martin approval - Max 3 fix cycles, then pause and ask Martin - KI self-review disclaimer in Code Review - Removed Phase 7 (Deployment) entirely - Renumbered: 7 phases instead of 9 - Updated all skills with new phase numbers
2026-05-10 20:37:13 +00:00
parent d57e6f0418
commit f94cfb41e6
10 changed files with 131 additions and 163 deletions
--- a/skills/gitea-abnahme-validierung/SKILL.md
+++ b/skills/gitea-abnahme-validierung/SKILL.md
@@ -5,10 +5,10 @@ description: Abnahme- & Validierungs-Agent für Gitea Issues. Validiert Anforder

 # Abnahme- & Validierungs-Agent

-Rolle: Siebte Phase – nach erfolgreichem Deployment. Stellt sicher, dass die Lösung das Problem wirklich löst.
+Rolle: Phase 6 – nach gemergtem Code. Stellt sicher, dass die Lösung das Problem wirklich löst.

 ## Eingang
- Deployte Anwendung in Zielumgebung
+- Gemergter PR / Release-Tag
 - Spezifikation: `memory/gitea-specs/issue-<number>.md`
 - Original-Issue von Gitea

@@ -51,31 +51,29 @@ Rolle: Siebte Phase – nach erfolgreichem Deployment. Stellt sicher, dass die L
 - Lizenzpflichtige Dependencies dokumentiert?

 ### Freigabetests durchführen
- Endgültiger Smoke Test auf Production/Staging
+- Finaler Check des gemergten Stands
 - Keine Regressions in bestehenden Features
- Performance akzeptabel unter realen Bedingungen
- Keine Error-Spikes in Monitoring
+- Keine offensichtlichen Fehler

 ### Stakeholder-Feedback auswerten
 - Falls Martin bereits getestet hat: Feedback einarbeiten
- Bei neuen Anforderungen: Neues Issue erstellen (nicht scope creepen)
+- Bei neuen Anforderungen: Neues Issue erstellen (kein Scope Creep)

 ### Produktionsverhalten kontrollieren
- Logs auf Unexpected Errors prüfen
- Metriken stabil?
- Keine Alarme ausgelöst?
- Nutzer-Reports prüfen falls vorhanden
+- Code-Stand auf `main` nach Merge prüfen
+- Build/CI-Status grün?
+- Keine Warnungen die übersehen wurden

 ### Release-Abnahme dokumentieren
 - Validierungsbericht in `memory/gitea-specs/issue-<number>-validation.md`
 - Ergebnis: **ACCEPTED** oder **REJECTED**
 - Bei ACCEPTED: Freigabe für Dokumentation
- Bei REJECTED: Begründung + ⏩ zurück zum Implementierungs-Agent
+- Bei REJECTED: Begründung + ⏩ zurück zum Implementierungs-Agent (Phase 2)

 ## Ausgang
 - Validierungsbericht: `memory/gitea-specs/issue-<number>-validation.md`
- Status: **ACCEPTED** → ⏩ Dokumentations- & Closing-Agent
- Status: **REJECTED** → ⏩ Implementierungs-Agent mit Begründung
+- Status: **ACCEPTED** → ⏩ Dokumentations- & Closing-Agent (Phase 7)
+- Status: **REJECTED** → ⏩ Implementierungs-Agent (Phase 2) mit Begründung

 ## Regeln
 - Immer aus Nutzersicht prüfen, nicht aus Entwicklersicht
--- a/skills/gitea-analyse-architektur/SKILL.md
+++ b/skills/gitea-analyse-architektur/SKILL.md
@@ -5,12 +5,24 @@ description: Analyse- & Architektur-Agent für Gitea Issues. Analysiert Anforder

 # Analyse- & Architektur-Agent

-Rolle: Erste Phase der Gitea Issue Pipeline. Analysiert das Issue und erstellt die Grundlage für alle folgenden Phasen.
+Rolle: Erste Phase der Gitea Issue Pipeline. Analysiert das Issue, bewertet die Komplexität und erstellt die Grundlage für alle folgenden Phasen.

 ## Eingang
 - Gitea Issue **nur** mit Label `KI`
 - Issue-Body, Kommentare, verlinkte Ressourcen

+## Complexity Gate
+
+**Pflicht am Anfang:** Bewerte die Komplexität des Issues:
+
+| Level | Kriterien | Auswirkung auf Pipeline |
+|---|---|---|
+| **S** (Small) | Typo-Fix, Config-Änderung, einfacher Bugfix, < 30min geschätzt | Überspringt Phase 4 (Test & QA). Nach Review direkt zu Merge. |
+| **M** (Medium) | Neues Feature, Refactoring, API-Änderung, 30min–4h | Volle Pipeline. |
+| **L** (Large) | Architektur-Änderung, neues Modul, DB-Migration, > 4h | Volle Pipeline + Martin muss Analyse freigeben bevor Implementierung startet. |
+
+Komplexität ins Issue schreiben und im Spezifikationsdokument festhalten.
+
 ## Aufgaben

 ### Anforderungen analysieren
@@ -83,7 +95,7 @@ Rolle: Erste Phase der Gitea Issue Pipeline. Analysiert das Issue und erstellt d

 ## Ausgang
 - Spezifikationsdokument: `memory/gitea-specs/issue-<number>.md`
- **Issue aktualisieren** mit allen Erkenntnissen (Architektur, Teilaufgaben, Akzeptanzkriterien, etc.)
+- **Issue aktualisieren** mit allen Erkenntnissen (Komplexität, Architektur, Teilaufgaben, Akzeptanzkriterien, etc.)
 - Spezifikation als Kommentar ins Issue geschrieben
 - Dem Issue den Tag **`ReadyForDev`** hinzufügen:
 ```bash
@@ -99,3 +111,4 @@ curl -s -X POST "https://git.home.kies-media.de/api/v1/repos/<owner>/<repo>/issu
 - Spezifikation muss für den Implementierungs-Agent ohne Rückfragen umsetzbar sein
 - Sicherheitsrelevante Entscheidungen dokumentieren und Martin zur Freigabe vorlegen
 - Tag `ReadyForDev` **erst** hinzufügen, wenn Analyse & Architektur vollständig abgeschlossen
+- **Bei Komplexität L:** Martin muss die Analyse freigeben bevor `ReadyForDev` gesetzt wird
--- a/skills/gitea-code-review/SKILL.md
+++ b/skills/gitea-code-review/SKILL.md
@@ -5,7 +5,16 @@ description: Code-Review-Agent für Gitea Issues. Prüft Codequalität, Sicherhe

 # Code-Review-Agent

-Rolle: Dritte Phase der Gitea Issue Pipeline. Qualitätssicherung vor dem Test.
+Rolle: Phase 3 der Gitea Issue Pipeline. Qualitätssicherung vor dem Test.
+
+## Wichtiger Hinweis: KI reviewt KI
+
+Dieser Agent führt ein **Self-Review** durch – die KI prüft ihren eigenen Code. Das ist besser als kein Review, aber **kein echter Gatekeeper**.
+
+- Bei **kritischen Änderungen** (Sicherheit, Finanzen, Auth, DB-Schema): Martin bitten, selbst zu reviewen
+- Bei **Komplexität L**: Martin muss den Review bestätigen bevor weitergegangen wird
+- Self-Review fängt offensichtliche Bugs, Style-Issues und Sicherheitsbasics ab
+- Subtile Logikfehler können durchgehen

 ## Eingang
 - Feature Branch mit Implementierung
@@ -82,10 +91,13 @@ Rolle: Dritte Phase der Gitea Issue Pipeline. Qualitätssicherung vor dem Test.
 ## Ausgang
 - Review-Ergebnis dokumentiert in `memory/gitea-specs/issue-<number>-review.md`
 - Status: **APPROVED** oder **CHANGES_REQUESTED**
- Bei APPROVED: ⏩ Übergabe an **Test- & QA-Agent**
- Bei CHANGES_REQUESTED: ⏩ Übergabe an **Fix- & Refactoring-Agent**
+- Bei APPROVED:
+  - Komplexität **S**: ⏩ direkte Übergabe an **Merge- & Release-Agent** (Phase 5)
+  - Komplexität **M/L**: ⏩ Übergabe an **Test- & QA-Agent** (Phase 4)
+- Bei CHANGES_REQUESTED: ⏩ Übergabe an **Fix- & Refactoring-Agent** (Phase 4-fix)

 ## Regeln
 - Immer konstruktiv – Review ist Hilfe, nicht Kritik
 - Keine stilistischen Nitpicks als Blocker
 - Sicherheitsprobleme sind immer 🔴 Must-Fix
+- Bei kritischen Änderungen: Martin zur Review-Bestätigung auffordern
--- a/skills/gitea-deployment/SKILL.md
+++ b/skills/gitea-deployment/SKILL.md
@@ -1,89 +0,0 @@
---
-name: gitea-deployment
-description: Deployment-Agent für Gitea Issues. Deployt Anwendungen, konfiguriert Infrastruktur und überwacht den Rollout. Teil der Gitea Issue Pipeline.
---
-
-# Deployment-Agent
-
-Rolle: Sechste Phase – nach Merge und Release. Kümmert sich um das Deployment in die Zielumgebung.
-
-## Eingang
- Gemergter PR / Release-Tag
- Release Notes
- Zielumgebung (dev/staging/production)
-
-## Aufgaben
-
-### Anwendungen deployen
- Deployment-Methoden: Docker, Docker Compose, K8s, Direct Deploy
- Blue-Green oder Rolling Update wo möglich
- Deployment-Befehl ausführen und überwachen
-
-### Infrastruktur konfigurieren
- Umgebungsvariablen setzen
- Konfigurationsdateien aktualisieren
- Service-Abhängigkeiten prüfen (Datenbank, Cache, etc.)
- Netzwerk/Firewall-Regeln falls nötig
-
-### Container verwalten
- Neues Image bauen: `docker build -t <image>:<version> .`
- Image pushen: `docker push <registry>/<image>:<version>`
- Container starten/neustarten
- Health des Containers prüfen
-
-### Rollbacks durchführen
- Bei Fehlern: sofortiges Rollback auf vorherige Version
- Vorherige Version/Image bereithalten
- Rollback-Befehl dokumentiert
- Martin bei Rollback sofort informieren
-
-### Secrets verwalten
- Neue Secrets in die Zielumgebung eintragen
- Keine Secrets in Config-Dateien oder Images
- Secrets rotieren falls nötig
- `.env`-Dateien nicht im Repo
-
-### Umgebungen synchronisieren
- Konfigurationsdrift vermeiden
- Staging vor Production deployen
- Prod-Parität des Staging sicherstellen
-
-### Datenbankmigrationen ausführen
- Migrationen automatisch oder manuell laufen lassen
- Backup vor Migration
- Migration-Output prüfen
- Bei Fehler: Rollback + Martin informieren
-
-### Monitoring aktivieren
- Logs prüfen nach Deployment
- Metriken/Alermts aktualisieren
- Dashboards bei neuen Metriken erweitern
- Error-Rate nach Deploy überwachen
-
-### Skalierung konfigurieren
- Ressourcenlimits anpassen falls nötig
- Auto-Scaling-Regeln aktualisieren
- Load Balancer Konfiguration prüfen
-
-### Deployment-Logs analysieren
- Logs auf Errors/Warnungen scannen
- Anomalien erkennen
- Erfolgreiches Deployment bestätigen
-
-### Health Checks durchführen
- Endpoint-Health prüfen (`/health`, `/ready`)
- Datenbankverbindung testen
- Externe API-Erreichbarkeit testen
- Smoke Tests ausführen
-
-## Ausgang
- Deployment erfolgreich und verifiziert
- Health Checks bestanden
- Martin informiert über erfolgreiches Deployment
- ⏩ Übergabe an **Abnahme- & Validierungs-Agent**
-
-## Regeln
- **Immer** Staging vor Production
- **Immer** Backup vor Migration
- **Immer** Rollback-Plan bereit
- **Sofort** Martin informieren bei Problemen
--- a/skills/gitea-dokumentation-closing/SKILL.md
+++ b/skills/gitea-dokumentation-closing/SKILL.md
@@ -5,13 +5,13 @@ description: Dokumentations- & Closing-Agent für Gitea Issues. Erstellt Dokumen

 # Dokumentations- & Closing-Agent

-Rolle: Letzte Phase – nach erfolgreicher Abnahme. Dokumentiert alles und schließt den Kreis.
+Rolle: Phase 7 – nach erfolgreicher Abnahme. Dokumentiert alles und schließt den Kreis.

 ## Eingang
 - Validierungsbericht: ACCEPTED
 - Spezifikation: `memory/gitea-specs/issue-<number>.md`
 - Review, QA-Reports
- Deployte und validierte Lösung
+- Gemergter und validierter Code

 ## Aufgaben

@@ -42,7 +42,7 @@ Rolle: Letzte Phase – nach erfolgreicher Abnahme. Dokumentiert alles und schli
 - Breaking Changes hervorgehoben

 ### Betriebsdokumentation schreiben
- Deploy-Prozess beschrieben
+- Deploy-/Start-Prozess beschrieben
 - Umgebungsvariablen dokumentiert
 - Backup/Restore-Verfahren
 - Monitoring & Alerting
@@ -75,12 +75,12 @@ curl -s -X PATCH "https://git.home.kies-media.de/api/v1/repos/<owner>/<repo>/iss
 - Neue Erkenntnisse in `memory/` speichern
 - Lessons Learned festhalten
 - Best Practices aktualisieren
- `MEMORY.md` bei relevanten learnings updaten
+- `MEMORY.md` bei relevanten Learnings updaten

 ### Abschlussberichte generieren
 - Zusammenfassung des gesamten Issue-Lebenszyklus
 - Was wurde gemacht, warum, mit welchem Ergebnis
- Aufwand (Zeit/Commits/Reviews)
+- Aufwand (Commits/Reviews/Zyklen)
 - In `memory/gitea-specs/issue-<number>-final.md`

 ### Tickets schließen
--- a/skills/gitea-fix-refactoring/SKILL.md
+++ b/skills/gitea-fix-refactoring/SKILL.md
@@ -11,6 +11,23 @@ Rolle: Wird bei Bedarf eingeschaltet – nach Code Review mit Änderungswünsche
 - Feature Branch mit Änderungswünschen
 - Review-Kommentare: `memory/gitea-specs/issue-<number>-review.md` (CHANGES_REQUESTED)
 - oder QA-Report: `memory/gitea-specs/issue-<number>-qa.md` (FAIL)
+- Zyklus-Counter (wie oft bereits Fix → Review/QA durchlaufen)
+
+## Zyklus-Limit
+
+**Maximal 3 Fix-Zyklen.** Danach:
+
+1. Fix-Zyklus abbrechen
+2. Zusammenfassung erstellen was hängt:
+   - Welche Probleme sind offen?
+   - Woran scheitert es?
+   - Was wurde schon versucht?
+3. **Martin informieren und auf seine Entscheidung warten:**
+   - Weitere 3 Zyklen genehmigen
+   - Issue manuell übernehmen
+   - Issue zurückstellen / schließen
+
+Zyklus-Counter dokumentieren in `memory/gitea-specs/issue-<number>-fix-cycles.md`.

 ## Aufgaben

@@ -78,11 +95,14 @@ Rolle: Wird bei Bedarf eingeschaltet – nach Code Review mit Änderungswünsche
 ## Ausgang
 - Alle Fixes auf Feature Branch committet
 - Änderungen dokumentiert
+- Zyklus-Counter inkrementiert
 - ⏩ Zurück an den Agent der das Feedback gegeben hat:
-  - Bei Review-Feedback → **Code-Review-Agent**
-  - Bei QA-Fail → **Test- & QA-Agent**
+  - Bei Review-Feedback → **Code-Review-Agent** (Phase 3)
+  - Bei QA-Fail → **Test- & QA-Agent** (Phase 4)
+- Bei Zyklus > 3: ⏸ Pause + Martin informieren

 ## Regeln
 - Ein Fix = ein Commit (atomic)
 - Kein Refactoring ohne klaren Grund
 - Bei Unsicherheit: Martin fragen
+- Zyklus-Limit **strikt** einhalten – keine Endlosschleifen
--- a/skills/gitea-issue-resolver/SKILL.md
+++ b/skills/gitea-issue-resolver/SKILL.md
@@ -1,11 +1,11 @@
 ---
 name: gitea-issue-resolver
-description: Pipeline-Orchestrator für Gitea Issues. Koordiniert die 9 Agenten-Phasen von der Analyse bis zum Closing. Use when checking or working on issues in Martin's Gitea repos (git.home.kies-media.de). Triggers on mentions of "issues", "Gitea issues", or when checking repos for open issues.
+description: Pipeline-Orchestrator für Gitea Issues. Koordiniert die 7 Agenten-Phasen von der Analyse bis zum Closing. Use when checking or working on issues in Martin's Gitea repos (git.home.kies-media.de). Triggers on mentions of "issues", "Gitea issues", or when checking repos for open issues.
 ---

 # Gitea Issue Resolver – Pipeline Orchestrator

-Koordiniert die gesamte Issue-Pipeline. Holt Issues ab und steuert sie durch die 9 Phasen.
+Koordiniert die gesamte Issue-Pipeline. Holt Issues ab und steuert sie durch die Phasen.

 ## Authentication

@@ -21,7 +21,17 @@ Gitea API token: `$GITEA_TOKEN` (in `.bashrc`):
 GITEA_TOKEN="568841…2e34"
 ```

-## Pipeline – 9 Phasen
+## Complexity Gate
+
+Phase 1 bewertet die Komplexität. Das bestimmt den Pipeline-Verlauf:
+
+| Komplexität | Pipeline |
+|---|---|
+| **S** (Small) | Phase 1 → 2 → 3 → 5 → 6 → 7 *(überspringt QA)* |
+| **M** (Medium) | Phase 1 → 2 → 3 → 4 → 5 → 6 → 7 *(volle Pipeline)* |
+| **L** (Large) | Phase 1 → **Martin-Freigabe** → 2 → 3 → 4 → 5 → 6 → 7 *(Analyse muss freigegeben werden)* |
+
+## Pipeline – 7 Phasen

 ### Issue-Filter
 Phase 1 (Analyse) holt Issues **nur** mit Tag `KI`:
@@ -34,9 +44,10 @@ curl -s "https://git.home.kies-media.de/api/v1/repos/<owner>/<repo>/issues?state
 Ab Phase 2 (Implementierung) werden nur Issues mit **beiden** Tags `KI` + `ReadyForDev` weiterverarbeitet (wird von Phase 1 gesetzt).

 ### Phase 1: Analyse- & Architektur-Agent → `gitea-analyse-architektur`
- Anforderungen analysieren
- Architektur entwerfen
- Spezifikation erstellen
+- Complexity Gate: S / M / L bewerten
+- Anforderungen analysieren, Architektur entwerfen
+- Spezifikation erstellen + ins Issue schreiben
+- Tag `ReadyForDev` hinzufügen (bei L: erst nach Martins Freigabe)
 - Output: `memory/gitea-specs/issue-<number>.md`

 ### Phase 2: Implementierungs-Agent → `gitea-implementierung`
@@ -47,35 +58,32 @@ Ab Phase 2 (Implementierung) werden nur Issues mit **beiden** Tags `KI` + `Ready

 ### Phase 3: Code-Review-Agent → `gitea-code-review`
 - Codequalität & Sicherheit prüfen
+- Self-Review (bei kritischen Änderungen: Martin bitten)
 - Review-Kommentare erstellen
 - Output: APPROVED oder CHANGES_REQUESTED

-### Phase 4: Test- & QA-Agent → `gitea-test-qa`
+### Phase 4: Test- & QA-Agent → `gitea-test-qa` *(übersprungen bei S)*
 - Unit-, Integration-, E2E-Tests
 - QA-Report erstellen
 - Output: PASS oder FAIL

-### Phase 5: Fix- & Refactoring-Agent → `gitea-fix-refactoring` *(bei Bedarf)*
+### Phase 4-fix: Fix- & Refactoring-Agent → `gitea-fix-refactoring` *(bei Bedarf, max. 3 Zyklen)*
 - Review-Feedback umsetzen
 - Bugs korrigieren
+- Nach max. 3 Zyklen: Martin informieren
 - Danach zurück zur jeweiligen Phase (Review oder QA)

-### Phase 6: Merge- & Release-Agent → `gitea-merge-release`
+### Phase 5: Merge- & Release-Agent → `gitea-merge-release`
 - PR erstellen
 - Release Notes & Versionierung
- Warten auf Martins Freigabe
+- **Wartet auf Martins Freigabe**

-### Phase 7: Deployment-Agent → `gitea-deployment`
- Anwendungen deployen
- Health Checks
- Bei Problemen: Rollback
-
-### Phase 8: Abnahme- & Validierungs-Agent → `gitea-abnahme-validierung`
+### Phase 6: Abnahme- & Validierungs-Agent → `gitea-abnahme-validierung`
 - Anforderungen validieren
 - Akzeptanzkriterien abhaken
 - Output: ACCEPTED oder REJECTED

-### Phase 9: Dokumentations- & Closing-Agent → `gitea-dokumentation-closing`
+### Phase 7: Dokumentations- & Closing-Agent → `gitea-dokumentation-closing`
 - Dokumentation erstellen
 - Issue schließen
 - Abschlussbericht
@@ -83,48 +91,51 @@ Ab Phase 2 (Implementierung) werden nur Issues mit **beiden** Tags `KI` + `Ready
 ## Pipeline-Fluss

 ```
-Issue (KI + ReadyForDev)
+Issue (Label: KI)
  │
  ▼
-[1] Analyse & Architektur
+[1] Analyse & Architektur ──→ Complexity: S / M / L
+  │                              │          │         │
+  │ (setzt ReadyForDev)          S          M         L → Martin freigeben
+  │                              │          │              │
+  ▼                              ▼          ▼              ▼
+[2] Implementierung         ──────────────────────────────────
  │
  ▼
-[2] Implementierung
+[3] Code Review ──── CHANGES_REQUESTED ──→ [fix] Fix & Refactoring ──→ [3]
+  │ APPROVED              (max. 3 Zyklen, dann Martin fragen)
  │
-  ▼
-[3] Code Review ──── CHANGES_REQUESTED ──→ [5] Fix & Refactoring ──→ [3]
-  │ APPROVED
-  ▼
-[4] Test & QA ────── FAIL ──────────────→ [5] Fix & Refactoring ──→ [4]
+  ├─ S ──────────────────────────────────→ [5] Merge & Release
+  │
+  ▼ (M, L)
+[4] Test & QA ────── FAIL ──────────────→ [fix] Fix & Refactoring ──→ [4]
  │ PASS
  ▼
-[6] Merge & Release ( wartet auf Martins Freigabe )
+[5] Merge & Release (wartet auf Martins Freigabe)
  │
  ▼
-[7] Deployment
-  │
-  ▼
-[8] Abnahme & Validierung ── REJECTED ──→ [2] Implementierung
+[6] Abnahme & Validierung ── REJECTED ──→ [2] Implementierung
  │ ACCEPTED
  ▼
-[9] Dokumentation & Closing → Issue geschlossen ✅
+[7] Dokumentation & Closing → Issue geschlossen ✅
 ```

 ## Orchestrierung

 Für jedes Issue:
 1. Spezifikations-Verzeichnis erstellen: `mkdir -p memory/gitea-specs`
-2. Phasen sequenziell durchlaufen
-3. Bei Rücksprüngen (Fix-Phase) den Zyklus wiederholen
+2. Komplexität aus Phase 1 berücksichtigen für Pipeline-Verlauf
+3. Fix-Zyklen zählen, bei >3 abbrechen und Martin informieren
 4. Martin bei wichtigen Meilensteinen informieren:
-   - Spezifikation fertig (Phase 1)
-   - PR erstellt (Phase 6)
-   - Deployment erfolgreich (Phase 7)
-   - Issue geschlossen (Phase 9)
+   - Spezifikation fertig + Komplexität (Phase 1)
+   - PR erstellt (Phase 5)
+   - Issue geschlossen (Phase 7)

 ## Regeln
- **Nur** Issues mit Tags `KI` + `ReadyForDev`
+- Phase 1 filtert auf **nur** `KI`
+- Ab Phase 2: **nur** Issues mit `KI` + `ReadyForDev`
 - **Nie** ohne Martins Freigabe mergen
- **Nie** Issue selbst schließen (nur Phase 9 darf das)
+- **Nie** Issue selbst schließen (nur Phase 7 darf das)
 - **Nie** direkt auf `main` pushen
+- **Max. 3** Fix-Zyklen, dann Martin fragen
 - Bei Blockern: sofort Martin informieren
--- a/skills/gitea-merge-release/SKILL.md
+++ b/skills/gitea-merge-release/SKILL.md
@@ -5,11 +5,11 @@ description: Merge- & Release-Agent für Gitea Issues. Verwaltet Pull Requests,

 # Merge- & Release-Agent

-Rolle: Fünfte Phase – nach erfolgreichem Review und QA. Kümmert sich um Merge und Release-Vorbereitung.
+Rolle: Phase 5 – nach erfolgreichem Review und QA. Kümmert sich um Merge und Release-Vorbereitung.

 ## Eingang
- Feature Branch mit APPROVED Code und PASS-Status im QA
- QA-Report: `memory/gitea-specs/issue-<number>-qa.md` (PASS)
+- Feature Branch mit APPROVED Code und PASS-Status im QA (oder APPROVED bei Komplexität S ohne QA)
+- QA-Report: `memory/gitea-specs/issue-<number>-qa.md` (PASS) – falls vorhanden
 - Spezifikation: `memory/gitea-specs/issue-<number>.md`

 ## Aufgaben
@@ -67,13 +67,12 @@ git push origin v<version>
 ### CI/CD-Pipelines überwachen
 - Pipeline-Status nach Push prüfen
 - Bei Fehlern: Logs analysieren und beheben
- Bei Erfolg: Deployment-Phase einleiten
+- Bei Erfolg: weiter zur Abnahme

 ### Build-Artefakte validieren
 - Build erfolgreich?
 - Artefakt-Größe plausibel?
 - Checksummen verifizieren
- Signaturen wo nötig

 ### Release-Freigaben koordinieren
 - Martin über Release informieren
@@ -83,7 +82,7 @@ git push origin v<version>
 ## Ausgang
 - PR erstellt und Martin informiert
 - Warte auf Martins Merge-Freigabe
- Nach Freigabe: ⏩ Deployment-Agent
+- Nach Freigabe: ⏩ Abnahme- & Validierungs-Agent (Phase 6)

 ## Regeln
 - **NIEMALS** ohne Martins Freigabe mergen
--- a/skills/gitea-test-qa/SKILL.md
+++ b/skills/gitea-test-qa/SKILL.md
@@ -5,7 +5,10 @@ description: Test- & QA-Agent für Gitea Issues. Erstellt und führt Tests durch

 # Test- & QA-Agent

-Rolle: Vierte Phase der Gitea Issue Pipeline. Stellt sicher, dass die Implementierung korrekt und robust ist.
+Rolle: Phase 4 der Gitea Issue Pipeline. Stellt sicher, dass die Implementierung korrekt und robust ist.
+
+## Wird übersprungen bei
+- **Komplexität S:** Test & QA wird übersprungen, direkt nach Review (APPROVED) → Merge

 ## Eingang
 - Feature Branch mit APPROVED Code
@@ -24,7 +27,7 @@ Rolle: Vierte Phase der Gitea Issue Pipeline. Stellt sicher, dass die Implementi
 - Modulgrenzen testen
 - Datenbank-Integration prüfen
 - API-End-to-End innerhalb des Services
- externe API-Mocks nutzen
+- Externe API-Mocks nutzen

 ### E2E-Tests durchführen
 - Nutzerflows durchspielen
@@ -82,8 +85,8 @@ Rolle: Vierte Phase der Gitea Issue Pipeline. Stellt sicher, dass die Implementi
 ## Ausgang
 - Test-Code auf Feature Branch committet
 - QA-Report: `memory/gitea-specs/issue-<number>-qa.md`
- Status: **PASS** → ⏩ Merge- & Release-Agent
- Status: **FAIL** → ⏩ Fix- & Refactoring-Agent
+- Status: **PASS** → ⏩ Merge- & Release-Agent (Phase 5)
+- Status: **FAIL** → ⏩ Fix- & Refactoring-Agent (Phase 4-fix)

 ## Regeln
 - Keine Tests nur für die Statistik – jeder Test muss einen Wert haben