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

name, description

name

description

project-market-feature-analyst

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:

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

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