feat: split gitea-issue-resolver into 9 specialized agent skills + orchestrator

- gitea-analyse-architektur (Phase 1)
- gitea-implementierung (Phase 2)
- gitea-code-review (Phase 3)
- gitea-test-qa (Phase 4)
- gitea-fix-refactoring (Phase 5, on demand)
- gitea-merge-release (Phase 6)
- gitea-deployment (Phase 7)
- gitea-abnahme-validierung (Phase 8)
- gitea-dokumentation-closing (Phase 9)
- gitea-issue-resolver updated as pipeline orchestrator
- Only issues tagged KI + ReadyForDev are processed

skills/gitea-abnahme-validierung/SKILL.md

@@ -0,0 +1,83 @@
+---
+name: gitea-abnahme-validierung
+description: Abnahme- & Validierungs-Agent für Gitea Issues. Validiert Anforderungen, prüft Akzeptanzkriterien und führt Freigabetests durch. Teil der Gitea Issue Pipeline.
+---
+
+# Abnahme- & Validierungs-Agent
+
+Rolle: Siebte Phase – nach erfolgreichem Deployment. Stellt sicher, dass die Lösung das Problem wirklich löst.
+
+## Eingang
+- Deployte Anwendung in Zielumgebung
+- Spezifikation: `memory/gitea-specs/issue-<number>.md`
+- Original-Issue von Gitea
+
+## Aufgaben
+
+### Anforderungen validieren
+- Jede Anforderung aus dem Issue durchgehen
+- Ist die Anforderung in der Lösung umgesetzt?
+- Löst die Lösung das im Issue beschriebene Problem?
+- Gap-Analyse: Fehlt etwas?
+
+### Akzeptanzkriterien prüfen
+- Jedes Akzeptanzkriterium einzeln abhaken
+- Bei UI: visuell überprüfen
+- Bei API: Requests manuell/automatisiert senden
+- Bei Daten: korrekte Speicherung und Abrufbarkeit prüfen
+
+### Nutzerflows testen
+- Reale Nutzer-Szenarien durchspielen
+- Happy Path + Alternative Paths
+- Abbruch-Szenarien
+- Workflow von Anfang bis Ende
+
+### Business-Logik verifizieren
+- Berechnungen korrekt?
+- Zustandsübergänge wie spezifiziert?
+- Berechtigungen wie gefordert?
+- Edge Cases im Business-Kontext
+
+### UI/UX bewerten
+- Layout korrekt und konsistent?
+- Fehlermeldungen verständlich?
+- Ladezeiten akzeptabel?
+- Mobile Darstellung falls relevant
+
+### Compliance prüfen
+- Datenschutzanforderungen erfüllt?
+- Audit-Trail wo gefordert?
+- Protokollierungsvorschriften eingehalten?
+- Lizenzpflichtige Dependencies dokumentiert?
+
+### Freigabetests durchführen
+- Endgültiger Smoke Test auf Production/Staging
+- Keine Regressions in bestehenden Features
+- Performance akzeptabel unter realen Bedingungen
+- Keine Error-Spikes in Monitoring
+
+### Stakeholder-Feedback auswerten
+- Falls Martin bereits getestet hat: Feedback einarbeiten
+- Bei neuen Anforderungen: Neues Issue erstellen (nicht scope creepen)
+
+### Produktionsverhalten kontrollieren
+- Logs auf Unexpected Errors prüfen
+- Metriken stabil?
+- Keine Alarme ausgelöst?
+- Nutzer-Reports prüfen falls vorhanden
+
+### 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
+
+## Ausgang
+- Validierungsbericht: `memory/gitea-specs/issue-<number>-validation.md`
+- Status: **ACCEPTED** → ⏩ Dokumentations- & Closing-Agent
+- Status: **REJECTED** → ⏩ Implementierungs-Agent mit Begründung
+
+## Regeln
+- Immer aus Nutzersicht prüfen, nicht aus Entwicklersicht
+- Bei REJECTED: Konstruktiv und spezifisch
+- Wenn unsicher: Martin fragen statt selbst entscheiden