OG-Bild

Was macht OG-Bild?

Jede Datei, die diese Fähigkeit verwendet, befindet sich in einem eigenen Ordner neben dieser SKILL.md, und Pfade hier sind relativ zu diesem Ordner. Sie benötigt nichts von anderen Fähigkeiten oder Ordnern, suche also nicht danach. Sofern der Benutzer keinen anderen Ort angibt, speichere alles, was sie erstellt, in out/og-image/ unter dem aktuellen Projekt.

Eine Share Card verkauft das Produkt in der halben Sekunde, in der jemand an einem Link vorbeiscrollt. Die Formel: Markenzeichen, ein kurzer Titel und das echte Produkt darunter, beschnitten durch die untere Kante. Nichts weiter.

Referenzstil (siehe references/):

• control-panel.png – Markenzeichen oben zentriert, ein sehr großer einzeiliger Titel, dann das App-Fenster (Sidebar, Header, Liste), beginnend bei etwa einem Drittel der Höhe, unten auslaufend, mit einem schwebenden Detail-Panel auf der rechten Seite.
• pulse.png – gleicher Aufbau aus Pulse's echtem Layout: Sidebar mit Projekt-Icons, Such-Header, Projekt-Seite mit Tabs, Feed-Zeilen und der Aktivitätsleiste.

Regeln

1. Echtes Produkt, niemals erfunden. Zeige die App so, wie sie aktuell ausgeliefert wird. Verwende nur Bildschirme, Tabs, Labels, Status und Funktionen, die im Code existieren. Keine erfundenen Metriken, Diagramme oder Funktionen, selbst wenn der Landingpage-Text davon spricht. Wenn eine Marketing-Demo auf der Website etwas zeigt, das die App nicht hat, kopiere diese Demo nicht.
2. Nachrichten stammen von der aktuellen Website. Übernimm den Pitch und den Beispielinhalt von der Live-Homepage (ihrem Hero, ihren Demo-Daten), sofern der Benutzer keinen Titel angibt. Wenn der Benutzer einen Titel angibt, verwende ihn wortwörtlich (ein abschließender Punkt ist für eine aussagekräftige Überschrift in Ordnung; frage bei Unsicherheit nach).
3. Sieht lebendig aus, nicht generiert. Demo-Daten müssen sich wie die Woche eines echten Teams lesen:
   • Realistisch wirkende Personen mit den eigenen Avatar-Fotos des Projekts, falls es welche ausliefert (z.B. public/landing/people); verwende die Namen, die der Benutzer wünscht.
   • Entitäten erhalten Icons oder Bilder, keine bloßen Buchstaben (z.B. Projekt-Avatare als farbige Icon-Kacheln, getönt mit den Akzentfarben des Produktthemas).
   • Aktivitätsgitter, Diagramme und Zählungen folgen echten Rhythmen: viel los Mo–Fr mit Abwechslung, größtenteils leere Wochenenden mit dem einen oder anderen leichten Tag, die aktuelle Woche bis heute abgeschnitten, Monatsbezeichnungen, wo Monate tatsächlich beginnen. Niemals ein einheitliches oder offensichtlich sich wiederholendes Muster.
   • Relative Zeiten, IDs, Branches und Status in den Formaten, die die App verwendet.
4. Text führt. Der Titel ist das größte, dunkelste Element auf der Karte und bereits in Thumbnail-Größe lesbar (~60–72px auf einer 1200px Karte, eine Zeile, enge Laufweite, die Anzeigeschrift des Produkts). Das Produkt sitzt darunter und überlappt es niemals.
5. Nur der eigene Stil des Produkts. Hintergrund, Schriftarten, Farben, Radien, Schatten aus den Tokens des Projekts. Ein sehr sanfter, akzentuierter Schimmer hinter dem Titel ist in Ordnung; keine neuen Paletten, Farbverläufe oder Stock-Bilder.

Schritte

1. Entdecken

• Lies die Homepage/Landing-Komponente und die README für den Pitch, den Produktnamen und Beispielinhalte.
• Finde die echte App-Hülle (Layout, Sidebar, Header) und den primären Bildschirm (Routes + Komponenten). Notiere genaue Klassennamen, Textgrößen, Tab-Labels, Status-Chip-Töne, leere/Ladezustände, die du vermeiden musst.
• Finde Tokens (globales CSS / Theme), Schriftarten, Icon-Bibliothek, Markenkomponente, Avatar-Assets.
• Prüfe, was bereits vorhanden ist: eine existierende OG-Route/ein existierendes OG-Bild, og:image-Meta im Root oder Seiten-Head, WEB_URL/Site-URL-Konfiguration.

2. Erstelle eine Render-Route

Erstelle die Karte als echte Seite im Stack des Projekts, damit sie die tatsächlichen Schriftarten, Tokens und Komponenten verwendet (kein handgezeichnetes SVG, kein Screenshot der Produktion mit privaten Daten):

