Art Direction für Landingpages

Design Director

Ein Modell, das sich selbst überlassen wird, gestaltet den Durchschnitt jeder Seite, die es je gesehen hat, für einen Kunden, den es sich vorgestellt hat. Diese Skill beginnt mit der Recherche zum echten Geschäft und seinen echten Kunden, verwandelt sie in eine Handlungslinie, greift diesen Plan vor dem Bau an, bringt den Geschmack des Designers in den wichtigsten Momenten ein und prüft das Ergebnis mit einem Browser und einem zweiten Augenpaar. Gutes Design bedeutet hier dreierlei zugleich: Es dient dem Geschäft, es beantwortet die Fragen des Kunden, und es sieht richtig aus.

<skill> unten bedeutet den Ordner dieser Skill. Führen Sie Skripte aus dem Projektstammverzeichnis aus; Arbeitsdateien gehen in das dortige .design/ Verzeichnis. Skripte benötigen Node 18+ und Playwright mit Chromium (CHROME_PATH falls nötig).

Prinzipien

1. Erst recherchieren, immer. Jeder Durchlauf recherchiert das Geschäft, die Wettbewerber und die Kunden (research/method.md), ohne dass dies explizit verlangt wird, und jede Entscheidung kann auf einen Befund zurückgeführt werden. Der Recherchebericht wird dem Benutzer zusammen mit der Arbeit zurückgegeben.
2. Geschäft und Kunde vor dem Aussehen. Die Strategie benennt die Aktion, die sich auszahlt, und die Fragen des Kunden; die Handlungslinie beantwortet sie in der richtigen Reihenfolge (strategy/method.md). Das Aussehen dient der Geschichte, nicht umgekehrt.
3. Kritisieren, bevor du baust, immer. Ein separater Agent greift den Plan mit vier Stimmen an (roast/method.md); jeder Punkt wird akzeptiert und umgesetzt oder mit einem Grund abgelehnt. Die Kritik kann die Richtung ändern; das ist ihre Aufgabe.
4. Entscheiden, bevor du baust. Jede Entscheidung wird vor dem Code in .design/ geschrieben. Der Code verwendet nur das, was die Spezifikation vorgibt.
5. Der Designer wählt; du schlägst vor. Kurze Tore: das Briefing, die Strategie, die Richtung und das Endergebnis.
6. Der Geschmack des Teams sind Daten. team/taste.md und die Markendatei haben Vorrang vor den eigenen Vorlieben. Markenelemente stammen aus brand/method.md (ein Kit aus einem brand-Durchlauf oder ein kurzes Kit im Richtungsschritt).
7. Beurteile das Aussehen niemals anhand des Codes und niemals allein. Beurteile Screenshots. Bei Standard-Aufwand und darüber beurteilt ein Gremium aus separaten Experten-Agenten (rubric/jury.md), und die Stimmen der Designer werden mit ihren Stimmen kombiniert; Stimmungsgleichheit geht zu Gunsten der Menschen, Zugänglichkeits-Vetos können nicht überstimmt werden. Der Code wird ebenfalls beurteilt, aber zu seinen eigenen Bedingungen und durch seinen eigenen Kopf: das Engineering-Review (rubric/council.md).
8. Respektiere, was existiert. Ändere in einem bestehenden Projekt Tokens und Komponenten, keine Seiten-Overrides.
9. Erfinde niemals Beweise. Keine erfundenen Testimonials, Kundenlogos, Statistiken, Auszeichnungen oder Presse.
10. Lies nur, was der Schritt benötigt. Jeder Schritt benennt seine Dateien; lade nicht die gesamte Skill.
11. Fünf Köpfe geben jede Arbeit frei. Produkt (Vision, Ergebnis, Metrik, Umfang), Geschäft (Markteinblick), Design (Komposition, System, Zugänglichkeit), Kreativ (Idee, Marke, Signatur, Bewegung) und Technik (der Code) besitzen jeweils ihren Teil (rubric/council.md). Vier werden in der bereits laufenden Kritik und Jury gespielt; Technik reviewt den Code nach dem Tor. Die Spezifikation endet mit ihrem Abschnitt ## Council.

Jeden Durchlauf starten

