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
2026-05-10 20:18:24 +00:00
parent aa10d148ec
commit db82c851b5
13 changed files with 1100 additions and 28 deletions
--- a/skills/gitea-abnahme-validierung/SKILL.md
+++ b/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
--- a/skills/gitea-analyse-architektur/SKILL.md
+++ b/skills/gitea-analyse-architektur/SKILL.md
@@ -0,0 +1,98 @@
+---
+name: gitea-analyse-architektur
+description: Analyse- & Architektur-Agent für Gitea Issues. Analysiert Anforderungen, plant Architektur, erstellt technische Spezifikationen. Teil der Gitea Issue Pipeline.
+---
+
+# Analyse- & Architektur-Agent
+
+Rolle: Erste Phase der Gitea Issue Pipeline. Analysiert das Issue und erstellt die Grundlage für alle folgenden Phasen.
+
+## Eingang
+- Gitea Issue mit Tags `KI` und `ReadyForDev`
+- Issue-Body, Kommentare, verlinkte Ressourcen
+
+## Aufgaben
+
+### Anforderungen analysieren
+- Issue-Body vollständig lesen und verstehen
+- Stakeholder-Intention erkennen
+- Implizite Anforderungen ableiten
+- Unklarheiten dokumentieren und Martin zur Klärung vorlegen
+
+### Tickets strukturieren
+- Anforderungen in Teilaufgaben gliedern
+- Prioritäten setzen
+- Abhängigkeiten zwischen Teilaufgaben markieren
+- Akzeptanzkriterien formulieren
+
+### Edge Cases erkennen
+- Grenzfälle identifizieren
+- Fehlerpfade aufzeigen
+- Ungültige Eingaben / fehlende Daten berücksichtigen
+- Race Conditions / Parallelitätsprobleme erkennen
+
+### Architektur entwerfen
+- Komponentendiagramm erstellen
+- Datenfluss definieren
+- Schnittstellen beschreiben
+- Technology-Stack-Empfehlung aussprechen
+
+### Datenmodelle planen
+- Entitäten identifizieren
+- Attribute und Typen definieren
+- Beziehungen modellieren
+- Indizes und Constraints planen
+- Migrationsbedarf eruieren
+
+### APIs definieren
+- Endpoints festlegen (Methoden, Pfade)
+- Request/Response-Schemas definieren
+- Authentifizierung/Authorisierung klären
+- Rate Limiting / Pagination berücksichtigen
+- Fehlercodes und -meldungen spezifizieren
+
+### Komponenten aufteilen
+- Logische Module/Services identifizieren
+- Verantwortlichkeiten trennen (Single Responsibility)
+- Interfaces zwischen Komponenten definieren
+- Wiederverwendbarkeit fördern
+
+### Abhängigkeiten identifizieren
+- Externe Libraries/Services auflisten
+- Interne Abhängigkeiten kartieren
+- Versionskonflikte prüfen
+- Neu hinzuzufügende Abhängigkeiten bewerten
+
+### Sicherheitsrisiken erkennen
+- OWASP Top 10 prüfen
+- Input-Validation-Anforderungen definieren
+- Auth/Authz-Anforderungen klären
+- Datenlecks ausschließen
+
+### Aufwand schätzen
+- Komplexität bewerten (S/M/L/XL)
+- Zeitaufwand pro Teilaufgabe schätzen
+- Risikopuffer einplanen
+- Gesamtahufwand aggregieren
+
+### Technische Spezifikationen erstellen
+- Alle Ergebnisse in einem Spezifikationsdokument zusammenfassen
+- Spezifikation im Workspace speichern: `memory/gitea-specs/issue-<number>.md`
+- Klare, umsetzbare Anweisungen für den Implementierungs-Agent
+
+### Migrationsstrategien planen
+- Bestehende Datenstruktur analysieren
+- Migrationspfad definieren
+- Rollback-Strategie festlegen
+- Datenverlust-Risiko bewerten
+
+## Ausgang
+- Spezifikationsdokument: `memory/gitea-specs/issue-<number>.md`
+- Strukturierte Teilaufgabenliste
+- Architektur-Entscheidungen dokumentiert
+- ⏩ Übergabe an **Implementierungs-Agent**
+
+## Regeln
+- Bei Unklarheiten **immer** Martin fragen, nicht raten
+- Spezifikation muss für den Implementierungs-Agent ohne Rückfragen umsetzbar sein
+- Sicherheitsrelevante Entscheidungen dokumentieren und Martin zur Freigabe vorlegen
--- a/skills/gitea-code-review/SKILL.md
+++ b/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
--- a/skills/gitea-deployment/SKILL.md
+++ b/skills/gitea-deployment/SKILL.md
@@ -0,0 +1,89 @@
+---
+name: gitea-deployment
+description: Deployment-Agent für Gitea Issues. Deployt Anwendungen, konfiguriert Infrastruktur und überwacht den Rollout. Teil der Gitea Issue Pipeline.
+---
+
+# Deployment-Agent
+
+Rolle: Sechste Phase – nach Merge und Release. Kümmert sich um das Deployment in die Zielumgebung.
+
+## Eingang
+- Gemergter PR / Release-Tag
+- Release Notes
+- Zielumgebung (dev/staging/production)
+
+## Aufgaben
+
+### Anwendungen deployen
+- Deployment-Methoden: Docker, Docker Compose, K8s, Direct Deploy
+- Blue-Green oder Rolling Update wo möglich
+- Deployment-Befehl ausführen und überwachen
+
+### Infrastruktur konfigurieren
+- Umgebungsvariablen setzen
+- Konfigurationsdateien aktualisieren
+- Service-Abhängigkeiten prüfen (Datenbank, Cache, etc.)
+- Netzwerk/Firewall-Regeln falls nötig
+
+### Container verwalten
+- Neues Image bauen: `docker build -t <image>:<version> .`
+- Image pushen: `docker push <registry>/<image>:<version>`
+- Container starten/neustarten
+- Health des Containers prüfen
+
+### Rollbacks durchführen
+- Bei Fehlern: sofortiges Rollback auf vorherige Version
+- Vorherige Version/Image bereithalten
+- Rollback-Befehl dokumentiert
+- Martin bei Rollback sofort informieren
+
+### Secrets verwalten
+- Neue Secrets in die Zielumgebung eintragen
+- Keine Secrets in Config-Dateien oder Images
+- Secrets rotieren falls nötig
+- `.env`-Dateien nicht im Repo
+
+### Umgebungen synchronisieren
+- Konfigurationsdrift vermeiden
+- Staging vor Production deployen
+- Prod-Parität des Staging sicherstellen
+
+### Datenbankmigrationen ausführen
+- Migrationen automatisch oder manuell laufen lassen
+- Backup vor Migration
+- Migration-Output prüfen
+- Bei Fehler: Rollback + Martin informieren
+
+### Monitoring aktivieren
+- Logs prüfen nach Deployment
+- Metriken/Alermts aktualisieren
+- Dashboards bei neuen Metriken erweitern
+- Error-Rate nach Deploy überwachen
+
+### Skalierung konfigurieren
+- Ressourcenlimits anpassen falls nötig
+- Auto-Scaling-Regeln aktualisieren
+- Load Balancer Konfiguration prüfen
+
+### Deployment-Logs analysieren
+- Logs auf Errors/Warnungen scannen
+- Anomalien erkennen
+- Erfolgreiches Deployment bestätigen
+
+### Health Checks durchführen
+- Endpoint-Health prüfen (`/health`, `/ready`)
+- Datenbankverbindung testen
+- Externe API-Erreichbarkeit testen
+- Smoke Tests ausführen
+
+## Ausgang
+- Deployment erfolgreich und verifiziert
+- Health Checks bestanden
+- Martin informiert über erfolgreiches Deployment
+- ⏩ Übergabe an **Abnahme- & Validierungs-Agent**
+
+## Regeln
+- **Immer** Staging vor Production
+- **Immer** Backup vor Migration
+- **Immer** Rollback-Plan bereit
+- **Sofort** Martin informieren bei Problemen
--- a/skills/gitea-dokumentation-closing/SKILL.md
+++ b/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
--- a/skills/gitea-fix-refactoring/SKILL.md
+++ b/skills/gitea-fix-refactoring/SKILL.md
@@ -0,0 +1,88 @@
+---
+name: gitea-fix-refactoring
+description: Fix- & Refactoring-Agent für Gitea Issues. Setzt Review-Feedback um, behebt Bugs und reduziert technische Schulden. Teil der Gitea Issue Pipeline.
+---
+
+# Fix- & Refactoring-Agent
+
+Rolle: Wird bei Bedarf eingeschaltet – nach Code Review mit Änderungswünschen oder nach QA-Testfehlern.
+
+## Eingang
+- Feature Branch mit Änderungswünschen
+- Review-Kommentare: `memory/gitea-specs/issue-<number>-review.md` (CHANGES_REQUESTED)
+- oder QA-Report: `memory/gitea-specs/issue-<number>-qa.md` (FAIL)
+
+## Aufgaben
+
+### Review-Feedback umsetzen
+- Alle 🔴 Must-Fix Comments adressieren
+- Alle 🟡 Should-Fix Comments prüfen und umsetzen
+- Konstruktives Feedback priorisieren
+- Nachvollziehbare Commits pro Fix
+
+### Bugs korrigieren
+- Root Cause identifizieren
+- Minimaler, korrekter Fix
+- Regressionstest hinzufügen
+- Keine neuen Bugs einführen
+
+### Technische Schulden reduzieren
+- TODOs mit Issue-Referenz auflösen
+- Workarounds durch saubere Lösungen ersetzen
+- Veraltete Patterns modernisieren
+
+### Code vereinfachen
+- Überflüssige Komplexität entfernen
+- Verschachtelte Conditionals reduzieren
+- Early Returns nutzen
+- Helper-Methoden extrahieren
+
+### Legacy-Code modernisieren
+- Veraltete APIs ersetzen
+- Neue Sprachfeatures nutzen
+- Patterns aktualisieren
+
+### Performance verbessern
+- Identifizierte Bottlenecks beheben
+- Ineffiziente Algorithmen ersetzen
+- Caching einführen wo sinnvoll
+- Datenbankabfragen optimieren
+
+### Sicherheitslücken schließen
+- Review identifizierte Schwachstellen beheben
+- Input Validation nachziehen
+- Auth/Authz-Lücken schließen
+- Dependencies aktualisieren bei Bedarf
+
+### Redundanzen entfernen
+- Doppelten Code zusammenführen
+- Unbenutzte Imports/Variablen entfernen
+- Tote Code-Pfade eliminieren
+
+### Module entkoppeln
+- Enge Kopplung reduzieren
+- Interfaces nutzen
+- Dependency Injection wo passend
+- Seiteneffekte isolieren
+
+### Typisierung verbessern
+- Strikte Typisierung wo möglich
+- Generics sinnvoll einsetzen
+- Type Guards für Runtime-Sicherheit
+
+### Refactorings dokumentieren
+- Was wurde geändert und warum
+- Breaking Changes kenntlich machen
+- Migrationsschritte falls nötig
+
+## Ausgang
+- Alle Fixes auf Feature Branch committet
+- Änderungen dokumentiert
+- ⏩ Zurück an den Agent der das Feedback gegeben hat:
+  - Bei Review-Feedback → **Code-Review-Agent**
+  - Bei QA-Fail → **Test- & QA-Agent**
+
+## Regeln
+- Ein Fix = ein Commit (atomic)
+- Kein Refactoring ohne klaren Grund
+- Bei Unsicherheit: Martin fragen
--- a/skills/gitea-implementierung/SKILL.md
+++ b/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
--- a/skills/gitea-issue-resolver/SKILL.md
+++ b/skills/gitea-issue-resolver/SKILL.md
@@ -1,9 +1,11 @@
 ---
 name: gitea-issue-resolver
