onovich/RepoCover

Was macht RepoCover?

Erstellen Sie eine Repository-spezifische Social Preview, die auch in Miniaturansicht lesbar bleibt. Bevorzugen Sie deterministische, bearbeitbare Komposition gegenüber einem generischen generierten Banner.

Produktinvarianten

• Liefern Sie eine exakte 1280×640 Rastergrafik, normalerweise PNG, unter 1.000.000 Bytes.
• Halten Sie eine bearbeitbare Quelle, normalerweise SVG, neben der Rastergrafik.
• Verankern Sie sichtbare Behauptungen, Metriken, Screenshots und Nachweise in Repository-Belegen.
• Bewahren Sie die Identität des Repositorys, anstatt einen einheitlichen Stil aufzuzwingen.
• Validieren Sie die volle Größe und 320×160 auf hellen und dunklen Hintergründen.
• Behandeln Sie Bilderstellung und GitHub-Upload als separate Autorisierungsgrenzen.
• Vermitteln Sie keine GitHub-Zugehörigkeit oder -Unterstützung.

Laden der richtigen Referenzen

Lesen Sie diese beiden Dateien für jedes Cover:

• references/common-quality.md für universelle Kompositions- und Ablehnungskriterien.
• references/design-ledger-template.md für den Nachweis-, Design- und Validierungsdatensatz.

Lesen Sie dann nur die zutreffende Route:

• Lesen Sie references/source-material.md, wenn Screenshots, Laufzeitaufnahmen, Logos, Illustrationen, SVGs, Sprites, Texturen oder andere aussagekräftige visuelle Elemente vorhanden sind.
• Lesen Sie references/cold-start.md, wenn kein verwendbarer Screenshot, keine Laufzeitaufnahme, kein Markenzeichen oder kein primäres visuelles Element aus dem Repository vorhanden ist.
• Lesen Sie references/version-regression.md, wenn Sie ein vorhandenes Cover aktualisieren, Kandidaten vergleichen oder einen versionierten Batch erstellen.

Laden Sie keine irrelevante Route nur, weil sie existiert. references/design-recipes.md ist nur ein Kompatibilitätsindex für ältere Eingabeaufforderungen.

Arbeitsablauf

1. Prüfen und eingrenzen der Belege

Lesen Sie alle relevanten AGENTS.md-Dateien, die README-Datei, Paketmetadaten, aussagekräftige Quellpfade, visuelle Assets und alle vorhandenen Social Previews. Identifizieren Sie:

• Repository-Name und primäre Benutzeraufgabe;
• eine konkrete Wertaussage;
• höchstens drei Nachweispunkte;
• den stärksten Produktnachweis;
• etablierte visuelle Identität und auszuschließende Sekundärfakten;
• Nachweismodus: remote-static, local-static, build-tested oder runtime-tested.

Geben Sie niemals vor, dass ein Build, eine Laufzeit, eine Szene oder ein Test ausgeführt wurde, wenn nur statische Belege geprüft wurden. Wenn sich die Bildanforderungen von GitHub geändert haben könnten, überprüfen Sie diese anhand der offiziellen GitHub-Dokumentation.

Verwenden Sie für ein Remote-Repository die verfügbaren öffentlichen oder authentifizierten GitHub-Belege, um dessen README-Datei, Baumstruktur, Manifeste, aussagekräftige Quelldateien, aktuelle Vorschau und stärkste visuelle Assets zu prüfen. Halten Sie die Ausgaben in einem dauerhaften, benutzersichtbaren Verzeichnis und zeichnen Sie Quell-URLs und Behauptungsgrenzen auf. Wenn keine Laufzeit oder repräsentative Schnittstelle erreicht werden kann, geben Sie diese Einschränkung an, anstatt vorzutäuschen, dass der Remote-Beleg einer funktionierenden lokalen Vorschau entspricht. Vorschaufähige lokale Projekte, insbesondere Webprojekte mit einer bestehenden Schnittstelle, liefern in der Regel die reichhaltigsten visuellen Belege.

2. Das Protokoll schreiben und die Route wählen

Erstellen Sie vor dem Zeichnen ein Designprotokoll aus der gebündelten Vorlage. Halten Sie mindestens fest:

• Versprechen, Nachweis, Ausschluss;
• Nachweismodus und Behauptungsgrenzen;
• Diagnose des Quellmaterials oder semantisches Grundgerüst für den Kaltstart;
• gewählte Produktions- und Interpretationsroute;
• Material-, Asset-Rollen-, Topologie- und Linienentscheidungen;
• Ausgabeversion, Validierungs- und Förderurteil, sofern zutreffend.

Wählen Sie die kleinste Produktionsroute, die die Identität bewahrt:

