onovich/RepoCover

Que fait RepoCover ?

Créez une prévisualisation sociale spécifique à un dépôt, lisible même en miniature. Privilégiez une composition déterministe et modifiable plutôt qu'une bannière générique.

Invariants du produit

• Générer un raster exact 1280×640, normalement PNG, d'une taille inférieure à 1 000 000 octets.
• Conserver une source modifiable, normalement SVG, à côté du raster.
• Ancrer les revendications, métriques, captures d'écran et preuves visibles dans les éléments du dépôt.
• Préserver l'identité du dépôt plutôt que d'imposer un style uniforme.
• Valider la taille réelle et une miniature 320×160 sur des fonds clairs et sombres.
• Traiter la création d'image et le téléchargement sur GitHub comme des autorisations séparées.
• Ne pas suggérer une affiliation ou un aval de GitHub.

Charger les bonnes références

Lisez ces deux fichiers pour chaque couverture :

• references/common-quality.md pour les règles de composition et de rejet universelles.
• references/design-ledger-template.md pour l'enregistrement des preuves, de la conception et de la validation.

Lisez ensuite uniquement la route applicable :

• Lisez references/source-material.md lorsqu'il existe des captures d'écran, des captures d'exécution, des logos, des illustrations, des SVG, des sprites, des textures ou d'autres visuels significatifs.
• Lisez references/cold-start.md lorsqu'il n'existe aucune capture d'écran, capture d'exécution, marque déposée ou visuel principal appartenant au dépôt.
• Lisez references/version-regression.md lors du rafraîchissement d'une couverture existante, de la comparaison de candidats ou de la génération d'un lot versionné.

Ne chargez pas une route non pertinente simplement parce qu'elle existe. references/design-recipes.md n'est qu'un index de compatibilité pour les anciennes invites.

Workflow

1. Inspecter et délimiter les preuves

Lisez les fichiers AGENTS.md applicables, le README, les métadonnées du paquet, les chemins sources significatifs, les ressources visuelles et toute prévisualisation sociale existante. Identifiez :

• le nom du dépôt et la tâche utilisateur principale ;
• une déclaration de valeur concrète ;
• au maximum trois points de preuve ;
• la preuve produit la plus forte ;
• l'identité visuelle établie et les faits secondaires à exclure ;
• le mode de preuve : remote-static, local-static, build-tested ou runtime-tested.

Ne laissez jamais entendre qu'une construction, un exécution, une scène ou un test a été effectué si seules des preuves statiques ont été inspectées. Si les exigences d'image de GitHub ont pu changer, vérifiez-les auprès de la documentation officielle de GitHub.

Pour un dépôt distant, utilisez les preuves GitHub disponibles (publiques ou authentifiées) pour inspecter son README, son arborescence, ses manifestes, les fichiers source significatifs, la prévisualisation actuelle et les ressources visuelles les plus pertinentes. Conservez les sorties dans un répertoire durable visible par l'utilisateur et enregistrez les URLs sources et les limites des revendications. Si aucun temps d'exécution ou interface représentative n'est accessible, mentionnez cette limitation au lieu de prétendre que la preuve distante équivaut à un aperçu local fonctionnel. Les projets locaux prévisualisables, en particulier les projets web avec une interface existante, fournissent généralement les preuves visuelles les plus riches.

2. Rédiger le registre et choisir la route

Créez un registre de conception à partir du modèle fourni avant de dessiner. Enregistrez au minimum :

• Promesse, preuve, exclusion ;
• mode de preuve et limites des revendications ;
• diagnostic des sources matérielles ou squelette sémantique pour démarrage à froid ;
• route de production et d'interprétation choisie ;
• décisions sur le matériau, le rôle des ressources, la topologie et les lignes ;
• version de sortie, validation et verdict de promotion, le cas échéant.

Choisissez la plus petite route de production qui préserve l'identité :

