bitomule/Koubou

Koubou: App Store-Screenshot-Generator

Erstelle professionelle App Store-Screenshots mit HTML/CSS-Vorlagen, über 100 echten Geräterahmen, xcstrings-Lokalisierung und pixelgenauen Apple-Maßen.

Screenshots sind Werbung, keine Dokumentation. Jede Folie verkauft ein Gefühl, ein Ergebnis oder eine Lösung für einen Schmerzpunkt.

Benutzeranweisungen haben immer Vorrang vor Standardeinstellungen in diesem Skill.

Die kreative Richtung ist standardmäßig offen. Verwenden Sie die Regeln in diesem Skill, um Wirkung, Lesbarkeit und canvas-bewusste Skalierung durchzusetzen, nicht, um jeden Satz gleich aussehen zu lassen.

Regelhierarchie

Behandeln Sie die Anleitungen in diesem Skill in dieser Reihenfolge:

1. Harte Einschränkungen – Lesbarkeit, Skalierung, Thumbnail-Klarheit, wahrheitsgemäßes Produktmarketing und echtes Canvas-Bewusstsein
2. Starke Vorgaben – Abwechslung, Asymmetrie, Überlappung, Rhythmus und Vermeidung generischer Layouts
3. Geschmackspräferenzen – Anti-Schrott-Heuristiken und stilistische Vorgaben, die gebrochen werden können, wenn eine stärkere Idee die Arbeit eindeutig verbessert

Wenn das Brechen einer Vorgabe ein besseres Screenshot-Set ergibt, brechen Sie sie bewusst und erklären Sie sich selbst den Kompromiss, bevor Sie generieren.

Referenzdateien (nach Bedarf lesen, nicht vorab):

• setup.md – Installation und HTML-Laufzeiteinrichtung
• design-guide.md – Designprinzipien, Copywriting-Regeln, CSS-Regeln, HTML-Vorlagenbeispiele
• style-intake.md – Wie man die echte visuelle Sprache der App untersucht, bevor man Fragen stellt
• style-interview.md – Kurze, signalstarke Stilfragen und Gesprächsmuster
• yaml-reference.md – YAML-Konfigurationsformat, Lokalisierung, Assets, Geräte, Größen
• capabilities-reference.md – Vollständige Koubou-Funktionen (Inhaltsmodus, Highlights, Zoom, Verläufe)

Phase 1: Einrichtung (still, automatisch)

Prüfen Sie zuerst, ob kou verfügbar ist. Installieren Sie nicht neu und berühren Sie keine Python-Pakete, wenn kou bereits funktioniert.

Bevorzugte Reihenfolge:

kou --version 2>/dev/null

Wenn kou --version erfolgreich ist:

• behandeln Sie Koubou als installiert
• führen Sie nicht pip, pip3 oder playwright install aus
• versuchen Sie nicht, die Umgebung des Benutzers proaktiv zu „aktualisieren” oder zu „reparieren”
• führen Sie vor der Generierung immer kou setup-html aus, da dieser Skill nur HTML verwendet und der Befehl sicher wiederholt werden kann

Wenn kou --version fehlschlägt, lesen Sie setup.md und folgen Sie dem am wenigsten invasiven Pfad für die Umgebung.

Für HTML-Rendering-Unterstützung:

• verwenden Sie immer kou setup-html
• überspringen Sie es nicht, nur weil HTML in einem vorherigen Durchlauf funktioniert hat
• führen Sie playwright install chromium nicht direkt aus

Informieren Sie den Benutzer nur, wenn die Einrichtung fehlschlägt. Verändern Sie niemals eine funktionierende Installation.

Phase 2: Die App lesen, dann fragen

Beginnen Sie nicht mit einem generischen Stilfragebogen. Untersuchen Sie zuerst die echte visuelle Sprache der App, fragen Sie dann nur, was noch fehlt oder mehrdeutig ist.

Lesen Sie style-intake.md, bevor Sie Stilfragen stellen. Folgen Sie dieser Reihenfolge.

2.1 Stilentdeckung (obligatorisch vor Stilfragen)

