README von GitHub verschönern

Verwandle eine Repository-Startseite oder ein gewünschtes visuelles Asset in eine prägnante, themenspezifische visuelle Geschichte. Behandle Markdown als Inhaltsebene, deterministisches SVG als Layoutsystem und generiertes Rastermaterial als optionalen visuellen Bestandteil.

Arbeitsablauf

1. Bestätige den Modus vor der Bearbeitung

Verwende genau einen Ausführungsmodus:

README-Modus — verbessere das gesamte README: Informationsreihenfolge, Kopierhierarchie, Korrektur, Markdown und visuelles System.
Asset-Only-Modus — erstelle nur die angeforderte statische SVG oder den visuellen Assetsatz. Statisches SVG ist die Voreinstellung. Erst wenn der Benutzer explizit in sinnvolle Bewegung einwilligt, liefere optional ein GitHub-sicheres GIF, während das SVG als editierbares Fallback erhalten bleibt. Schreibe, ordne neu oder bette nichts in das README ein, es sei denn, der Benutzer fügt diesen Umfang explizit hinzu.

Wenn der Modus nicht explizit ist, stelle eine kompakte Frage, bevor du Änderungen vornimmst:

Möchtest du, dass ich das gesamte README verbessere oder nur visuelle Assets erstelle? Wenn Asset-Only, sag mir bitte, ob du einen Hero, Abschnittsüberschriften, einen Workflow, ein Badge, eine Bewegungsgrafik oder einen koordinierten Satz benötigst.

Wenn ein Hero, Badge, Workflow oder Diagramm sinnvolle Bewegung aufweist und der Benutzer nicht statisch oder animiert angegeben hat, stelle eine kompakte Folgefrage:

Soll dies als statisches SVG bleiben, oder möchtest du eine GitHub-sichere GIF-Animation, wobei das SVG als editierbares Fallback erhalten bleibt?

GIF ist Opt-In und niemals die Voreinstellung. Wenn der Benutzer ablehnt, nicht antwortet oder keinen sinnvollen Bewegungsfall hat, fahre mit reinem statischen SVG fort. Frage nicht, wenn die Bewegung rein dekorativ wäre oder der Benutzer die Ausgabe bereits gewählt hat. Schreibgeschützte Inspektion ist vor der Antwort erlaubt, wenn sie hilft, das Repository zu verstehen. Interpretiere nicht „diese Fähigkeit verwenden“, einen Repository-Pfad oder „verschönere es“ als Erlaubnis, das gesamte README zu ändern. Sobald der Benutzer den Asset-Only-Modus wählt, erfordert die Ausweitung auf README-Bearbeitungen eine neue Autorisierung.

Wenn der Benutzer explizit nur ein Audit anfordert, auditieren ohne zu bearbeiten und zwinge nicht die Zwei-Modus-Frage.

2. Vor dem Entwerfen inspizieren

Lies das vorhandene README, den Repository-Baum, Paketmetadaten, Screenshots, Beispiele, Design-Tokens, das Logo und reale Ausgaben.
Im Asset-Only-Modus inspiziere nur den Kontext, der benötigt wird, um die angeforderten Assets zu entwerfen. Das Lesen des README für den Kontext autorisiert nicht, es zu ändern.
Überprüfe bei einer GitHub-URL die aktuelle Remote-Seite und den Standard-Branch, bevor du Änderungen vorschlägst.
Identifiziere die Zielgruppe, das gelöste Problem, den klarsten Beweis, den kürzesten Weg zur ersten Nutzung und alle Behauptungen, denen es an Beweisen mangelt.
Bewahre nicht zusammenhängende Benutzeränderungen. Beginne schreibgeschützt; committe, pushe, benenne um oder veröffentliche nichts ohne explizite Autorisierung.

3. Bestätige die visuelle Implementierung vor der Erstellung von Hero-ähnlichen Assets