• SVG natif au code — privilégié : outils de développement, diagrammes, graphiques, logos, bibliothèques et systèmes visuels inférés.
• Hybride capture d'écran ou source : uniquement lorsqu'un artefact source autonome reste la preuve la plus claire après diagnostic.
• Hybride illustration : uniquement lorsque l'illustration est centrale à l'identité du dépôt ; générez l'œuvre sans texte important et superposez le texte exact en SVG.

N'invoquez pas la génération d'images simplement pour imiter un système vectoriel établi.

3. Construire et versionner la source modifiable

Par défaut, utilisez docs/social-preview.svg et docs/social-preview.png sauf si le dépôt a une convention de ressources claire ou si l'utilisateur nomme une autre destination.

• Utilisez un viewBox de 1280 640 et un arrière-plan pleine toile.
• Gardez le contenu essentiel dans une zone de sécurité extérieure d'environ 72 px.
• Répartissez le texte, la preuve produit, les légendes et la signature dans des régions non superposées.
• Utilisez les polices système sauf si le dépôt fournit une police sous licence appropriée.
• Incorporez les preuves locales ou reproduisez-les avec des primitives SVG déterministes ; évitez les dépendances d'exécution externes.
• Coupez les graphiques, captures d'écran, marques répétées et formes d'onde dans leurs régions respectives.
• Conservez une couverture existante et créez un homologue versionné, sauf si le remplacement est explicitement demandé.

4. Rendre et valider mécaniquement

Rendez avec le script fourni lorsque Sharp est disponible :

node <skill-directory>/scripts/render_svg.mjs <source.svg> <output.png>

Utilisez --force uniquement lorsque le remplacement de la sortie nommée est dans le périmètre. Dans Codex Desktop, chargez les dépendances de l'espace de travail et utilisez l'exécutable Node retourné et le chemin du paquet via NODE_PATH ; n'installez pas de dépendance sans autorisation.

Validez le PNG et le SVG :

python <skill-directory>/scripts/validate_preview.py <output.png> --svg <source.svg>

Créez la feuille de miniature standard :

node <skill-directory>/scripts/create_review_sheet.mjs <preview.png> <review.png>

Sur les pages de code héritées Windows, définissez PYTHONUTF8=1 pour les outils qui lisent des sources UTF-8.

5. Valider visuellement

Inspectez le raster en taille réelle et inspectez la feuille de révision générée. Confirmez :

• le nom du dépôt et la déclaration de valeur restent lisibles à 320×160 ;
• la preuve produit est reconnaissable et techniquement fidèle ;
• le texte, les marques, les recadrages, les panneaux et les éléments décoratifs n'entrent pas en collision ou ne sont pas coupés ;
• la composition fonctionne sur des fonds clairs et sombres ;
• chaque élément visible correspond à la promesse ou à la preuve ;
• le design passe tous les vetos spécifiques à la route applicables.

Scannez de gauche à droite et de haut en bas, corrigez un défaut nommé à la fois, re-rendez et relancez la validation. Ne livrez pas un défaut connu.

Pour les lots, créez une feuille de contact et inspectez la dérive de modèle partagé accidentel avant de promouvoir les candidats.

6. Télécharger uniquement sur demande

Créer une ressource n'autorise pas à modifier les paramètres GitHub. Lorsque le téléchargement est explicitement demandé, ouvrez :

https://github.com/<owner>/<repo>/settings

Utilisez Social preview → Edit → Upload an image… et suivez la politique de confirmation de l'interface active. Après le téléchargement, récupérez la page publique du dépôt et vérifiez que og:image pointe vers la nouvelle image 1280×640. Ne signalez pas le succès depuis la miniature des paramètres.

Remise

Affichez l'image finale et signalez :

• chemin de la source modifiable ;
• chemin du raster, format, dimensions et taille en octets ;
• justification de conception en une phrase ;
• statut de validation et de promotion de version ;
• statut du téléchargement : non demandé, en attente ou vérifié publiquement.

Ne laissez pas les sorties liées au projet uniquement dans un répertoire temporaire ou appartenant au modèle.