Auto-commit: 2026-05-20 21:35

skills/gitea-abnahme-validierung/SKILL.md

@@ -11,6 +11,8 @@ Rolle: Phase 6 – nach gemergtem Code. Stellt sicher, dass die Lösung das Prob
 - Gemergter PR / Release-Tag
 - Spezifikation: `memory/gitea-specs/issue-<number>.md`
 - Original-Issue von Gitea
+- **Wird IMMER ausgeführt**, selbst nach Martins manuellem Merge – Pipeline ist erst nach Phase 7 fertig
+- **Testumgebung:** `http://178.104.150.0:6427/` falls noch nicht gemerged
 
 ## Aufgaben
 
@@ -22,7 +24,11 @@ Rolle: Phase 6 – nach gemergtem Code. Stellt sicher, dass die Lösung das Prob
 
 ### Akzeptanzkriterien prüfen
 - Jedes Akzeptanzkriterium einzeln abhaken
-- Bei UI: visuell überprüfen
+- **Browser-Validierung via `agent-browser`:**
+  - Seite auf `http://178.104.150.0:6427/` öffnen
+  - Screenshot machen
+  - Jedes Akzeptanzkriterium visuell nachvollziehen
+  - Bei UI: visuell überprüfen
 - Bei API: Requests manuell/automatisiert senden
 - Bei Daten: korrekte Speicherung und Abrufbarkeit prüfen
 
@@ -39,10 +45,14 @@ Rolle: Phase 6 – nach gemergtem Code. Stellt sicher, dass die Lösung das Prob
 - Edge Cases im Business-Kontext
 
 ### UI/UX bewerten
+- **Browser-Check via `agent-browser`** auf `http://178.104.150.0:6427/`
+- Screenshot erstellen und visuell bewerten
 - Layout korrekt und konsistent?
 - Fehlermeldungen verständlich?
 - Ladezeiten akzeptabel?
-- Mobile Darstellung falls relevant
+- Mobile Darstellung: Viewport auf 375px setzen und erneut prüfen
+- Accessibility-Basics (Kontrast, Alt-Texte, Links)
+- Screenshots im Validierungsbericht dokumentieren
 
 ### Compliance prüfen
 - Datenschutzanforderungen erfüllt?
@@ -72,6 +82,7 @@ Rolle: Phase 6 – nach gemergtem Code. Stellt sicher, dass die Lösung das Prob
 
 ## Ausgang
 - Validierungsbericht: `memory/gitea-specs/issue-<number>-validation.md`
+- **Label `InValidation` gesetzt** (kumulativ)
 - Status: **ACCEPTED** → ⏩ Dokumentations- & Closing-Agent (Phase 7)
 - Status: **REJECTED** → ⏩ Implementierungs-Agent (Phase 2) mit Begründung
 
@@ -79,3 +90,4 @@ Rolle: Phase 6 – nach gemergtem Code. Stellt sicher, dass die Lösung das Prob
 - Immer aus Nutzersicht prüfen, nicht aus Entwicklersicht
 - Bei REJECTED: Konstruktiv und spezifisch
 - Wenn unsicher: Martin fragen statt selbst entscheiden
+- **Bei Komplexität S:** Vereinfachter Check – nur Akzeptanzkriterien abhaken, kein vollständiger Validierungsbericht. Direkt zu ACCEPTED wenn Kriterien erfüllt.

skills/gitea-analyse-architektur/SKILL.md

@@ -25,6 +25,23 @@ Komplexität ins Issue schreiben und im Spezifikationsdokument festhalten.
 
 ## Aufgaben
 