Durchsuchen Sie zuerst lokale Projektquellen. Suchen Sie automatisch, bevor Sie den Benutzer nach visueller Richtung fragen.

Priorisieren Sie diese Quellen:

1. Assets.xcassets, App-Symbole, Illustrationen, Logos, Farb-Assets
2. Vorhandene Screenshots und Marketing-Ordner:
   • .maestro/
   • screenshots/
   • AppStore/
   • fastlane/screenshots/
   • marketing/
3. Produktdokumentation und Positionierung:
   • README*
   • CLAUDE.md
   • Launch-Pläne, Landing-Page-Texte, Dok-Ordner
4. Design-Tokens und UI-Code:
   • CSS-Variablen
   • SwiftUI-Farben, Verläufe, Materialien, Typografie-Entscheidungen
   • Web-Theme-Dateien und gemeinsame Designkonstanten
5. Vorherige App Store-Artefakte, falls vorhanden:
   • frühere Vorlagen
   • alte Screenshot-Kampagnen
   • lokalisierte Marketing-Assets

Extrahieren und fassen Sie mindestens diese Signale zusammen:

• dominante Farben und Akzentfarben
• Gesamtkontrast: dunkel, hell, gemischt, gedämpft, lebendig
• UI-Dichte: luftig, ausgewogen, dicht
• Formensprache: scharf, weich, abgerundet, kartenlastig, flach
• Ikonografie und Illustrationsstil
• Typografie-Richtung, falls sichtbar
• Copy-Ton: ruhig, technisch, verspielt, hochwertig, warm, dringend
• ob sich die App ruhig, technisch, warm, energiegeladen, poliert, verspielt usw. anfühlt

Wenn der App-Stil klar ist:

• fassen Sie die erkannten Signale für den Benutzer in einfacher Sprache zusammen
• bestätigen Sie, dass Sie von dieser Richtung aus aufbauen, anstatt mit einer generischen Vorlagensprache neu zu starten

Wenn die Signale schwach, fehlend oder widersprüchlich sind:

• sagen Sie, was Sie gefunden haben
• stellen Sie gezielte Folgefragen zur Unklarheit, anstatt einen breiten Designfragebogen zu stellen

2.2 Intent-Interview (kurz, signalstark)

Lesen Sie style-interview.md und fragen Sie nur das Nötigste. Bleiben Sie gesprächig. Geben Sie nicht alle Fragen auf einmal aus.

Erforderliche Stilfragen, wenn noch nötig:

1. Welches Gefühl soll die Kampagne vermitteln: hochwertig, verspielt, redaktionell, utilitaristisch, technisch, warm usw.?
2. Gibt es App Store-Referenzen, Marken oder Screenshot-Sets, die die Richtung beeinflussen sollten?
3. Was ist visuell verboten: laute Verläufe, Glasphorm, nur dunkel, Kartenraster, übermäßig verspieltes Styling usw.?
4. Welches visuelle Merkmal der App selbst muss in den Screenshots noch erkennbar sein?

Optionale Fragen nur, wenn noch ungelöst:

5. Bevorzugte Typografie-Richtung oder Schriftart-Persönlichkeit
6. Helle, dunkle oder gemischte Präferenz
7. Dichtepräferenz: mehr Luft vs. mehr Informationen
8. Ob sich das Set eng konsistent oder sichtbar variiert über die Folien anfühlen soll

2.3 Produktinformationen (weiterhin erforderlich)

Nachdem die Stilentdeckung begonnen hat, sammeln Sie die verbleibenden Produktionseingaben natürlich:

1. App: Name, was sie tut (1 Satz), Hauptnutzenversprechen
2. Screenshots: Wo sind die App-Aufnahmen? Suchen Sie automatisch zuerst:
   • Wenn gefunden, zeigen Sie, was Sie gefunden haben, und bestätigen Sie
   • Wenn nicht gefunden, fragen Sie, wie der Benutzer sie generiert
   • Bevorzugen Sie saubere Simulator-Aufnahmen, die die App-Oberfläche klar zeigen. Wenn der Benutzer wählen kann, bevorzugen Sie aktuelle 6,1-Zoll iPhone-Aufnahmen als Quellmaterial