Für einen Hero, ein großes Banner, eine Schautafel oder ein ausdrucksstarkes Titelsystem, bei dem beide Implementierungen möglich sind, erkläre den Unterschied und frage, bevor du das Asset erstellst:

Welche Implementierung möchtest du?

Reines SVG — vollständig deterministisch, leichtgewichtig, scharf skalierbar, einfach zu bearbeiten und am besten für Typografie, Diagramme, Code, Symbole und geometrische oder Pixel-Art-Szenen geeignet. Es verwendet keine Bildgenerierung und ist schwächer bei realistischen Personen, Haaren, organischen Texturen, komplexen Materialien oder filmischer Beleuchtung.

Hybride SVG-Komposition — verwende SVG für Layout und Typografie, optional ImageGen für ein projektspezifisches Rastersubjekt, entferne seinen Hintergrund, wenn angemessen, und komponiere die Ebenen zu einem endgültigen PNG/WebP. Es unterstützt reichhaltigere Charaktere, Materialien und Beleuchtung, ist aber schwerer, teilweise stochastisch und erfordert Generierung plus visuelle Validierung. Behalte die SVG-Layout-Quelle und das transparente Subjekt-PNG.

Stelle diese Frage nicht, wenn der Benutzer bereits eine Implementierung gewählt hat, ein Audit angefordert hat oder das Asset offensichtlich deterministisch ist, wie ein Workflow, Architekturdiagramm, Badge, kompakte Abschnittsüberschrift oder code-native Illustration. Schlage keine hybride Komposition vor, nur um Dekoration hinzuzufügen. Bevorzuge echte Screenshots, Ausgaben, Logos oder vorhandene Projektgrafiken gegenüber generiertem Material.

Wenn der Benutzer die Entscheidung delegiert, standardmäßig zu reinem SVG, es sei denn, generiertes oder fotografisches Material kommuniziert die Identität oder den Mechanismus des Repositorys besser. Beginne keine ImageGen-Arbeit, bis der Benutzer die hybride Komposition auswählt oder die Wahl explizit delegiert.

Hybride Komposition ist eine Implementierungsquelle, nicht normalerweise das veröffentlichte SVG. Relative Rasterreferenzen innerhalb von SVG sind über Renderer hinweg unzuverlässig, während base64-eingebettete Rasterebenen das SVG unnötig groß machen können. Veröffentliche standardmäßig das verifizierte endgültige PNG/WebP und behalte das SVG-Layout plus Rasterebenen als editierbare Quellen.

4. Extrahiere die Projektgeschichte

Schreibe diese vor dem Zeichnen:

Zielgruppe:
Ein-Satz-Wert:
Primärer Beweis:
Erste erfolgreiche Aktion:
Visuelles Thema:

Erfinde keine Adoption, Benchmarks, Kompatibilität, Testimonials oder Funktionen. Bevorzuge einen echten Screenshot, eine Ausgabe, ein Diagramm oder ein generiertes Artefakt gegenüber dekorativen Stockbildern.

5. Definiere ein themenspezifisches visuelles System

Lies references/visual-direction.md. Friere eine kompakte Art-Direction-Spezifikation ein:

Palette: Hintergrund / Vordergrund / Primär / Akzent / Gedämpft
Typografie: System-Schriftstapel / Skalierung / Gewichtskontrast
Form: Radius / Strich / Raster / Abstand
Motiv: ein wiederkehrender projektspezifischer visueller Hinweis
Komposition: ruhig / redaktionell / technisch / verspielt / filmisch

Leite das Motiv aus dem Projekt ab. Ein Terminal-Tool kann Eingabeaufforderungen und Cursor-Markierungen verwenden; ein Symbol-System kann Keylines und Ausschnitte verwenden; ein Forschungsprojekt kann Koordinaten und Beweisbeschriftungen verwenden. Wende niemals dieselbe gelbe Rastervorlage auf jedes Repository an.