-description: Resolve open Gitea issues by creating feature branches, implementing fixes, and committing. Use when checking or working on issues in Martin's Gitea repos (git.home.kies-media.de). Triggers on mentions of "issues", "Gitea issues", or when checking repos for open issues.
+description: Pipeline-Orchestrator für Gitea Issues. Koordiniert die 9 Agenten-Phasen von der Analyse bis zum Closing. Use when checking or working on issues in Martin's Gitea repos (git.home.kies-media.de). Triggers on mentions of "issues", "Gitea issues", or when checking repos for open issues.
 ---

-# Gitea Issue Resolver
+# Gitea Issue Resolver – Pipeline Orchestrator
+
+Koordiniert die gesamte Issue-Pipeline. Holt Issues ab und steuert sie durch die 9 Phasen.

 ## Authentication

@@ -14,43 +16,113 @@ GIT_USER=$(echo "$GIT_CREDS" | sed -n 's|.*://\([^:]*\):.*|\1|p')
 GIT_PASS=$(echo "$GIT_CREDS" | sed -n 's|.*://[^:]*:\([^@]*\)@.*|\1|p')
 ```

-For API calls use `-u "$GIT_USER:$GIT_PASS"`. If Basic Auth fails, ask Martin for a Gitea API token.
+Gitea API token: `$GITEA_TOKEN` (in `.bashrc`):
+```bash
+GITEA_TOKEN="568841…2e34"
+```

-## Workflow
+## Pipeline – 9 Phasen

-### 1. Check for Open Issues
+### Issue-Filter
+Nur Issues mit **beiden** Tags: `KI` **und** `ReadyForDev`:

 ```bash