3. Hervorzuhebende Funktionen: Priorisierte Liste von Funktionen/Vorteilen (empfehlen Sie 3-5). Jede Folie = 1 Funktion
4. Hero-Assets: App-Symbol oder anderes Marken-Asset. Suchen Sie automatisch, bevor Sie fragen
5. Folienanzahl: Wie viele Screenshots (empfehlen Sie 3-5 zum Start, Apple erlaubt bis zu 10)

Optional nur, wenn relevant:

6. Gerät: Standard ist iPhone 16 Pro - Black Titanium - Portrait. Fragen Sie nur, wenn iPad/Mac/anderes Sinn ergibt
7. Lokalisierung: Nur, wenn das Projekt bereits xcstrings oder mehrsprachige Unterstützung hat
8. Zusätzliche Assets: Schwebende UI-Elemente, Abzeichen, unterstützende Illustrationen
9. Zusätzliche Einschränkungen: Erforderliche Behauptungen, verbotene Stile oder Marketing-Einschränkungen

2.4 Stilentscheidung (obligatorisch vor HTML)

Bevor Sie Vorlagen entwerfen, legen Sie diese sechs Punkte explizit fest und sperren Sie sie intern:

• erkannte Markensignale
• gewählter Kampagnenstil
• Copy-Stimme
• Hintergrundsystem
• Gerätekompositionsrhythmus
• Variationsplan über Folien hinweg

Jeder Punkt muss entweder durch:

• App-Beweise aus der Stilentdeckung, oder
• direktes Benutzerfeedback aus dem Interview gerechtfertigt sein

Wenn Sie keinen davon rechtfertigen können, stellen Sie weiter gezielte Fragen, bevor Sie designen.

Abgeleitet (fragen Sie NICHT, es sei denn, Sie sind blockiert)

• Hintergrundverläufe oder -texturen aus Markenfarben und UI-Stimmung
• Layoutverteilung (Hero → Feature-oben → Feature-unten → abwechselnd)
• Überschriften-Copy aus Funktionen und Nutzenversprechen
• Sekundärpalette aus der tatsächlichen Palette der App
• Canvas-Klasse aus project.device + project.output_size über kou inspect-frame
• Ob der App-Name überhaupt erscheinen soll. Standard: Lassen Sie ihn weg, es sei denn, er bietet echten Markenwert in lesbarer Größe
• Ob das App-Symbol erscheinen soll. Standard: Verwenden Sie es sparsam auf Hero- oder Abschlussfolien, nicht als winzigen dekorativen Marker

Prinzip: Wenn Kontext lokal verfügbar ist, verwenden Sie ihn vor dem Fragen. Stilfragen kommen nach der Inspektion, nicht davor.

Phase 3: Generieren

Lesen Sie design-guide.md vor dem Generieren von Vorlagen. Lesen Sie yaml-reference.md vor dem Schreiben der Konfiguration.

1. Erstellen Sie ein Arbeitsverzeichnis (z. B. AppStore/ oder wo immer es für das Projekt Sinn ergibt)

2. Führen Sie kou setup-html aus

3. Lesen Sie project.device und project.output_size aus dem YAML

4. Führen Sie kou inspect-frame "<device>" --output-size <size> --output json aus und verwenden Sie diese Geometrie vor dem Schreiben von CSS

5. Entwerfen Sie den narrativen Bogen und 2-3 Überschriften/Untertitel-Optionen pro Folie vor dem Layout. Wählen Sie zuerst die stärkste aus. Copy-Qualität kommt vor CSS

6. Übersetzen Sie die Stilentscheidung in ein Kampagnen-Briefing:

   • wie sich das Set anfühlen soll
   • welche Motive erlaubt sind
   • welche Motive verboten sind
   • wie viel Variation die ersten 5 Folien zeigen sollen