• Eine Route, z.B. /og/<page> (TanStack routes/og.<page>.tsx, Next app/og/<page>/page.tsx, etc.), noindex, keine App-Chrome.
• Eine Komponente (z.B. og-image.tsx neben der Landing, zu der sie gehört), die einen festen 1200×630 Rahmen mit data-og-frame auf dem Root und overflow-hidden rendert.
• Layout:
  • Markenzeichen zentriert, ~48px vom oberen Rand.
  • Titel zentriert darunter.
  • App-Fenster beginnend ~200–240px vom oberen Rand, ~60px vom linken Rand, breiter als der verbleibende Platz, sodass es rechts oder unten ausläuft. Abgerundete obere Ecken, hauchdünner Rand, der Schatten des Produkts.
• Innerhalb des Fensters den echten Bildschirm als statische Replik nachbauen: Hülle (Sidebar + Header) plus den primären Bildschirm. Markup und Klassen aus den echten Komponenten kopieren; die Quelldateien in einem Header-Kommentar angeben. Nur statische Props, keine Abfragen, keine Timer.
• Um ein Layout in voller Größe in die Karte einzupassen, das Fenster in seiner natürlichen Breite (z.B. 1200px) anlegen und mit zoom (0.85–0.95) verkleinern. zoom skaliert auch top/left auf demselben Element, daher die beabsichtigten Offsets durch den Zoom-Faktor teilen.
• Vorhandene Demo-Primitive von der Landing (Avatare, Source-Badges, Heat-Farben) wiederverwenden, wenn sie mit der echten App übereinstimmen.

3. Aufnehmen

Starte den Dev-Server (oder verwende einen vorhandenen), dann:

node <dieser Skill-Ordner>/scripts/capture.mjs \
  --url http://localhost:<port>/og/<page> \
  --out out/og-image/og-<page>.png

Es öffnet einen 1200×630 Viewport bei 2x (→ 2400×1260), bevorzugt reduced motion, blendet Dev-Overlays aus (TanStack/Next/Vite/Astro Devtools, Toaster), wartet auf Schriftarten und macht einen Screenshot von [data-og-frame]. Verwende --hide für andere Overlays und --wait, wenn Bilder langsam laden.

Probleme:

• Port-Kollisionen: überprüfe, ob der Port tatsächlich diese App bedient (lsof -iTCP:<port> -sTCP:LISTEN, und sieh dir den Seitentitel an). Eine andere lokale App auf [::1]:<port> kann localhost stillschweigend beantworten. Wähle bei Bedarf einen freien Port.
• Ein Hintergrund-Dev-Server, der von einer Agenten-Sitzung gestartet wurde, stirbt mit der Sitzung. Trenne ihn (nohup … & disown), wenn der Benutzer die Vorschau behalten möchte.
• Verdecke Overlays nicht mit breiten :has() / body > div-Regeln; sie können den App-Root verdecken und die Aufnahme zum Zeitüberschreiten bringen.

4. Prüfen

Öffne das PNG und überprüfe es wie ein Designer, in voller Größe und stelle es dir bei 500px Breite vor:

• Titel in einer Zeile, nichts überlappt ihn, großzügiger Abstand über dem Fenster.
• Keine Devtools-Badges, Cursor, Toasts, Lade-Skelette oder halb abgespielte Animationen.
• Nichts ungeschickt abgeschnitten (ein Label mitten im Wort an einer Seitenkante, ein Chip halb versteckt). Unten/rechts auslaufend ist beabsichtigt; linke und obere Kanten des Fensters sind vollständig sichtbar.
• Daten sehen echt aus (Regel 3). Iteriere, bis dies der Fall ist, kopiere dann das endgültige PNG in public/.

5. Meta-Tags einbinden

Auf der Seite, zu der das Bild gehört (oder im Root für eine seitenweite Karte):

• og:type, og:title, og:description
• og:image — absolute URL, aufgebaut aus der Site-URL-Konfiguration (z.B. ${WEB_URL}/og-<page>.png)
• og:image:width 2400, og:image:height 1260, og:image:alt mit Beschreibung des Titels + was der Produktscreenshot zeigt
• twitter:card = summary_large_image, twitter:title, twitter:description, twitter:image

Überprüfe, ob die Tags im ausgelieferten HTML erscheinen (curl -s <page> | grep og:image) und die PNG-URL 200 image/png zurückgibt.

Ausgabe

Teile dem Benutzer mit:

• wo das PNG und die Render-Route/Komponente liegen
• wie neu generiert wird: der obige Capture-Befehl
• was das Bild zeigt und welche echten Bildschirme/Komponenten es repliziert
• was nicht aus echten Daten stammt (Beispielnamen, Projekte), und dass die Site-URL-Umgebungsvariable auf die Produktionsdomain zeigen muss, damit Crawler das Bild auflösen können