154 lines
5.0 KiB
Markdown
154 lines
5.0 KiB
Markdown
---
|
|
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
|