7. Erstellen Sie templates/ mit HTML-Vorlagen – mindestens 3 verschiedene Layouts, und die ersten 3 Folien dürfen nicht denselben Kompositionsarchetyp wiederholen

8. Fügen Sie in jeder HTML-Vorlage data-kou-id und data-kou-role zu diesen Elementen hinzu, bevor Sie CSS schreiben:

   • Hauptüberschrift: data-kou-id="headline" data-kou-role="headline"
   • Unterstützender Text: data-kou-id="subtitle" data-kou-role="supporting"
   • Primäres Gerätebild: data-kou-id="device" data-kou-role="device"
   • Funktionstitel/-untertitel (Abschluss-/Funktionsfolien): data-kou-id="feature-N-title" data-kou-role="feature-title", data-kou-id="feature-N-sub" data-kou-role="feature-sub"

   Ohne diese bleibt das Layout-Seitenwagen-elements-Array leer und die Post-Render-QA ist blind. Siehe design-guide.md-Vorlagenbeispiele für korrekte Annotationsmuster.

9. Erstellen Sie config.yaml mit der Koubou-Konfiguration (lesen Sie yaml-reference.md für das Format)

10. Verwenden Sie CSS, das sich an die Canvas und die Kopylänge anpasst: verwenden Sie vw oder clamp() bewusst, bevorzugen Sie CSS Grid, Überlappung und absolut positionierte Schichten, und überprüfen Sie die endgültige berechnete Textskalierung auf der echten Canvas

11. Bevor Sie HTML schreiben: Planen Sie Text-/Gerätezonen für jede Folie (welcher Bereich wie viel Prozent der Canvas besitzt). Beginnen Sie nicht mit CSS, bis die Zonen klar sind

12. Führen Sie aus: kou generate config.yaml --output json

13. Für jedes generierte HTML-Screenshot lesen Sie layout_path aus dem JSON-Ergebnis und inspizieren Sie den Seitenwagen, bevor Sie entscheiden, dass das Layout akzeptabel ist

14. Post-Render-QA (obligatorisch – nicht überspringen):

    • Überprüfen Sie jede generierte Folie visuell
    • Öffnen Sie jede *.layout.json-Seitenwagendatei, auf die von layout_path verwiesen wird
    • Überprüfen Sie gegen die Ablehnungs-Checkliste in design-guide.md
    • Überprüfen Sie, dass das gerenderte Set immer noch den App-Stil widerspiegelt, den Sie entdeckt haben, anstatt generischer App Store-Standards
    • Verwenden Sie Layout-JSON nur für objektive Geometrie: Positionen, belegter Raum, Proportionen und mathematische Überlappungen
    • Wenn elements für eine HTML-Folie, die gemessen werden soll, leer ist, behandeln Sie dies als fehlende oder defekte Annotation und reparieren Sie die Vorlage
    • Überprüfen Sie: keine Emoji-Symbole, keine identischen Kartenraster, keine dezentrierten Geräte, kein Text unterhalb der Mindestschwellung, keine unbeabsichtigte Gerätebeschneidung (Geräteoberkante/-notch muss auf Hero-Folien sichtbar sein; Bildschirminhalt muss lesbar sein)
    • Wenden Sie den Logo-Swap-Test an: Würden diese Folien für einen Mitbewerber funktionieren?
    • Wenn eine Folie durchfällt, reparieren und neu generieren, bevor Sie sie dem Benutzer zeigen

15. Öffnen Sie das Ausgabeverzeichnis: open <output_dir>

16. Fragen Sie, ob der Benutzer Anpassungen wünscht – iterieren Sie auf bestimmten Folien, ohne alles neu zu generieren

Iterationsregeln