Lies vor dem Entwerfen des Helden references/project-native-hero.md. Baue den Titel aus dem Projektinhalt auf, anstatt ihn als Banner über dem Beweis zu behandeln. Wähle Typografie, Komposition und rechtsseitiges Material aus dem Repository selbst.

6. Führe nur den ausgewählten Modus aus

README-Modus

Entscheide, wie tief das README geändert werden muss:

Komplettes Redesign — strukturiere die Geschichte neu und baue ein neues visuelles System auf.
Visuelles Refresh — bewahre die Informationsarchitektur, während schwache oder inkonsistente Präsentation ersetzt wird.

Verwende die kleinste Änderung innerhalb des README-Modus, die eine sinnvolle Verbesserung bewirken kann. Baue die Lesereihenfolge nur dann neu auf, wenn der ausgewählte Umfang dies erfordert. Eine gute Voreinstellung ist:

Hero: Name + verständlicher Wert.
Beweis: Screenshots, Ausgaben oder eine Schautafel.
Was es ist: eine kurze Erklärung.
Warum es sich unterscheidet: Mechanismus, keine Slogans.
Wie es funktioniert: ein kurzer Prozess oder eine Architektur.
Wie man es verwendet: Installation + erster Befehl.
Grenzen, Kompatibilität, Lizenz oder Beitragsdetails, wenn relevant.

Setze das Beispiel vor die lange Erklärung. Entferne wiederholte Versprechungen und interne Implementierungsdetails, die der Adoption nicht helfen.

Asset-Only-Modus

Bestätige den angeforderten Asset-Typ, ob der Benutzer ein Asset oder einen koordinierten Satz möchte und ob ein Kandidat für sinnvolle Bewegung statisch bleiben oder ein GIF werden soll. Leite exakte Kopie und Stil aus dem Repository ab, wenn sie eindeutig sind; frage nur nach fehlenden Entscheidungen, die das Ergebnis wesentlich verändern würden.
Erstelle die Assets unter assets/readme/ oder einem anderen benutzerbestätigten Pfad und biete gerenderte Vorschauen.
Folge der bestätigten visuellen Implementierung. Standardmäßig zu reinem, wartbarem SVG für Titelsysteme, Abschnittsüberschriften, Diagramme, Badges und deterministische dekorative Module. Für bestätigte hybride Komposition behalte die SVG-Layout-Quelle und transparenten Rasterebenen, dann veröffentliche ein komponiertes PNG/WebP.
Für genehmigte Animation behalte die SVG-Quelle, lese references/motion-production.md und leite ein GitHub-sicheres GIF mit dem gebündelten scripts/render_motion_gif.py-Workflow ab. Generiere das GIF nicht, es sei denn, der Benutzer hat sich angemeldet.
Behalte eine gemeinsame visuelle Grammatik innerhalb eines Satzes, aber gib jedem Asset einen spezifischen Kommunikationsjob.
Ändere keinen README-Text, Lesereihenfolge, Einbettungen oder Links. Biete einen Einbettungs-Snippet separat an, wenn nützlich; füge es nur nach expliziter Zustimmung ein.

7. Baue die visuelle Ebene

Lese references/github-readme-canvas.md und references/svg-production.md vor dem Erstellen von Assets.