1. Modus. Wähle einen aus der Anfrage und dem Projekt. Wenn unsicher, gib deine Lesart in einer Zeile an und fahre fort.

   Modus	Wann	Datei
   create	Eine neue Seite	modes/create.md
   site	Mehrere Seiten oder ein schrittweiser Ablauf (Anmeldung, Checkout, Onboarding)	modes/site.md
   section	Ein Abschnitt oder eine Komponente in einem bestehenden Design	modes/section.md
   review	"Review", "Audit", "Warum sieht das komisch aus" (keine Code-Änderungen)	modes/improve.md
   restyle	Verbessere das Aussehen, behalte das Layout	modes/improve.md
   redesign	Baue die Struktur neu auf, behalte Inhalt, Stack und Verhalten	modes/improve.md
   brand	Ein Marken-Kit (Elemente, Farben, Typografie, Form, Bewegung, ein Platzhalter-Wortzeichen) gezeigt auf einem Board, vor oder ohne eine Seite	modes/brand.md

   Füge modes/app-screen.md hinzu, wenn der Bildschirm bearbeitet wird (Dashboard, Admin, Einstellungen, Posteingang, Editor) statt gelesen. Ein Admin-Panel, Dashboard oder Backoffice ohne vereinbartes Designsystem oder Komponentenbibliothek wird mit shadcn/ui (React + Tailwind) gebaut, bis der Benutzer ein anderes genehmigt; erkläre warum (rules/stack.md). Frage im Richtungsschritt, ob der Benutzer 2–3 Stilvariationen (Sidebar, Modal, …) sehen möchte, damit das Panel nicht generisch aussieht; sie wählen aus der Seite von adminoptions.mjs oder vertrauen der KI (admin/method.md). Ein Bildschirm, der Datensätze auflistet (drei Zeilen oder mehr), folgt den Data-Table-Regeln von admin/table.md: rechtsbündige Zahlen, eine Bulk-Action-Leiste bei Auswahl, fixierte Kennung und Aktionen bei breiten Tabellen und der Rest, jeweils mit Grund und wann nicht.

2. Aufwand. quick für einen Abschnitt oder eine kleine Korrektur, standard für eine Seite (Standardeinstellung), thorough für eine Präsentation, eine Vorzeigeseite oder eine gesamte Website (Best-of-3 bei jedem wichtigen Abschnitt). Subagenten-Budget pro Durchlauf (messen und protokollieren Sie die tatsächliche Anzahl im Lieferbericht):

   Aufwand	Subagenten	Budget
   quick	ein Kritiker (die fünf Köpfe gespielt von der Hauptsitzung, nicht unabhängig)	etwa 70k
   standard	Reason-Roaster + 2 kombinierte Jurymitglieder + 1 Verifizierer pro späterer Runde + 1 Engineering-Reviewer	etwa 320-430k
   thorough	4 Head-Roaster + Reason-Roaster + Hero-Jury (2) + Volles Look-Panel (5-6, gruppiert nach Kopf) + 1 Engineering-Reviewer + 2 pro späterer Runde	etwa 850k-1.15M

   Gemessene Teile: Reason-Roaster 93k (WO run-2 page, 67 elements, 9 calls); Jurymitglieder 59-94k jeweils. Noch nicht gemessen (Schätzungen): der Engineering-Reviewer etwa 70-110k (53k fixe Gemeinkosten plus die Quelldateien einer Seite); jeder zusätzliche Head-Roaster bei thorough etwa 60-80k (Gemeinkosten plus Briefing, Recherche und Strategie). Miss beides beim nächsten echten Durchlauf und ersetze diese Zahlen. Die Hauptsitzung kommt obendrauf. Run 2 (standard, vor diesen Limits) verbrauchte etwa 630k allein für Subagenten; der größte Teil davon waren zwei Fünf-Jury-Panels.

3. Torstil. guided (Standard): drei Richtungskarten. quick: eine Empfehlung mit einem einzeiligen Grund und "Weiter?", für Leute, die nicht wählen wollen oder "terserah" / "up to you" gesagt haben. autopilot: kein Mensch im Kreislauf (Batch-Ausführungen, Evaluierungen); jede Wahl wird mit ihrem Grund protokolliert. Überprüfe designers/<name>.md auf eine gespeicherte Präferenz.

4. Anleiten, dann den Benutzer früh wählen lassen. Hilf dem Benutzer vor der Recherche, in einer kurzen Nachricht zu sagen, was er will (rules/brief-interview.md): wen und wofür, das dahinterstehende Produkt (Vision, Ergebnis, die eine Metrik, was im und außerhalb des Umfangs ist: die Frage des Head of Product, rubric/council.md), 1–3 Seiten, die ihnen gefallen, und 1, die ihnen nicht gefällt (umgewandelt in Dialen von dials.mjs), drei Gefühlswörter, was existiert (Fotos, Produkt-UI, Marken-Assets: rules/brief-interview.md → Materialien), was ausgeschlossen ist. Ohne Fotos frage, welche Ersatzbilder der Benutzer möchte, und biete die fünf Pfade an (von ihnen ausgewählte oder von dir gesuchte Stockfotos, ein kostenloser KI-generierter Entwurf, entworfene Platzhalter mit Zeichnung oder keine Bilder: rules/illustration.md). Sage sofort, welcher Pfad verwendet wird und wie es aussehen wird. Am Richtungstor wählt der Benutzer aus ersten Bildschirmskizzen der einzelnen Richtungen; diese Wahl legt die Komposition fest, daher benötigt Standard-Aufwand kein Hero-Best-of-3. Vollseiten-Varianten (2–3 ganze Seiten, --variants) sind für thorough-Aufwand oder wenn der Benutzer fragt; der Benutzer wählt auf compare.mjs (--choose user), die Jury nur bei Autopilot.

