---
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