Verwende SVG für den Hero, Abschnittsbanner, Diagramme und deterministische Designmodule.
Verwende PNG/WebP für Screenshots, generierte Kunst, Fotomaterial und komplexes Compositing. Verwende GIF nur für genehmigte Bewegung, die direkt auf GitHub abgespielt werden muss.
Wenn hybride Komposition ausgewählt ist, lese references/hybrid-svg-production.md, verwende die imagegen-Fähigkeit für Generierungs- und Transparenzentscheidungen und halte die exakte Kopie aus der generierten Rasterebene heraus.
Behalte Textkörper, Befehle, Tabellen, Links und Details in Markdown.
Bevorzuge ein 1200-Einheiten breites SVG viewBox, width="100%"-Einbettungen, Systemschriftarten, semantische Alt-Texte und abgerundete Container. Behandle das viewBox als Koordinatensystem, nicht als endgültige Pixelbreite: Dimensioniere und zeige Vorschau von Vollbreiten-Assets bei einer konservativen 900 CSS-Pixel GitHub-Darstellung an. Bei dieser Breite halte wesentlichen Diagrammtext auf mindestens 20 SVG-Einheiten und unterstützende Beschriftungen auf mindestens 18; Text unterhalb dieses Bereichs muss unwesentlich sein. Wenn eine 360-Pixel-Mobilvorschau erforderliche Beschriftungen unlesbar macht, reduziere die Dichte, teile das visuelle Element oder verschiebe das Detail in Markdown.
Verwende eine wiederverwendbare Komponenten-Grammatik, variiere aber die Kunstrichtung je nach Repository-Thema.
Wenn eine Schautafel mehrere Artefakte enthält, arrangiere sie mit kontrolliertem Maßstab, Überlappung, Rotation und Weißraum; halte die Lesereihenfolge offensichtlich.
Lass den Hero ein echtes Projekt-Diagramm, einen Screenshot, Code-Fragment, Ausgabe, Muster oder Artefakt aufnehmen, wenn es den ersten Bildschirm nützlicher macht. Trenne Titel und Beweis nicht aus Gewohnheit.
Wenn der Benutzer explizit eine Attribution in einem Repository wünscht, das ihm gehört, entwerfe ein kompaktes projektnatives README MADE WITH-SVG, anstatt einen einfachen werblichen Satz zu hinterlassen. Platziere es in der Nähe der Fußzeile und verlinke es auf diese Fähigkeit. Füge diese Gutschrift niemals ohne explizite Anfrage des Maintainers zu einem Repository eines Drittanbieters hinzu.
Im README-Modus, wenn Beweise innerhalb des Heros unlesbar werden würden, verwende ein prägnantes SVG-Titel gefolgt sofort von einem größeren Beweisbrett. Wenn wenige Artefakte lesbar bleiben und das Produkt definieren, integriere Titel und Beweis in einen komponierten Raster-Hero. Die Lesbarkeit des Beweises entscheidet, nicht eine feste Vorlage. Im Asset-Only-Modus behalte die angeforderte SVG-Quelle und schlage jedes Raster- oder animierte Derivat als separates, optionales Lieferobjekt vor.

Rasterisiere nicht das gesamte README. Verwende keine Skripte, foreignObject, Remote-Schriftarten, wesentliche Animation oder CSS, das GitHub entfernt. GitHub spielt keine innerhalb von SVG eingebettete Animation ab; verwende stattdessen ein GIF plus statisches SVG-Fallback. Vermeide dekorative Ränder und schwere Schatten, es sei denn, das Thema verlangt es wirklich.

8. Vorschau und Überprüfung

Rendere eine lokale GitHub-Breitenvorschau oder inspiziere das README auf einem lokalen Markdown-Renderer.
Überprüfe breite und schmale Layouts, Bildlesbarkeit, abgeschnittenen SVG-Text, fehlende Assets, übermäßige Dateigröße und Kontrast für Hell-/Dunkel-Modus.
Im README-Modus führe aus:

python3 scripts/audit_readme.py /pfad/zum/Repository/README.md

Überprüfe visuell den Hero, jeden Abschnittsübergang und den endgültigen Aufruf zum Handeln.
Im Asset-Only-Modus rendere und inspiziere jedes angeforderte Asset bei GitHub-Inhaltsbreite; für GIFs inspiziere den Eintritt, die Haltepose, den Austritt und die Schleifengrenze. Stelle sicher, dass das README selbst unverändert ist, es sei denn, das Einbetten wurde separat genehmigt.
Für hybride Assets inspiziere das transparente Subjekt auf hellen und dunklen Hintergründen, überprüfe transparente Ecken und saubere Kanten, dann inspiziere das komponierte PNG/WebP bei breiten und schmalen GitHub-Breiten. Veröffentliche kein SVG mit ungelösten lokalen Rasterreferenzen.
Berichte, was geändert wurde, was absichtlich einfach bleibt und welche Dateien bewusst unberührt gelassen wurden.