• Code-natives SVG – bevorzugt: Entwicklerwerkzeuge, Diagramme, Grafiken, Logos, Bibliotheken und abgeleitete visuelle Systeme.
• Screenshot- oder Quellhybrid: nur, wenn ein in sich geschlossenes Quellartefakt nach der Diagnose der klarste Nachweis bleibt.
• Illustrationshybrid: nur, wenn die Illustration für die Identität des Repositorys zentral ist; erstellen Sie Kunstwerke ohne wichtigen Text und überlagern Sie exakte Wortlaute in SVG.

Rufen Sie keine Bildgenerierung auf, nur um ein etabliertes Vektorsystem nachzuahmen.

3. Erstellen und versionieren der bearbeitbaren Quelle

Standardmäßig docs/social-preview.svg und docs/social-preview.png, sofern das Repository keine klare Asset-Konvention hat oder der Benutzer ein anderes Ziel angibt.

• Verwenden Sie einen viewBox von 1280 640 und einen vollflächigen Hintergrund.
• Halten Sie wesentliche Inhalte innerhalb eines äußeren Sicherheitsabstands von etwa 72 px.
• Teilen Sie Kopie, Produktnachweis, Bildunterschriften und Signatur in nicht überlappende Bereiche auf.
• Verwenden Sie Systemschriftarten, sofern das Repository keine geeignete lizenzierte Schriftart mitliefert.
• Betten Sie lokale Belege ein oder reproduzieren Sie diese mit deterministischen SVG-Primitiven; vermeiden Sie externe Laufzeitabhängigkeiten.
• Beschneiden Sie Diagramme, Screenshots, wiederholte Markierungen und Wellenformen auf ihre eigenen Bereiche.
• Bewahren Sie ein vorhandenes Cover auf und erstellen Sie eine versionierte Kopie, es sei denn, der Ersatz wird ausdrücklich angefordert.

4. Mechanisch rendern und validieren

Rendern Sie mit dem gebündelten Skript, wenn Sharp verfügbar ist:

node <skill-verzeichnis>/scripts/render_svg.mjs <quell.svg> <ausgabe.png>

Verwenden Sie --force nur, wenn das Ersetzen der benannten Ausgabe vorgesehen ist. Laden Sie in Codex Desktop die Workspace-Abhängigkeiten und verwenden Sie das zurückgegebene Node-ausführbare Programm und den Paketpfad über NODE_PATH; installieren Sie keine Abhängigkeit ohne Erlaubnis.

Validieren Sie das PNG und SVG:

python <skill-verzeichnis>/scripts/validate_preview.py <ausgabe.png> --svg <quell.svg>

Erstellen Sie das Standard-Miniaturansichtsblatt:

node <skill-verzeichnis>/scripts/create_review_sheet.mjs <vorschau.png> <überprüfung.png>

Legen Sie unter Windows mit Legacy-Codepages PYTHONUTF8=1 für Tools fest, die UTF-8-Quellen lesen.

5. Visuell validieren

Prüfen Sie die Rastergrafik in voller Größe und prüfen Sie das generierte Überprüfungsblatt. Bestätigen Sie:

• Repository-Name und Wertaussage bleiben bei 320×160 lesbar;
• der Produktnachweis ist erkennbar und technisch treu;
• Text, Markierungen, Beschneidungen, Panels und dekorative Elemente kollidieren oder überschneiden sich nicht;
• die Komposition funktioniert auf hellen und dunklen Hintergründen;
• jedes sichtbare Element entspricht dem Versprechen oder Nachweis;
• das Design besteht jedes anwendbare routenspezifische Veto.

Scannen Sie von links nach rechts und von oben nach unten, beheben Sie jeweils einen benannten Fehler, rendern Sie neu und führen Sie die Validierung erneut durch. Geben Sie keinen bekannten Fehler weiter.

Erstellen Sie für Batches ein Kontaktblatt und prüfen Sie auf unbeabsichtigte gemeinsame Vorlagenabweichungen, bevor Sie Kandidaten fördern.

6. Nur auf Anfrage hochladen

Das Erstellen eines Assets autorisiert nicht das Ändern von GitHub-Einstellungen. Wenn das Hochladen ausdrücklich angefordert wird, öffnen Sie:

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

Verwenden Sie Social preview → Edit → Upload an image… und befolgen Sie die aktive UI-Bestätigungsrichtlinie. Rufen Sie nach dem Hochladen die öffentliche Repository-Seite ab und verifizieren Sie, dass og:image in das neue 1280×640 Bild aufgelöst wird. Melden Sie den Erfolg nicht allein anhand der Einstellungen-Miniaturansicht.

Übergabe

Zeigen Sie das endgültige Bild und berichten Sie:

• Pfad der bearbeitbaren Quelle;
• Rasterpfad, Format, Abmessungen und Byte-Größe;
• ein Ein-Satz-Designbegründung;
• Validierungs- und Versionsförderungsstatus;
• Upload-Status: nicht angefordert, ausstehend oder öffentlich verifiziert.

Hinterlassen Sie projektbezogene Ausgaben nicht nur in einem temporären oder modell-eigenen Verzeichnis.