-curl -s "https://git.home.kies-media.de/api/v1/repos/<owner>/<repo>/issues?state=open" \
+curl -s "https://git.home.kies-media.de/api/v1/repos/<owner>/<repo>/issues?state=open&labels=KI,ReadyForDev" \
  -u "$GIT_USER:$GIT_PASS"
 ```

-### 2. For Each Open Issue
+### Phase 1: Analyse- & Architektur-Agent → `gitea-analyse-architektur`
+- Anforderungen analysieren
+- Architektur entwerfen
+- Spezifikation erstellen
+- Output: `memory/gitea-specs/issue-<number>.md`

-1. **Create a feature branch** from `main`:
-   ```bash
-   git checkout main && git pull
-   git checkout -b feature/issue-<number>-<short-description>
-   ```
+### Phase 2: Implementierungs-Agent → `gitea-implementierung`
+- Feature Branch erstellen
+- Code schreiben
+- Commits strukturieren
+- Output: Code auf Feature Branch

-2. **Clone repo if needed** (work in a temp dir):
-   ```bash
-   git clone https://git.home.kies-media.de/<owner>/<repo>.git /tmp/<repo>
-   ```
+### Phase 3: Code-Review-Agent → `gitea-code-review`
+- Codequalität & Sicherheit prüfen
+- Review-Kommentare erstellen
+- Output: APPROVED oder CHANGES_REQUESTED

-3. **Implement the fix** – read the issue body, understand the requirement, implement it.
+### Phase 4: Test- & QA-Agent → `gitea-test-qa`
+- Unit-, Integration-, E2E-Tests
+- QA-Report erstellen
+- Output: PASS oder FAIL

-4. **Commit and push**:
-   ```bash
-   git add -A
-   git commit -m "Fix #<number>: <description>"
-   git push -u origin feature/issue-<number>-<short-description>
-   ```
+### Phase 5: Fix- & Refactoring-Agent → `gitea-fix-refactoring` *(bei Bedarf)*
+- Review-Feedback umsetzen
+- Bugs korrigieren
+- Danach zurück zur jeweiligen Phase (Review oder QA)

-5. **Inform Martin** – send a summary of what was done and that the branch is ready for review/merge.
+### Phase 6: Merge- & Release-Agent → `gitea-merge-release`
+- PR erstellen
+- Release Notes & Versionierung
+- Warten auf Martins Freigabe

-### 3. Do NOT
+### Phase 7: Deployment-Agent → `gitea-deployment`
+- Anwendungen deployen
+- Health Checks
+- Bei Problemen: Rollback

- Do not merge the branch yourself
- Do not close the issue yourself
- Do not push to `main` directly
+### Phase 8: Abnahme- & Validierungs-Agent → `gitea-abnahme-validierung`
+- Anforderungen validieren
+- Akzeptanzkriterien abhaken
+- Output: ACCEPTED oder REJECTED
+
+### Phase 9: Dokumentations- & Closing-Agent → `gitea-dokumentation-closing`
+- Dokumentation erstellen
+- Issue schließen
+- Abschlussbericht
+
+## Pipeline-Fluss
+
+```
+Issue (KI + ReadyForDev)
+  │
+  ▼
+[1] Analyse & Architektur
+  │
+  ▼
+[2] Implementierung
+  │
+  ▼
+[3] Code Review ──── CHANGES_REQUESTED ──→ [5] Fix & Refactoring ──→ [3]
+  │ APPROVED
+  ▼
+[4] Test & QA ────── FAIL ──────────────→ [5] Fix & Refactoring ──→ [4]
+  │ PASS
+  ▼
+[6] Merge & Release ( wartet auf Martins Freigabe )
+  │
+  ▼
+[7] Deployment
+  │
+  ▼
+[8] Abnahme & Validierung ── REJECTED ──→ [2] Implementierung
+  │ ACCEPTED
+  ▼
+[9] Dokumentation & Closing → Issue geschlossen ✅
+```
+
+## Orchestrierung
+
+Für jedes Issue:
+1. Spezifikations-Verzeichnis erstellen: `mkdir -p memory/gitea-specs`
+2. Phasen sequenziell durchlaufen
+3. Bei Rücksprüngen (Fix-Phase) den Zyklus wiederholen
+4. Martin bei wichtigen Meilensteinen informieren:
+   - Spezifikation fertig (Phase 1)
+   - PR erstellt (Phase 6)
+   - Deployment erfolgreich (Phase 7)
+   - Issue geschlossen (Phase 9)
+
+## Regeln
+- **Nur** Issues mit Tags `KI` + `ReadyForDev`
+- **Nie** ohne Martins Freigabe mergen
+- **Nie** Issue selbst schließen (nur Phase 9 darf das)
+- **Nie** direkt auf `main` pushen
+- Bei Blockern: sofort Martin informieren
--- a/skills/gitea-merge-release/SKILL.md
+++ b/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
--- a/skills/gitea-test-qa/SKILL.md
+++ b/skills/gitea-test-qa/SKILL.md
@@ -0,0 +1,91 @@
+---
+name: gitea-test-qa
+description: Test- & QA-Agent für Gitea Issues. Erstellt und führt Tests durch, sichert Qualität ab. Teil der Gitea Issue Pipeline.
+---
+
+# Test- & QA-Agent
+
+Rolle: Vierte Phase der Gitea Issue Pipeline. Stellt sicher, dass die Implementierung korrekt und robust ist.
+
+## Eingang
+- Feature Branch mit APPROVED Code
+- Spezifikationsdokument: `memory/gitea-specs/issue-<number>.md`
+- Review-Ergebnis: `memory/gitea-specs/issue-<number>-review.md`
+
+## Aufgaben
+
+### Unit-Tests erstellen
+- Für jede neue Funktion/Methode
+- Positive und Negative Cases
+- Grenzwerte testen
+- Mocking für externe Abhängigkeiten
+
+### Integrationstests erstellen
+- Modulgrenzen testen
+- Datenbank-Integration prüfen
+- API-End-to-End innerhalb des Services
+- externe API-Mocks nutzen
+
+### E2E-Tests durchführen
+- Nutzerflows durchspielen
+- Kritische Pfade abdecken
+- Browser-basiert wenn UI betroffen
+
+### Regressionstests ausführen
+- Bestehende Test-Suite laufen lassen
+- Sicherstellen dass nichts kaputt gegangen ist
+- Bei Fehlschlägen: Root Cause dokumentieren
+
+### Testdaten generieren
+- Realistische Testdaten erzeugen
+- Edge Cases in Testdaten abdecken
+- Keine Produktionsdaten verwenden
+- Testdaten reproduzierbar (Seeds/Fixtures)
+
+### Fehler reproduzieren
+- Gemeldete Bugs nachstellen
+- Minimal reproduzierbares Example erstellen
+- Umgebungsdetails dokumentieren
+
+### Edge Cases testen
+- Leere Eingaben
+- Ungültige Formate
+- Gleichzeitige Zugriffe
+- Netzwerkfehler / Timeouts
+- Datenüberläufe / Grenzwerte
+
+### API-Tests durchführen
+- Alle Endpoints abdecken
+- Status Codes verifizieren
+- Response-Schemas validieren
+- Auth/Authz testen
+- Rate Limiting prüfen
+
+### UI-Tests automatisieren
+- Kritische User Flows
+- Formularvalidierung
+- Responsive Breakpoints
+- Accessibility-Basics
+
+### Performance-Tests ausführen
+- Antwortzeiten messen
+- Lasttests bei relevanten Endpoints
+- Memory-Verbrauch prüfen
+- Bottlenecks identifizieren
+
+### Testreports erstellen
+- Ergebnisse zusammenfassen in `memory/gitea-specs/issue-<number>-qa.md`
+- Testabdeckung (%)
+- Gefundene Issues mit Schweregrad
+- Gesamtbewertung: PASS / FAIL / PASS_WITH_ISSUES
+
+## Ausgang
+- Test-Code auf Feature Branch committet
+- QA-Report: `memory/gitea-specs/issue-<number>-qa.md`
+- Status: **PASS** → ⏩ Merge- & Release-Agent
+- Status: **FAIL** → ⏩ Fix- & Refactoring-Agent
+
+## Regeln
+- Keine Tests nur für die Statistik – jeder Test muss einen Wert haben
+- Flaky Tests sofort fixen oder entfernen
+- Performance-Regressionen als FAIL werten