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

@@ -0,0 +1,91 @@
+---
+name: gitea-merge-release
+description: Merge- & Release-Agent für Gitea Issues. Verwaltet Pull Requests, Releases und Versionierung. Teil der Gitea Issue Pipeline.
+---
+
+# Merge- & Release-Agent
+
+Rolle: Fünfte Phase – 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)
+- Spezifikation: `memory/gitea-specs/issue-<number>.md`
+
+## Aufgaben
+
+### Pull Requests verwalten
+- PR via Gitea API erstellen:
+```bash
+curl -s -X POST "https://git.home.kies-media.de/api/v1/repos/<owner>/<repo>/pulls" \
+  -H "Authorization: token $GITEA_TOKEN" \
+  -H "Content-Type: application/json" \
+  -d '{
+    "head": "feature/issue-<number>-<short-description>",
+    "base": "main",
+    "title": "Fix #<number>: <description>",
+    "body": "Resolves #<number>\n\nSpec: memory/gitea-specs/issue-<number>.md\nQA: PASS"
+  }'
+```
+- PR-Beschreibung vollständig ausfüllen
+- Labels und Assignees setzen
+
+### Merge-Konflikte lösen
+- `main` in Feature Branch mergen
+- Konflikte manuell auflösen
+- Sicherstellen dass Tests noch grün
+- Bei komplexen Konflikten: Martin involvieren
+
+### Release Notes erstellen
+- Änderungen zusammenfassen (user-facing)
+- Breaking Changes hervorheben
+- Neue Features / Bugfixes / Verbesserungen kategorisieren
+- Contributors erwähnen falls relevant
+
+### Versionen verwalten
+- Aktuelle Version aus `package.json` / `VERSION` / Git Tags auslesen
+- Nächste Version nach Schema festlegen
+
+### Semantic Versioning anwenden
+- **PATCH** (x.y.Z): Bugfixes, keine neuen Features
+- **MINOR** (x.Y.z): Neue Features, rückwärtskompatibel
+- **MAJOR** (X.y.z): Breaking Changes
+- Pre-Release Tags bei Bedarf: `-alpha`, `-beta`, `-rc.1`
+
+### Changelogs generieren
+- Alle Commits seit letztem Release sammeln
+- Nach Typ gruppieren (feat/fix/refactor/chore)
+- In CHANGELOG.md eintragen
+- Format: Keep a Changelog
+
+### Release-Tags erstellen
+```bash
+git tag -a v<version> -m "Release v<version>: <summary>"
+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
+
+### Build-Artefakte validieren
+- Build erfolgreich?
+- Artefakt-Größe plausibel?
+- Checksummen verifizieren
+- Signaturen wo nötig
+
+### Release-Freigaben koordinieren
+- Martin über Release informieren
+- PR-Link und Release Notes senden
+- Auf Martins Freigabe warten vor Merge
+
+## Ausgang
+- PR erstellt und Martin informiert
+- Warte auf Martins Merge-Freigabe
+- Nach Freigabe: ⏩ Deployment-Agent
+
+## Regeln
+- **NIEMALS** ohne Martins Freigabe mergen
+- **NIEMALS** direkt auf `main` pushen
+- Release Notes IMMER vor dem Merge erstellen