SplatStudio (GitHub Dashboard Skill)

GitHub Dashboard Skill – (SplatStudio)

Erstelle ein einseitiges GitHub-Repository-Analyse-Dashboard im visuellen Stil von FlowAI / Soft Paper Workspace: warmer cremefarbener Hintergrund, weiße abgerundete Panels, eine feste linke Seitenleiste, kompakte KPI-Karten, pastellfarbene Pillen, dichte Tabellen und kontrastarme Haarlinien.

Ressourcenübersicht

github-dashboard/
├── SKILL.md
├── example.html                         ← gerendertes Referenz-Dashboard
└── references/
    ├── template.html                    ← Live-Artefakt-kompatibles HTML-Template
    ├── example-data.json                ← normalisierte öffentliche GitHub-Datenstruktur
    ├── artifact-example.json            ← minimale Eingabe für Live-Artefakt-Erstellung
    └── provenance-example.json          ← sicheres Quellen-/Provenienz-Beispiel

Wann dieses Skill verwendet werden sollte

Verwende dieses Skill, wenn der Benutzer nach einem Dashboard oder Bericht über ein einzelnes GitHub-Repository fragt, zum Beispiel:

• Repository-Wachstums-Dashboard
• Open-Source-Projekt-Gesundheitsbericht
• GitHub-Sterne-/Forks-/Mitwirkenden-Analyse
• Issue- und Pull-Request-Aktivitätsseite
• Maintainer-/Mitwirkenden-Dashboard

Wenn der Benutzer nach Aktualisierbarkeit, Quellprüfbarkeit oder geplanten Updates fragt, erstelle den Live-Artefakt-Quellsatz (template.html, data.json, artifact.json, provenance.json) und folge dem live-artifact-Vertrag. Wenn nur ein visuelles Artefakt benötigt wird, erstelle ein eigenständiges index.html.

Arbeitsablauf

1. Repository-Umfang ermitteln

   • Extrahiere owner/repo aus der Aufgabenbeschreibung.
   • Dieses v1-Skill ist auf ein Repository beschränkt. Wenn mehrere Repositories angefordert werden, bitte den Benutzer, das primäre Repository auszuwählen oder erstelle ein Dashboard pro Repository.
   • Wenn das Repository fehlt, stelle eine kurze Frage nach der GitHub-URL oder owner/repo.

2. Öffentliche GitHub-Daten sammeln

   • Bevorzuge GitHub CLI/API für öffentliche Repository-Daten, wenn verfügbar.
   • Aktuelle Sterne/Forks/Watcher/offene Issues: GET /repos/{owner}/{repo} (stargazers_count, forks_count, watchers_count, open_issues_count).
   • Mitwirkende: Seite GET /repos/{owner}/{repo}/contributors?per_page=100&page=N durchgehen, absteigend nach contributions sortieren und die obersten N (vom Dashboard verwendet) aufnehmen. Wenn nur Seite 1 verfügbar ist, markiere die Summen als Schätzwerte der ersten Seite.
   • Issues: Verwende die GitHub Search API (repo:{owner}/{repo} is:issue) für Gesamtzahlen oder blättere durch GET /repos/{owner}/{repo}/issues?state=all und filtere Einträge mit dem Feld pull_request heraus.
   • Pull Requests: Verwende die GitHub Search API (repo:{owner}/{repo} is:pr) für Gesamtzahlen oder blättere durch GET /repos/{owner}/{repo}/pulls?state=all und zähle Seiten über den Link-Header.
   • Aktuelle Aktivitäten: Kombiniere die neuesten Issues und Pull Requests, normalisiere sie zu anzeigebereiten Zeilen und begrenze die Vorschau auf 5–10 Einträge.
   • Wachstums-/Delta-Metriken: GitHub REST stellt keine vollständigen historischen Stern-/Fork-Deltas bereit. Verwende GraphQL, Stargazer-Ereignis-Snapshots, die Events API (wo verfügbar) oder markiere Deltas explizit als geschätzt/synthetisch in provenance.json.
   • Speichere keine Authentifizierungstoken, rohen HTTP-Envelopes, Cookies, Rate-Limit-Header oder privaten Metadaten.

