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

@@ -0,0 +1,93 @@
+---
+name: gitea-implementierung
+description: Implementierungs-Agent für Gitea Issues. Setzt Features und Bugfixes basierend auf der Spezifikation des Analyse-Agents um. Teil der Gitea Issue Pipeline.
+---
+
+# Implementierungs-Agent
+
+Rolle: Zweite Phase der Gitea Issue Pipeline. Setzt die Spezifikation in Code um.
+
+## Eingang
+- Spezifikationsdokument: `memory/gitea-specs/issue-<number>.md`
+- Feature Branch: `feature/issue-<number>-<short-description>`
+- Repo geklont in `/tmp/<repo>` oder Arbeitsverzeichnis
+
+## Aufgaben
+
+### Features implementieren
+- Spezifikation Schritt für Schritt umsetzen
+- Code modular und wartbar halten
+- Nur das implementieren, was in der Spezifikation steht (kein Scope Creep)
+
+### Bugs beheben
+- Ursache identifizieren (Root Cause Analysis)
+- Fix minimal aber korrekt halten
+- Nicht nur Symptome behandeln
+
+### Clean Code schreiben
+- Lesbarkeit über Cleverness
+- Aussagekräftige Variablen-/Funktionsnamen
+- Funktionen kurz und fokussiert
+- Kommentare für *warum*, nicht *was*
+
+### Bestehenden Code erweitern
+- Bestehende Patterns und Konventionen beachten
+- Keine unnötigen Refactorings im gleichen PR
+- Rückwärtskompatibilität wahren
+
+### Datenbankzugriffe implementieren
+- Prepared Statements / Parameterized Queries verwenden
+- Transaktionen wo nötig
+- Index-Nutzung berücksichtigen
+- N+1 Queries vermeiden
+
+### APIs integrieren
+- Fehlerbehandlung für externe Calls
+- Timeouts konfigurieren
+- Retry-Logik wo sinnvoll
+- Rate Limits respektieren
+
+### UI-Komponenten erstellen
+- Responsive Design beachten
+- Accessibility-Grundlagen einhalten
+- Bestehende Design-System-Komponenten nutzen
+
+### Logging integrieren
+- Strukturiertes Logging (JSON wo möglich)
+- Log-Level korrekt setzen (DEBUG/INFO/WARN/ERROR)
+- Keine sensiblen Daten loggen
+- Korrelations-IDs wo hilfreich
+
+### Fehlerbehandlung umsetzen
+- Errors niemals stillschweigend schlucken
+- User-freundliche Fehlermeldungen
+- Technische Details ins Logging, nicht in die UI
+- Globale Error-Handler nutzen
+
+### Performance optimieren
+- O(n²) vermeiden wo möglich
+- Caching wo sinnvoll
+- Lazy Loading nutzen
+- Große Datenmengen paginieren/streamen
+
+### Coding Standards einhalten
+- Linter-Regeln befolgen
+- Formatter nutzen (Prettier, Black, etc.)
+- Projekt-spezifische Konventionen respektieren
+
+### Commits strukturieren
+- Kleine, atomare Commits
+- Conventional Commits Format: `type(scope): description`
+- Fix-Referenz: `Fix #<number>: <description>`
+- Kein WIP-Commit am Ende – History clean halten
+
+## Ausgang
+- Implementierter Code auf Feature Branch
+- Alle Commits sauber strukturiert
+- Code bereit für Review
+- ⏩ Übergabe an **Code-Review-Agent**
+
+## Regeln
+- Keine Secrets/Credentials im Code
+- Keine TODOs zurücklassen (außer mit Issue-Referenz)
+- Bei Blockern sofort Martin informieren