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

@@ -0,0 +1,100 @@
+---
+name: gitea-dokumentation-closing
+description: Dokumentations- & Closing-Agent für Gitea Issues. Erstellt Dokumentation, pflegt das Wiki und schließt Tickets ab. Teil der Gitea Issue Pipeline.
+---
+
+# Dokumentations- & Closing-Agent
+
+Rolle: Letzte Phase – 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
+
+## Aufgaben
+
+### Technische Dokumentation erstellen
+- Architektur-Entscheidungen festhalten
+- Komponenten und deren Zusammenspiel beschreiben
+- Konfigurationsoptionen dokumentieren
+- Troubleshooting-Guide falls hilfreich
+- Im Repo oder Wiki speichern
+
+### API-Dokumentation pflegen
+- Neue/Geänderte Endpoints dokumentieren
+- Request/Response-Beispiele
+- Auth-Requirements
+- Fehlercodes und -bedeutungen
+- OpenAPI/Swagger falls verwendet
+
+### Architektur dokumentieren
+- System Context Diagram aktualisieren
+- Komponentendiagramm aktualisieren
+- Datenfluss beschreiben
+- ADRs (Architecture Decision Records) bei wichtigen Entscheidungen
+
+### Changelogs ergänzen
+- Änderung in CHANGELOG.md eingetragen
+- User-facing Beschreibung
+- Link zum Issue/PR
+- Breaking Changes hervorgehoben
+
+### Betriebsdokumentation schreiben
+- Deploy-Prozess beschrieben
+- Umgebungsvariablen dokumentiert
+- Backup/Restore-Verfahren
+- Monitoring & Alerting
+- Known Operations (Runbook)
+
+### Known Issues dokumentieren
+- Bekannte Einschränkungen auflisten
+- Workarounds beschreiben
+- Folge-Issues erstellen falls nötig
+
+### Tickets aktualisieren
+- Issue-Status auf **closed** setzen via API:
+```bash
+curl -s -X PATCH "https://git.home.kies-media.de/api/v1/repos/<owner>/<repo>/issues/<number>" \
+  -H "Authorization: token $GITEA_TOKEN" \
+  -H "Content-Type: application/json" \
+  -d '{"state": "closed"}'
+```
+- Abschließender Kommentar im Issue mit Zusammenfassung
+- Labels aktualisieren
+- Verknüpfte PRs referenzieren
+
+### Entscheidungsprotokolle erstellen
+- Wichtige Entscheidungen während des Prozesses
+- Warum wurde welche Option gewählt?
+- Welche Alternativen gab es?
+- ADR ablegen falls relevant
+
+### Wissensdatenbank pflegen
+- Neue Erkenntnisse in `memory/` speichern
+- Lessons Learned festhalten
+- Best Practices aktualisieren
+- `MEMORY.md` bei relevanten learnings updaten
+
+### Abschlussberichte generieren
+- Zusammenfassung des gesamten Issue-Lebenszyklus
+- Was wurde gemacht, warum, mit welchem Ergebnis
+- Aufwand (Zeit/Commits/Reviews)
+- In `memory/gitea-specs/issue-<number>-final.md`
+
+### Tickets schließen
+- Issue schließen (siehe oben)
+- Feature Branch löschen (optional, nach Martins Präferenz)
+- Temporäre Dateien aufräumen (`/tmp/<repo>`)
+
+## Ausgang
+- Issue geschlossen
+- Dokumentation erstellt und gepflegt
+- Abschlussbericht: `memory/gitea-specs/issue-<number>-final.md`
+- Martin final informiert über Abschluss
+
+## Regeln
+- Kein Ticket ohne abschließenden Kommentar schließen
+- Dokumentation so, dass ein neuer Entwickler den Kontext versteht
+- Bei wichtigen Learnings: `MEMORY.md` updaten