+### Abhängigkeiten analysieren
+- Gibt es andere offene Issues, die dieses Issue blockieren oder die davon abhängen?
+- Typische Abhängigkeiten:
+  - JS-Rewrite (#19 jQuery entfernen) sollte VOR Accessibility (#18) passieren
+  - Infrastruktur-Änderungen VOR Feature-Implementierung
+  - API-Änderungen VOR Frontend-Anpassungen
+- Abhängigkeiten im Spezifikationsdokument festhalten
+- **Als Kommentar ins Issue schreiben** mit `🔗 **Abhängigkeit:**` Prefix
+- Gitea Dependency-API nutzen falls verfügbar:
+```bash
+# Issue N hängt von Issue M ab
+POST /repos/<owner>/<repo>/issues/N/dependencies  {"index": M}
+# Issue N blockiert Issue M
+POST /repos/<owner>/<repo>/issues/N/blocks  {"index": M}
+```
+- Falls API nicht funktioniert: Als Kommentar dokumentieren
+
 ### Anforderungen analysieren
 - Issue-Body vollständig lesen und verstehen
 - Stakeholder-Intention erkennen
@@ -93,11 +110,23 @@ Komplexität ins Issue schreiben und im Spezifikationsdokument festhalten.
 - Rollback-Strategie festlegen
 - Datenverlust-Risiko bewerten
 
+### API-Calls absichern
+Alle Gitea API-Calls müssen den HTTP-Status prüfen:
+```bash
+HTTP_STATUS=$(curl -s -o /tmp/response.json -w "%{http_code}" ...)
+if [ "$HTTP_STATUS" -ge 400 ]; then
+  echo "API-Fehler: $HTTP_STATUS"
+  cat /tmp/response.json
+  # Abbrechen und Martin informieren
+fi
+```
+ Bei Fehlern: Vorgang abbrechen, Fehlermeldung dokumentieren, Martin informieren.
+
 ## Ausgang
 - Spezifikationsdokument: `memory/gitea-specs/issue-<number>.md`
 - **Issue aktualisieren** mit allen Erkenntnissen (Komplexität, Architektur, Teilaufgaben, Akzeptanzkriterien, etc.)
 - Spezifikation als Kommentar ins Issue geschrieben
-- Dem Issue den Tag **`ReadyForDev`** hinzufügen:
+- Dem Issue das Label **`ReadyForDev`** hinzufügen (kumulativ – bestehende Labels bleiben):
 ```bash
 curl -s -X POST "https://git.home.kies-media.de/api/v1/repos/<owner>/<repo>/issues/<number>/labels" \
   -H "Authorization: token $GITEA_TOKEN" \
@@ -112,3 +141,4 @@ curl -s -X POST "https://git.home.kies-media.de/api/v1/repos/<owner>/<repo>/issu
 - Sicherheitsrelevante Entscheidungen dokumentieren und Martin zur Freigabe vorlegen
 - Tag `ReadyForDev` **erst** hinzufügen, wenn Analyse & Architektur vollständig abgeschlossen
 - **Bei Komplexität L:** Martin muss die Analyse freigeben bevor `ReadyForDev` gesetzt wird
+- **Bei Subscription-Limit / Rate-Limit:** Sofort pausieren, Martin informieren, nicht weiterarbeiten

skills/gitea-code-review/SKILL.md

@@ -29,6 +29,38 @@ Dieser Agent führt ein **Self-Review** durch – die KI prüft ihren eigenen Co
 - SOLID-Prinzipien beachten
 - YAGNI – kein Over-Engineering
 
+### Code-Quality-Checkliste (PFLICHT)
+
+Jeder Review MUSS diese Checks durchführen:
+
+| # | Check | Kriterium | Schweregrad bei Verletzung |
+|---|---|---|---|
+| 1 | **Funktionslänge** | Max 30 Zeilen pro Funktion (ohne Leerzeilen) | 🟡 Should-Fix |
+| 2 | **Dateilänge** | Max 300 Zeilen pro Datei | 🟡 Should-Fix |
+| 3 | **Verschachtelung** | Max 3 Ebenen (if/for/while) | 🟡 Should-Fix |
+| 4 | **Magic Numbers** | Keine unbenannten Zahlen im Code | 🔵 Nitpick |
+| 5 | **Console.log** | Keine console.log/print in Produktionscode | 🔴 Must-Fix |
+| 6 | **Dead Code** | Keine auskommentierten Blöcke, unreachable code | 🟡 Should-Fix |
+| 7 | **Ternary-Chains** | Max 1 Ternary, keine Verschachtelung | 🟡 Should-Fix |
+| 8 | **Dependencies** | Keine unnötigen neuen Dependencies | 🟡 Should-Fix |
+| 9 | **Error-Handling** | Alle Fehlerpfade behandelt, kein silent catch | 🔴 Must-Fix |
+| 10 | **Input-Validation** | Alle User-Inputs validiert/sanitized | 🔴 Must-Fix |
+| 11 | **Secrets** | Keine Passwörter/Tokens/Keys im Code | 🔴 Must-Fix |
+| 12 | **Typsicherheit** | Kein `any` in TypeScript, korrekte Typen | 🟡 Should-Fix |
+
+Ergebnis der Checkliste im Review-Dokument dokumentieren.
+
+**Zusätzliche automatische Checks:**
+```bash
+# Linter-Ergebnis prüfen
+npm run lint
+# Formatter-Check
+npx prettier --check .
+# Dependency-Audit
+npm audit --audit-level=moderate
+```
+Bei Fehlern: 🔴 Must-Fix, Review darf nicht APPROVED werden.
+
 ### Sicherheitsprobleme erkennen
 - Input Validation auf allen Einstiegspunkten
 - SQL Injection / XSS / CSRF prüfen
@@ -91,6 +123,7 @@ Dieser Agent führt ein **Self-Review** durch – die KI prüft ihren eigenen Co
 ## Ausgang
 - Review-Ergebnis dokumentiert in `memory/gitea-specs/issue-<number>-review.md`
 - Status: **APPROVED** oder **CHANGES_REQUESTED**
+- **Label `InReview` gesetzt** (kumulativ)
 - Bei APPROVED:
   - Komplexität **S**: ⏩ direkte Übergabe an **Merge- & Release-Agent** (Phase 5)
   - Komplexität **M/L**: ⏩ Übergabe an **Test- & QA-Agent** (Phase 4)

skills/gitea-dokumentation-closing/SKILL.md

@@ -88,13 +88,39 @@ curl -s -X PATCH "https://git.home.kies-media.de/api/v1/repos/<owner>/<repo>/iss
 - Feature Branch löschen (optional, nach Martins Präferenz)
 - Temporäre Dateien aufräumen (`/tmp/<repo>`)
 
+### Spec-Dateien aufräumen
+Nach Abschluss:
+- `-final.md` bleibt als Dauer-Doku
+- Temporäre Specs (`-review.md`, `-qa.md`, `-validation.md`) nach 30 Tagen löschen
+- Bei Komplexität S: Nur `-final.md` erstellen, keine temporären Specs
+
+### Komplexität S: Vereinfachter Closing-Flow
+Bei S-Issues (Typos, Config, kleine Fixes):
+- Kurze Zusammenfassung als Issue-Kommentar
+- Issue schließen
+- `-final.md` mit Minimal-Info (was, warum, PR-Link)
+- Keine umfangreiche Doku, kein Runbook, kein ADR
+
 ## Ausgang
 - Issue geschlossen
 - Dokumentation erstellt und gepflegt
 - Abschlussbericht: `memory/gitea-specs/issue-<number>-final.md`
-- Martin final informiert über Abschluss
+- Martin final informiert über Abschluss (inkl. Gesamtzeit der Umsetzung)
+
+### Zeit-Tracking
+Jede Phase dokumentiert ihre Dauer. Im Abschlussbericht (`-final.md`) und in der Benachrichtigung an Martin wird die Gesamtzeit aller Phasen ausgewiesen:
+- Phase 1 (Analyse): Dauer
+- Phase 2 (Implementierung): Dauer
+- Phase 3 (Review): Dauer
+- Phase 4 (QA, falls vorhanden): Dauer
+- Phase 5 (Merge/PR): Dauer
+- Phase 6 (Abnahme): Dauer
+- Phase 7 (Closing): Dauer
+- **Gesamtzeit:** Summe
 
 ## Regeln
 - Kein Ticket ohne abschließenden Kommentar schließen
 - Dokumentation so, dass ein neuer Entwickler den Kontext versteht
 - Bei wichtigen Learnings: `MEMORY.md` updaten
+- Feature Branch nach Merge im Remote löschen
+- Temporäre Spec-Dateien nach 30 Tagen aufräumen

skills/gitea-issue-resolver/SKILL.md

@@ -122,14 +122,25 @@ Issue (Label: KI)
 
 ## Orchestrierung
 
-Für jedes Issue:
+### Grundsatz: IMMER alle Phasen durchlaufen
+Die Pipeline muss **immer** von Phase 1 bis Phase 7 komplett durchlaufen werden.
+Der einzige Pause-Punkt ist Martins Merge-Freigabe in Phase 5.
+Nach dem Merge durch Martin MÜSSEN Phase 6 und 7 automatisch weiterlaufen.
+
+### Für jedes Issue:
 1. Spezifikations-Verzeichnis erstellen: `mkdir -p memory/gitea-specs`
 2. Komplexität aus Phase 1 berücksichtigen für Pipeline-Verlauf
 3. Fix-Zyklen zählen, bei >3 abbrechen und Martin informieren
-4. Martin bei wichtigen Meilensteinen informieren:
-   - Spezifikation fertig + Komplexität (Phase 1)
-   - PR erstellt (Phase 5)
-   - Issue geschlossen (Phase 7)
+4. **Alle Phasen sequenziell ausführen**, pausieren nur bei:
+   - Komplexität L: Martin muss Analyse freigeben (vor Phase 2)
+   - Phase 5: Martin muss PR freigeben/mergen
+5. Nach Martins Merge: **sofort** Phase 6 (Abnahme) und Phase 7 (Closing) starten
+
+### Martin bei Meilensteinen informieren:
+- Spezifikation fertig + Komplexität (Phase 1)
+- PR erstellt (Phase 5)
+- Issue geschlossen (Phase 7)
+- **Abhängigkeiten beachten:** Vor Implementierung prüfen ob blockierende Issues bereits gemergt sind. Falls nicht: warten oder Martin informieren.
 
 ## Regeln
 - Phase 1 filtert auf **nur** `KI`
@@ -139,3 +150,6 @@ Für jedes Issue:
 - **Nie** direkt auf `main` pushen
 - **Max. 3** Fix-Zyklen, dann Martin fragen
 - Bei Blockern: sofort Martin informieren
+- **Immer** Phase 1–7 komplett durchlaufen, kein vorzeitiger Abbruch
+- Nach Martins Merge: Phase 6+7 automatisch starten
+- **Bei Subscription-Limit / Rate-Limit / Token-Limit:** Sofort pausieren, Martin informieren. Nicht weiterarbeiten bis Martin grünes Licht gibt. Sub-Agenten ebenfalls stoppen.

skills/gitea-test-qa/SKILL.md

@@ -14,6 +14,7 @@ Rolle: Phase 4 der Gitea Issue Pipeline. Stellt sicher, dass die Implementierung
 - Feature Branch mit APPROVED Code
 - Spezifikationsdokument: `memory/gitea-specs/issue-<number>.md`
 - Review-Ergebnis: `memory/gitea-specs/issue-<number>-review.md`
+- **Pipeline hat Feature Branch auf Testumgebung deployed** → `http://178.104.150.0:6427/`
 
 ## Aufgaben
 
@@ -64,6 +65,20 @@ Rolle: Phase 4 der Gitea Issue Pipeline. Stellt sicher, dass die Implementierung
 - Auth/Authz testen
 - Rate Limiting prüfen
 
+### Visuelle Qualitätskontrolle via Browser (verpflichtend)
+- **Testumgebung:** `http://178.104.150.0:6427/`
+- Skill `agent-browser` nutzen, um die deployte Seite im Browser zu öffnen
+- Screenshot der Seite erstellen und visuell prüfen
+- Zu prüfen:
+  - Seite lädt korrekt (keine weiße Seite, keine Fehler)
+  - Layout stimmt (Header, Footer, Inhalt sichtbar)
+  - Bilder und Assets laden korrekt
+  - Links sind klickbar und führen zum richtigen Ziel
+  - Responsive Darstellung (Desktop + Mobile-Viewport)
+  - Änderungen aus dem Feature Branch sichtbar
+- Bei Fehlern: Screenshot dokumentieren, Issue beschreiben
+- Ergebnis in QA-Report aufnehmen (mit Screenshot-Pfad)
+
 ### UI-Tests automatisieren
 - Kritische User Flows
 - Formularvalidierung

skills/project-market-feature-analyst/SKILL.md

@@ -0,0 +1,153 @@
+---
+name: project-market-feature-analyst
+description: Analysiert ein Git-Repository technisch und fachlich, führt Markt- und Konkurrenzanalyse durch und identifiziert sinnvolle neue Features. Use when the user wants to improve a project, find new feature ideas, analyze competitors, or asks "what should I add to my project". Triggers on mentions of "Feature-Ideen", "Marktanalyse", "Projektanalyse", "Konkurrenzanalyse", "Verbesserungen", "Roadmap", or "Features finden".
+---
+
+# Projektanalyse & Marktanalyse für Feature-Ideen
+
+Analysiert ein Git-Repository, vergleicht mit dem Markt und schlägt hochwertige Features vor. Für jedes Feature wird der Nutzer gefefragt, ob ein Git-Issue erstellt werden soll.
+
+## Kernprinzipien
+
+**MUSS:**
+- kritisch und pragmatisch denken
+- bestehende Architektur und Patterns respektieren
+- realistische Verbesserungen priorisieren
+- Marktbedarf und technische Schulden berücksichtigen
+
+**DARF NICHT:**
+- generische "AI Chat" Features vorschlagen
+- unnötige Microservices oder komplette Rewrites empfehlen
+- unrealistische Großprojekte erzeugen
+- irrelevante Enterprise-Funktionen hinzufügen
+- bestehende Architektur ignorieren
+- doppelte Features empfehlen
+
+## Ablauf
+
+### Phase 1: Repository-Analyse
+
+Repo klonen (falls nötig) und analysieren:
+
+- **Struktur:** Verzeichnisse, Architektur-Pattern, Monorepo vs. Multi-Repo
+- **Tech-Stack:** Sprachen, Frameworks, Abhängigkeiten (package.json, requirements.txt, etc.)
+- **Infrastruktur:** Docker, CI/CD, Deployment-Konfig
+- **APIs:** REST/GraphQL-Endpunkte, Auth, Datenmodelle
+- **Frontend:** Pages, Components, Router, State Management
+- **Qualität:** Tests, Linter, Logging, Monitoring
+- **Dokumentation:** README, CHANGELOG, Inline-Docs
+- **Technische Schulden:** TODOs, Hack-Kommentare, veraltete Dependencies
+
+Priorisierte Dateien lesen:
+1. README.md, LICENSE, CONTRIBUTING.md
+2. Paket-/Build-Dateien (package.json, pyproject.toml, etc.)
+3. Infrastruktur (Dockerfile, docker-compose, CI/CD)
+4. Konfiguration (vite.config, webpack, .env.example)
+5. Backend (routes, controllers, models, middleware)
+6. Frontend (pages, components, layouts, stores)
+7. API-Doku (Swagger/OpenAPI)
+8. Tests
+
+### Phase 2: Zielgruppenanalyse
+
+Ermitteln:
+- Hauptzielgruppe (B2B/B2C, Entwickler/Endkunden)
+- Deployment-Typ (SaaS, Selfhosted, Open Source)
+- Community-Fokus
+
+### Phase 3: Marktanalyse
+
+Web-Recherche durchführen:
+- Ähnliche Open-Source-Projekte finden
+- Kommerzielle Konkurrenzprodukte identifizieren
+- GitHub Issues/Reddit/Hacker News nach Nutzerwünschen durchsuchen
+- Marktstandards und UX-Trends identifizieren
+- Stärken und Schwächen der Konkurrenz dokumentieren
+
+### Phase 4: Feature-Ermittlung
+
+Nur Features vorschlagen, die mindestens eins erfüllen:
+- Klaren Nutzermehrwert bieten
+- UX/Performance/Sicherheit verbessern
+- Marktstandard oder Wettbewerbsvorteil darstellen
+- Developer Experience oder Wartbarkeit erhöhen
+- Accessibility oder Mobile-Unterstützung verbessern
+- Automatisierung oder bessere Integration ermöglichen
+
+### Phase 5: Ergebnispräsentation
+
+Jedes Feature im folgenden Format präsentieren:
+
+```md
+# Feature: <Titel>
+
+## Problem
+Welches Problem wird gelöst?
+
+## Nutzen
+Warum ist das sinnvoll?
+
+## Marktvergleich
+Welche Konkurrenzprodukte besitzen das?
+
+## Aufwand
+- Klein | Mittel | Groß
+
+## Risiko
+- Niedrig | Mittel | Hoch
+
+## Technische Umsetzung
+Kurze Beschreibung der Implementierung.
+
+## Empfehlung
+- Sehr sinnvoll | Sinnvoll | Optional | Nicht empfohlen
+```
+
+Nach Präsentation jedes Features fragen:
+> Soll ich ein Issue dafür erstellen? (ja/nein/später)
+
+Bei "ja": Vorab existierende offene und geschlossene Issues prüfen, um Duplikate zu vermeiden:
+
+```bash
+curl -s "https://git.home.kies-media.de/api/v1/repos/<owner>/<repo>/issues?state=open&limit=50" -H "Authorization: token $GITEA_TOKEN"
+curl -s "https://git.home.kies-media.de/api/v1/repos/<owner>/<repo>/issues?state=closed&limit=50" -H "Authorization: token $GITEA_TOKEN"
+```
+
+Titel und Beschreibung der existierenden Issues mit dem neuen Feature abgleichen. Bei inhaltlicher Überschneidung:
+- Existierendes Issue verlinken und Nutzer informieren ("Es gibt bereits Issue #X")
+- Kein neues Issue erstellen
+
+Nur wenn kein Duplikat gefunden wurde: Issue mit Label `KI` im konfigurierten Gitea-Repo erstellen.
+
+## Erweiterte Qualitätsanalyse
+
+Zusätzlich systematisch prüfen:
+- Fehlende Authentifizierung
+- Schlechte API-Struktur
+- Fehlende Tests
+- Fehlendes Logging
+- Fehlende Metrics
+- Fehlende Observability
+- Fehlende Security Headers
+- Schlechte Performance
+- Schlechte DX
+- Schlechte UX
+- Fehlende Dokumentation
+- Fehlende Automatisierung
+- Fehlendes Onboarding
+- Fehlende Accessibility
+- Fehlende Mobile-Optimierung
+- Schlechte Error-Handling-Struktur
+- Fehlende Retry-Mechanismen
+- Fehlende Rate-Limits
+- Fehlende Backups
+- Fehlende Monitoring-Strategien
+- SEO-Verbesserungen
+- Internationalisierungspotenzial
+- Caching-Strategien
+
+## Konfiguration
+
+- Standard-Repo: `greggy/landingpage-haus-schleusingen` (Haus-Repo)
+- Gitea API: `$GITEA_TOKEN` für Auth
+- Issue-Label: `KI` für Pipeline-Kompatibilität

skills/self-improving-agent/.clawhub/origin.json

@@ -3,5 +3,5 @@
   "registry": "https://clawhub.ai",
   "slug": "self-improving-agent",
   "installedVersion": "3.0.21",
-  "installedAt": 1778353984557
+  "installedAt": 1779312527914
 }