splatstudio – Tableau de bord GitHub

Compétence Tableau de bord GitHub

Créez un tableau de bord analytique de dépôt GitHub sur un seul écran, dans le style visuel FlowAI / Soft Paper Workspace : toile blanc cassé chaud, panneaux blancs arrondis, barre latérale gauche fixe, cartes KPI compactes, pastilles pastel, tableaux denses et filets à faible contraste.

Carte des ressources

github-dashboard/
├── SKILL.md
├── example.html                         ← tableau de bord de référence rendu
└── references/
    ├── template.html                    ← modèle HTML compatible avec les artifacts dynamiques
    ├── example-data.json                ← forme normalisée des données GitHub publiques
    ├── artifact-example.json            ← entrée minimale de création d'artifact dynamique
    └── provenance-example.json          ← exemple de source/provenance sécurisée

Quand utiliser cette compétence

Utilisez-la lorsque l'utilisateur demande un tableau de bord ou un rapport concernant un seul dépôt GitHub, par exemple :

• tableau de bord de croissance d'un dépôt
• rapport d'état d'un projet open-source
• analyse des étoiles / forks / contributeurs GitHub
• page d'activité des issues et pull requests
• tableau de bord pour mainteneur / contributeur

Si l'utilisateur demande une actualisation, une auditabilité de la source, ou des mises à jour planifiées, produisez l'ensemble des sources d'artifact dynamique (template.html, data.json, artifact.json, provenance.json) et respectez le contrat live-artifact. S'il ne demande qu'un artifact visuel, produisez un index.html autonome.

Flux de travail

1. Résoudre le périmètre du dépôt

   • Analysez owner/repo à partir de la demande.
   • Cette compétence v1 est limitée à un seul dépôt. Si plusieurs dépôts sont demandés, demandez à l'utilisateur de choisir le dépôt principal ou créez un tableau de bord par dépôt.
   • Si le dépôt est manquant, posez une question concise pour obtenir l'URL GitHub ou owner/repo.

2. Collecter les données GitHub publiques

   • Préférez l'interface en ligne de commande GitHub / l'API pour les données publiques lorsque disponibles.
   • Étoiles/forks/watchers/issues ouvert·es actuels : GET /repos/{owner}/{repo} (stargazers_count, forks_count, watchers_count, open_issues_count).
   • Contributeurs : paginez GET /repos/{owner}/{repo}/contributors?per_page=100&page=N, triez par contributions décroissant, et prenez les N premiers utilisés par le tableau de bord. Si seule la page 1 est disponible, indiquez les totaux comme estimations de première page.
   • Issues : utilisez l'API de recherche GitHub (repo:{owner}/{repo} is:issue) pour les totaux, ou paginez GET /repos/{owner}/{repo}/issues?state=all et filtrez les éléments ayant un champ pull_request.
   • Pull requests : utilisez l'API de recherche GitHub (repo:{owner}/{repo} is:pr) pour les totaux, ou paginez GET /repos/{owner}/{repo}/pulls?state=all et comptez les pages via l'en-tête Link.
   • Activité récente : combinez les issues et pull requests les plus récentes, normalisez-les en lignes prêtes à afficher, et limitez l'aperçu à 5–10 éléments.
   • Métriques de croissance/delta : l'API REST GitHub n'expose pas les historiques complets de variation des étoiles/forks. Utilisez GraphQL, des captures d'événements stargazer, l'API Events lorsque disponible, ou marquez explicitement les deltas comme estimés/synthétiques dans provenance.json.
   • Ne stockez pas de jetons d'authentification, d'enveloppes HTTP brutes, de cookies, d'en-têtes de limite de débit, ni de métadonnées privées.

3. Normaliser en données de tableau de bord

   • repository requis : name, fullName, url, description, language, license, created, lastUpdated.
   • metrics requis : étoiles, forks, contributeurs, issues, pull requests. Stockez les totaux prêts à afficher ainsi que les petites variations ou notes de croissance.
   • contributors requis : les 5 à 8 principaux contributeurs avec login, avatar et contributions.
   • recentActivity requis : lignes prêtes à afficher avec title, typeText, typeClass, label, labelClass, author, authorAvatar et updated. Ne vous fiez pas aux conditionnelles de modèle pour la commutation issue/PR.
   • Les données des graphiques peuvent être synthétiques uniquement lorsque GitHub n'expose pas l'historique exact ; documentez la transformation dans provenance.

4. Appliquer le système visuel

   • Utilisez les jetons actifs de DESIGN.md lorsqu'ils sont présents.
   • Si aucun système de design n'est fourni, utilisez les valeurs par défaut de Soft Paper reflétées dans references/template.html : toile #F2F2F0, cartes blanches, bordures #ECECEA, encre #0A0A0A, typographie Geist/Inter, barre latérale 256px, barre supérieure 48px, rayon de carte 16px.
   • Gardez la couleur réduite et sémantique : vert pour les métriques saines, ambre pour les avertissements, bleu pour les labels de fonctionnalité/PR, rouge uniquement pour les défauts ou les risques.

5. Organiser la page

   • Coque : barre latérale 256px + panneau principal, tous deux blancs, arrondis 16px, bordure de 1px.
   • Barre supérieure : contexte du dépôt à gauche, actions d'actualisation/exportation/action à droite.
   • En-tête : nom du dépôt, description et ligne date/paramètres/actions.
   • Bande KPI : 5 cartes compactes pour les étoiles, forks, contributeurs, issues, PR.
   • Grille principale : répartition 2fr/1fr avec un graphique de croissance ou un tableau d'activité à gauche et les principaux contributeurs/cartes d'état à droite.
   • Pied de page : note de provenance/dernière mise à jour en petit texte atténué.

6. Écrire l'artifact

   • Pour un artifact statique, écrivez un index.html autonome avec CSS en ligne et aucune bibliothèque JS externe.
   • Pour un artifact dynamique, écrivez template.html, data.json, artifact.json et provenance.json ; index.html est dérivé par le démon.
   • Étiquetez les régions majeures avec des valeurs data-od-id stables : sidebar, topbar, repo-header, kpi-strip, growth-chart, contributors, activity, provenance.

Règles visuelles

• Mode clair uniquement.
• Barre latérale fixe de 256 px sur desktop ; empilement sur écrans étroits.
• 4 ou 5 cartes KPI dans la première ligne.
• Utilisez des chiffres tabulaires pour tous les décomptes.
• Les avatars sont circulaires, 28–32 px dans les tableaux et listes de contributeurs.
• Les tableaux utilisent un texte de corps de 13 px, des étiquettes de colonne en majuscules de 11 px, des séparateurs de ligne de 1 px.
• Les cartes utilisent des bordures fines et une ombre à peine visible au maximum : 0 1px 2px rgba(10,10,10,.04), 0 1px 1px rgba(10,10,10,.02).
• N'utilisez pas de dégradés, sauf pour les icônes de workflow/dépôt de petite taille.
• Ne rendez pas la page identique à GitHub elle-même. Il s'agit d'un tableau de bord opérationnel personnalisé, pas d'un clone de l'interface utilisateur GitHub.

Auto-vérification

• Chaque métrique a une source ou une note de provenance.
• Aucune donnée privée ni aucune information d'identification ne sont persistées.
• Les étiquettes de données sont spécifiques au dépôt, pas des espaces réservés.
• L'écran reste lisible à 50 % de zoom.
• Le tableau de bord utilise au plus une action principale noire unie par zone.
• Les étiquettes de statut et les pastilles issue/PR sont des pastilles pastel, pas des badges saturés.