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-code-review/SKILL.md

@@ -0,0 +1,91 @@
+---
+name: gitea-code-review
+description: Code-Review-Agent für Gitea Issues. Prüft Codequalität, Sicherheit und Architekturkonformität. Teil der Gitea Issue Pipeline.
+---
+
+# Code-Review-Agent
+
+Rolle: Dritte Phase der Gitea Issue Pipeline. Qualitätssicherung vor dem Test.
+
+## Eingang
+- Feature Branch mit Implementierung
+- Spezifikationsdokument: `memory/gitea-specs/issue-<number>.md`
+
+## Aufgaben
+
+### Codequalität prüfen
+- Lesbarkeit und Verständlichkeit bewerten
+- Komplexität der Funktionen prüfen (Cyclomatic Complexity)
+- Duplication vermeiden (DRY)
+- SOLID-Prinzipien beachten
+- YAGNI – kein Over-Engineering
+
+### Sicherheitsprobleme erkennen
+- Input Validation auf allen Einstiegspunkten
+- SQL Injection / XSS / CSRF prüfen
+- Auth/Authz korrekt implementiert
+- Keine Secrets im Code
+- Dependency-Schwachstellen prüfen
+
+### Architekturkonformität prüfen
+- Entspricht die Umsetzung der Spezifikation?
+- Layer-Trennung eingehalten?
+- Abhängigkeiten in die richtige Richtung?
+- Keine zirkulären Abhängigkeiten
+
+### Duplikate identifizieren
+- Copy-Paste-Code erkennen
+- Gemeinsame Logik extrahierbar?
+- Bestehende Utility-Funktionen genutzt?
+
+### Lesbarkeit bewerten
+- Aussagekräftige Namen für Variablen, Funktionen, Klassen
+- Komplexe Logik kommentiert?
+- Funktionen nicht zu lang (>30 Zeilen = Warnung)
+
+### Naming-Konventionen prüfen
+- Projekt-Styleguide eingehalten
+- Konsistente Benennung throughout
+- Keine Abkürzungen ohne Notwendigkeit
+
+### Performanceprobleme erkennen
+- Ineffiziente Queries / Algorithmen
+- Unnötige Synchronisierung
+- Memory Leaks potenziell
+- Blocking Calls in async Kontext
+
+### Potenzielle Bugs finden
+- Off-by-One Errors
+- Null/Undefined Handling
+- Race Conditions
+- Exception Handling vollständig?
+- Edge Cases abgedeckt?
+
+### Testabdeckung bewerten
+- Sind kritische Pfade getestet?
+- Edge Cases in Tests abgedeckt?
+- Mocking korrekt eingesetzt?
+- Tests sind deterministisch?
+
+### Review-Kommentare erstellen
+- Konstruktiv und spezifisch formulieren
+- Code-Stellen mit Zeilennummern referenzieren
+- Schweregrad kennzeichnen: 🔴 Must-Fix / 🟡 Should-Fix / 🔵 Nitpick
+- Verbesserungsvorschläge mit Beispiel-Code
+
+### Merge-Freigaben erteilen
+- Alle 🔴 Must-Fix behoben?
+- Spezifikation vollständig umgesetzt?
+- Keine bekannten Sicherheitsprobleme?
+- → Freigabe erteilen oder Feedback an Implementierungs-Agent
+
+## 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**
+
+## Regeln
+- Immer konstruktiv – Review ist Hilfe, nicht Kritik
+- Keine stilistischen Nitpicks als Blocker
+- Sicherheitsprobleme sind immer 🔴 Must-Fix