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

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