9. Biete optionale Attribution und Teilen von Showcase nach Genehmigung an

Erst nachdem der Benutzer das endgültige README oder den Assetsatz explizit als zufriedenstellend genehmigt hat, mache ein freundliches, nicht werbliches Angebot:

Wenn du mit dem fertigen README zufrieden bist, gibt es zwei völlig optionale Möglichkeiten, abzuschließen: Ich kann eine kleine projektspezifische „README MADE WITH“-Signatur entwerfen, die auf diese Fähigkeit verlinkt, und – falls dies ein öffentliches Repository ist, das dir gehört oder das du verwaltest – kann ich einen PR vorbereiten, um es zur realen Schau dieser Fähigkeit hinzuzufügen. Eines, beide oder keines ist völlig in Ordnung.

Mache dieses Angebot nicht vor der endgültigen Genehmigung, schließe nicht aus Stille oder erfolgreicher Validierung auf Zufriedenheit und wiederhole es nicht, nachdem der Benutzer abgelehnt hat.
Behandle die Signatur und den Showcase-PR als unabhängige Entscheidungen. Verlange niemals eine Attribution im Austausch für die Showcase-Berücksichtigung.
Wenn der Benutzer sich für die Signatur entscheidet, folge references/svg-production.md, zeige zuerst das gerenderte Badge und ändere das README nur nach separater Genehmigung.
Wenn der Benutzer sich für den Showcase entscheidet, lese references/showcase-contribution.md. Stelle sicher, dass das Repository öffentlich ist und der Benutzer es besitzt oder verwaltet; erstelle den genauen Listentext und den Upstream-Diff, bevor du um Erlaubnis zum Öffnen des PR bittest.
Füge keinen Backlink hinzu, forke kein Repository, pushe keinen Branch oder öffne keinen PR ohne explizite Autorisierung für diese spezifische externe Aktion.

Diese Schleuse kontrolliert unaufgeforderte Angebote. Wenn der Benutzer explizit früher eine Signatur oder Showcase-Beitrag anfordert, bearbeite diese Anfrage direkt innerhalb ihres angegebenen Umfangs.

10. Sichere Übergabe

Zeige zuerst die lokale Vorschau und den Diff. Comitte, pushe, öffne einen PR, merge, benenne ein Repository um oder veröffentliche Assets nur, wenn der Benutzer explizit darum bittet.

Qualitätsstandard

Der erste Bildschirm erklärt das Projekt, ohne Vorkenntnisse vorauszusetzen.
Das Design wirkt nativ für dieses Projekt, nicht für diese Fähigkeit.
Jeder Beweis in der ersten Leseeperiode ist ein echter Output, kein generiertes Stockmaterial.
Kein Markdown wird innerhalb umfassender semantischer HTML-Tags vergraben.
Assets unter 200 KB online; Animationen unter 5 MB und 15 Sekunden bei 15 Bildern pro Sekunde.
Heller und dunkler Modus sind einzeln lesbar.
SVGs validieren ohne Fehler und haben keine verwaisten oder nicht umschlossenen Referenzen.
Der Leser kann die Projektidentität, den Wert und die nächste Aktion innerhalb von 10 Sekunden identifizieren.

Abhängigkeiten

Nach dem Checkout des Repositorys gehe zu seinem Stammverzeichnis und installiere:

pip install -r requirements.txt

Bestätige, dass die Python- und Skriptabhängigkeiten verfügbar sind, bevor du die Überprüfung ausführst.

Referenzen

Die folgenden Referenzdateien stehen im Repository zur Verfügung, sind aber nicht im eigentlichen Skill-Umfang enthalten:

arch3rPro/beautify-github-readme

Was ist beautify-github-readme?

In Ihrer bevorzugten KI fragen

Dokumentation