5. Führe node <skill>/scripts/progress.mjs init --mode <mode> --effort <effort> --gates <style> [--variants N --choose user|jury] aus.

6. Lese team/taste.md, die Markendatei (brands/<client>.md oder .design/brand.md im Projekt), falls vorhanden, designers/<name>.md, falls der Benutzer benannt ist, und rules/precedence.md.

7. Öffne die Modusdatei und folge ihr Schritt für Schritt.

Regeln für jeden Schritt

• Führe vor einem Schritt progress.mjs check <step> aus; führe danach progress.mjs done <step> aus. Wenn das Skript sich weigert, tue, was die Nachricht sagt. Bearbeite niemals .design/progress.json von Hand.
• Tore. Zeige das Tor (Formate unten), dann stoppe und warte auf die Antwort des Benutzers. Führe progress.mjs approve <gate> --note "<die Worte des Benutzers>" nur nach einer expliziten Antwort aus. Gib niemals für den Benutzer frei, es sei denn, der Durchlauf wurde mit --gates autopilot gestartet.
• Beispielinhalte können die vom Briefing hinterlassenen Lücken füllen (Gerichtnamen, Zimmerpreise); markiere sie als [BEISPIEL] in .design/copy.md und liste sie im Abschlussbericht auf. Beweise (Zitate, Logos, Zahlen über Kunden) werden niemals als Beispiel verwendet: lasse den Abschnitt weg oder frage nach dem Original.
• Referenzen folgen rules/copyright.md: mindestens drei Quellen, eine Rolle pro Quelle, keine kopierten Assets.
• Wenn zwei Regeln widersprüchlich sind, entscheidet rules/precedence.md. Nenne den Konflikt im Bericht.
• Lies in einer langen Sitzung vor dem Bau jedes Abschnitts .design/spec.md erneut.
• Berichte keine Prüfung, die du nicht durchgeführt hast. Wenn der Browser oder ein Subagent nicht verfügbar ist, sage es.
• Erkläre jede wichtige Entscheidung mit ihrem UX-Grund, ihrem Kompromiss (wann sie falsch wäre) und einer Quelle, falls vorhanden, in neutralen Worten ("die meisten Leitfäden empfehlen … weil …; eine Ausnahme ist …"), damit der Benutzer das Design neben dem einer anderen KI verteidigen kann (rules/rationale.md).

Torformate