• Wenn der Benutzer eine bestimmte Folie ändern möchte, ändern Sie nur diese Vorlage + den Konfigurationseintrag
• Wenn der Benutzer eine globale Stiländerung wünscht (Farben, Schriftarten, Stimmung, Dichte, Fettigkeit), aktualisieren Sie alle Vorlagen
• Führen Sie nach Änderungen kou generate config.yaml --output json erneut aus, damit die neuen layout_path-Werte und Seitenwagen synchron bleiben
• Verwenden Sie kou live config.yaml, wenn der Benutzer eine Echtzeitvorschau während der Bearbeitung wünscht
• Wenn sich eine Folie klein anfühlt, erhöhen Sie zuerst die Skalierung oder wechseln Sie das Layout. Verstecken Sie das Problem nicht mit zusätzlichen Verläufen oder Labels
• Wenn der Copy zu winzigen Text zwingt, schreiben Sie den Copy um oder wählen Sie ein passenderes Layout; akzeptieren Sie niemals eine zögerliche Folie, weil „der Text passen musste”
• Halten Sie die Abwechslung hoch: Das Ziel ist Kampagnenkonsistenz, nicht Layoutwiederholung
• Hören Sie nicht nach dem ersten erfolgreichen Render auf, wenn die Ausgabe immer noch gegen die Designregeln oder die Ablehnungs-Checkliste verstößt
• Wenn der Benutzer eine Stimmungsänderung wünscht, interpretieren Sie das gesamte Set innerhalb der Qualitätsgrenzen neu, anstatt die vorherigen Vorgaben zu verteidigen
• Wenn Screenshot und Layout-JSON nicht übereinstimmen, vertrauen Sie dem gerenderten Screenshot für den Geschmack und untersuchen Sie die Annotation oder das Rendertiming, anstatt eine Layoutentscheidung aus veralteter Geometrie zu erzwingen

Harte Regeln

Harte Einschränkungen

• Verwenden Sie niemals Emojis als Symbole – verwenden Sie CSS-Formen (Akzentbalken, Punkte) oder Nur-Text
• Verwenden Sie niemals verbotene Copy-Phrasen – „revolutionär”, „nahtlos”, „entsperren”, „bahnbrechend” usw.
• Wenden Sie den Logo-Swap-Test an – wenn der Name eines Mitbewerbers passen würde, ist das Set zu generisch
• Jede HTML-Vorlage muss data-kou-id-Annotationen haben – mindestens: headline, subtitle und device. Wenn elements im Layout-Seitenwagen nach der Generierung leer ist, fehlen Annotationen – reparieren Sie die Vorlage, bevor die QA besteht. Präsentieren Sie dem Benutzer keine nicht annotierten Folien.

Skalierung

• Auf hohen iPhone-Porträts (iPhone6_9, iPhone6_7) müssen Hero-Überschriften >=10vw, Seitenlayout-Überschriften >=10vw, Untertitel >=4.5vw sein
• Verwenden Sie vw oder clamp() nur, wenn die berechnete Größe das Minimum auf der Ziel-Canvas immer noch überschreitet
• Auf Kontrast- oder Abschlussfolien muss der Inhaltscluster 60 %+ der Canvas-Höhe einnehmen

Starke Vorgaben

• Verwenden Sie nicht dieselbe aufrechte, zentrierte Telefonkomposition auf aufeinanderfolgenden Folien
• Lassen Sie keine großen leeren Bänder (>15 % Canvas-Höhe) zwischen Überschrift und Gerät
• Vermeiden Sie die Kombination von rotate() + translate() auf zentrierten Geräten, es sei denn, das visuelle Zentrum fühlt sich nach dem Render immer noch beabsichtigt an
• Verwenden Sie keine einfache zentrierte Flex-Spalte, wenn die Folie Überlappung, randbrechende Beschnitte oder eine geschichtete Komposition benötigt
• Planen Sie Text-/Gerätezonen vor dem Schreiben von CSS (siehe design-guide.md Gerät-Text-Zonenplanung)
• Wenn Sie Kartenraster verwenden, staffeln, betonen oder vereinfachen Sie sie, es sei denn, ein strenges Raster dient tatsächlich dem Konzept

Inhalt

• Fügen Sie standardmäßig keine winzigen Top-Labels, Kategorie-Labels oder App-Name-Kopfzeilen hinzu
• Rendern Sie den App-Namen nicht als kleinen dekorativen Text, es sei denn, er ist klar lesbar

… [für die Übersetzung gekürzt]