3. In Dashboard-Daten normalisieren

   • Erforderlich repository: name, fullName, url, description, language, license, created, lastUpdated.
   • Erforderlich metrics: Sterne, Forks, Mitwirkende, Issues, Pull Requests. Speichere anzeigebereite Summen plus kleine Deltas oder Wachstumsnotizen.
   • Erforderlich contributors: Top 5–8 Mitwirkende mit login, avatar und contributions.
   • Erforderlich recentActivity: Anzeigebereite Zeilen mit title, typeText, typeClass, label, labelClass, author, authorAvatar und updated. Verlasse dich nicht auf Template-Bedingungen für den Issue/PR-Wechsel.
   • Diagrammdaten dürfen nur dann synthetisch sein, wenn GitHub den genauen Verlauf nicht preisgibt; dokumentiere die Transformation im Provenienz-Objekt.

4. Das visuelle System anwenden

   • Verwende die aktiven DESIGN.md-Tokens, wenn vorhanden.
   • Wenn kein Designsystem angegeben ist, verwende die Standardwerte von Soft Paper, die in references/template.html reflektiert werden: #F2F2F0-Hintergrund, weiße Karten, #ECECEA-Ränder, #0A0A0A-Schrift, Geist/Inter-Typografie, 256px Seitenleiste, 48px obere Leiste und 16px Kartenradius.
   • Halte die Farben klein und semantisch: Grün für gesunde Metriken, Bernstein für Warnungen, Blau für Feature/PR-Labels, Rot nur für Defekte oder Risiken.

5. Die Seite layouten

   • Shell: 256px Seitenleiste + Hauptpanel, beide weiß, abgerundet 16px, 1px Haarlinie als Rand.
   • Obere Leiste: Repository-Kontext links, Aktualisierungs-/Export-/Aktionsmöglichkeiten rechts.
   • Header: Repository-Name, Beschreibung und Datum/Einstellungen/Aktionen-Zeile.
   • KPI-Streifen: 5 kompakte Karten für Sterne, Forks, Mitwirkende, Issues, PRs.
   • Hauptraster: 2fr/1fr-Aufteilung mit einem Wachstumsdiagramm oder einer Aktivitätstabelle links und Top-Mitwirkenden/Gesundheitskarten rechts.
   • Footer: Provenienz-/Letzte-Aktualisierung-Notiz in kleiner, dezent getönter Schrift.

6. Das Artefakt schreiben

   • Für ein statisches Artefakt schreibe ein eigenständiges index.html mit Inline-CSS und ohne externe JS-Bibliotheken.
   • Für ein Live-Artefakt schreibe template.html, data.json, artifact.json und provenance.json; index.html wird vom Daemon abgeleitet.
   • Markiere Hauptbereiche mit stabilen data-od-id-Werten: sidebar, topbar, repo-header, kpi-strip, growth-chart, contributors, activity, provenance.

Visuelle Regeln

• Nur Hellmodus.
• 256px feste Seitenleiste auf Desktop; auf schmalen Bildschirmen gestapelt.
• 4 oder 5 KPI-Karten in der ersten Zeile.
• Verwende Tabellenziffern für alle Zählungen.
• Avatare sind rund, 28–32px in Tabellen und Mitwirkenden-Listen.
• Tabellen verwenden 13px Fließtext, 11px Großbuchstaben-Spaltenüberschriften, 1px Zeilentrenner.
• Karten verwenden Haarlinien-Ränder und höchstens einen kaum sichtbaren Schatten: 0 1px 2px rgba(10,10,10,.04), 0 1px 1px rgba(10,10,10,.02).
• Verwende keine Verläufe, außer bei kleinen Arbeitsablauf-/Repository-Icon-Platzhaltern.
• Lass die Seite nicht wie GitHub selbst aussehen. Dies ist ein benutzerdefiniertes operatives Dashboard, kein GitHub-UI-Klon.

Selbstüberprüfung

• Jede Metrik hat eine Quelle oder eine Provenienz-Notiz.
• Keine privaten Daten oder Zugangsdaten werden gespeichert.
• Datenbezeichnungen sind spezifisch für das Repository, keine Platzhalter.
• Der Bildschirm bleibt bei 50% Zoom gut lesbar.
• Das Dashboard verwendet höchstens eine solide schwarze primäre Aktion pro Bereich.
• Status-Labels und Issue/PR-Chips sind pastellfarbene Pillen, keine gesättigten Badges.