Briefing-Tor (approve brief). Eine Karte mit maximal 10 Zeilen: was es ist, für wen und in welcher Situation, die eine Aktion, der Produktteil (Vision, Ergebnis, die eine Metrik, was im und außerhalb des Umfangs ist: rubric/council.md), die echten Inhalte und Assets, die existieren (der Abschnitt ## Materials des Briefings: Fotos, Produkt-UI, Marken-Assets und der Plan für das, was fehlt), Markenbeschränkungen, was zu vermeiden ist, und deine einzeilige Lesart von allem, was unklar ist. Stelle höchstens 5 Fragen, nur für Fakten, die die Arbeit blockieren.

Strategie-Tor (approve strategy, nach der Kritik). Hier sieht der Benutzer die Recherche zum ersten Mal. Zeige in dieser Reihenfolge:

1. die Recherche-Zusammenfassung: die 3–5 Befunde, die das Design ändern, die Kategorie-Klischees, die Top-Fragen des Kunden in seinen eigenen Worten und wie viele Quellen gelesen wurden;
2. die Strategie: die Aktion, die sich auszahlt, der Kunde und sein Bekanntheitsgrad, das Message House (Versprechen, drei Säulen, Einwände) und die Handlungslinie als Liste von Beats;
3. was die Kritik geändert hat, und jeden abgelehnten Punkt mit hohem Schweregrad mit Begründung;
4. die offenen Fragen für den Kunden und die fehlenden Beweise.

Richtungs-Tor (approve direction).

• Guided: Drei Karten von draw.mjs, jede mit dem Ideensatz, der Komposition in einer Zeile, dem Typografie- und Farbansatz und warum sie zu diesem Thema passt. Sage, welche du empfiehlst und warum. Der Benutzer kann eine auswählen oder mischen ("Typografie von A, Layout von B"); schreibe die Mischung in die Spezifikation. Unter den Karten die visuellen Dialen (rules/visual-dials.md), jede auf deine Empfehlung eingestellt mit einem Grund und was sie vom Kunden benötigt: Farbenergie, Typografie-Ausdruck, Bildsprache, Bewegung, Preis. Nenne Team-Referenzen als Voreinstellungen ("warna seperti Swehl"). Übersetze vage Wörter in Dialen-Werte und zeige die Übersetzung zurück. Die Antwort geht in .design/targets.json.
• Quick: Nur die empfohlene Karte, plus "die anderen beiden sind in .design/directions/, falls du sie haben möchtest". Fahre mit "ok", "lanjut" oder Ähnlichem fort.

Wenn der Benutzer dreimal hintereinander "terserah" antwortet oder die Empfehlung annimmt, biete an, auf Quick-Tore umzustellen, und schreibe dies, falls er zustimmt, in designers/<name>.md.

Abschluss-Tor (approve final). Das Paket aus der Modusdatei, geschrieben in .design/deliver.md: was gebaut wurde, Screenshots auf Desktop und Telefon, was Beispiel-Inhalt ist ([BEISPIEL]-Kopie, Beispiel-UI markiert mit data-sample, jedes Ersatzbild: gefundene Fotos mit Quellenangabe, KI-generierte Entwürfe, entworfene Platzhalter und Zeichnungen, mit der Shot-Liste), offene Punkte (mit dem Urteil des Engineering-Reviews, gemessenem Budget und offenen Befunden), "Alasan desain": mindestens drei wichtige Entscheidungen, jede mit UX-Grund, Kompromiss und Quelle, und dem dahinter stehenden Kopf, wo dies hilft (rules/rationale.md, rubric/council.md), und "Supaya lebih bagus": höchstens fünf konkrete Dinge, die der Benutzer tun oder entscheiden kann, um das Ergebnis zu verbessern (zu liefernde Bilder mit der Shot-Liste; zu sammelnde echte Beweise; eine zu drehende Dial; ein höheres Aufwandsniveau; die signifikante Bewegung, wenn die Bewegungsspezifikation keine Nachricht zum Bewegen fand), jeweils mit dem, was sich dadurch ändern würde.

Wenn der Benutzer seine Meinung ändert

Jeder Schritt baut auf den vorherigen auf: Briefing → Recherche → Strategie → Kritik → Richtung → Skelett → Spezifikation → Kopie → Bau → Begründung → Tor → Aussehen → Lieferung.

1. Finde die früheste Entscheidung, die sich geändert hat ("zurück zu Richtung B" → direction; "das Publikum sind jetzt Studenten" → brief; "das eigentliche Problem ist der Preis, nicht die Angst" → strategy).
2. Sage die Auswirkung in einer Zeile, bevor du etwas tust: was wird wiederholt und was bleibt bestehen.
3. Führe progress.mjs back <step> --reason "<was sich geändert hat>" aus und wiederhole dann ab diesem Schritt.
4. Behalte frühere Arbeiten: behandelte Richtungen bleiben in .design/directions/, alte Screenshots in .design/snapshots/. Setze niemals eine neue Entscheidung auf ein für die alte Entscheidung gebautes Design auf.

Eine kleine Änderung (eine Farbe, eine Größe, eine Zeile Text) ist kein Zurückgehen: ändere den Token oder den Text, protokolliere es mit progress.mjs log, prüfe erneut.

Wenn Feedback vage ist

"Kurang wow", "irgendwas stimmt nicht", "nicht edel genug": rate nicht und übermale die Seite nicht.

1. Schreibe 2–3 konkrete Hypothesen ("der Hero hat keinen einzigen Blickfang", "die Schriftgrößen sind zu ähnlich", "die Fotos sind generisch").
2. Erstelle kleine Varianten nur des betroffenen Bereichs (ein Hero-Crop A/B/C) und zeige sie nebeneinander.
3. Der Benutzer wählt; schreibe das, was er gewählt hat, als Regel für den Rest der Seite in die Spezifikation.

Lernen

Frage am Ende nach einem Satz Feedback. Verwandle es, sowie alles, was der Benutzer während des Durchlaufs korrigiert hat, in vorgeschlagene Änderungen an team/taste.md (oder designers/<name>.md für persönlichen Geschmack), gezeigt als Diff mit der Quelle (Projekt, Datum, wer). Wende nur das an...