muhammad-ahmed-ghani/ai-website-builder

Was macht ai-website-builder?

Eine App ist dann erstklassig, wenn fünf Dinge gleichzeitig zutreffen. Sie beantwortet, was die Person eigentlich wollte. Sie sieht aus wie keine andere und konvertiert trotzdem. Sie sagt nur, was wahr ist. Alles darin funktioniert. Und jemand hat sie in einem echten Browser angesehen, bevor sie für fertig erklärt wurde. Dieses Skill ist die Methode, um alle fünf zu erreichen – in jedem Stack, allein oder mit Helfer-Agenten.

Los geht's: Was werden die Leute DARIN tun?

Bevor du einen Tool-Aufruf tätigst, entscheide, welche dieser Optionen du baust. Lies references/01-read-the-request.md, falls es nicht offensichtlich ist.

Die Person fragt nach...	Bauen	Lesen
Einer App über ein Unternehmen, eine Person, einen Ort oder eine Sache, die sie verkaufen	Eine Lese-App: Geschichte, echte Beweise, die sie gegeben haben, eine Möglichkeit, sie zu erreichen	01, 02, 03, 09, 04, 10
Etwas zum NUTZEN: ein Dashboard, Tool, Portal, „wie Slack, aber...“, ein Redesign eines funktionierenden Tools	Eine funktionierende App: / ist der funktionierende Bildschirm, mit Demodaten und – wenn sich Leute anmelden – sichtbaren Demo-Anmeldedaten	01, 05 zuerst, dann 03, 09, 04
Einer Aktivität (eine Sprache lernen, Prüfungsvorbereitung, Planung, Tracking) mit einer Zielgruppe und keinem genannten Unternehmen	Eine funktionierende App. Zum Lernen: eine gestaltete Startseite mit Abschnitten, dann Lektionen, Übungen, Fortschritt. KEINE Broschüre für eine erfundene Schule	01, 05, 09
Einer Seite, die ein bestehendes Produkt präsentiert	Eine Lese-App über dieses Produkt	01, 02, 03, 09, 04, 10

Das Wort „Website“ in einer Anfrage entscheidet nicht darüber; Eigentümerwörter („meine Akademie“, „unser Laden“) und die Tätigkeiten der Nutzer tun es. Im Zweifelsfall baue die funktionierende App-Variante und sag dies in deiner ersten Nachricht.

Der Ablauf (Details in references/00-operating-loop.md)

1. Lies die Anfrage. Schreibe .app-notes/brief.json (Fakten mit den eigenen Worten der Person, Unbekanntes, Annahmen) und .app-notes/requirements.json (alles, was sie sagt, jetzt und später). Stelle höchstens eine gebündelte Frage, und nur dann, wenn eine falsche Annahme den Build ändern würde.
2. Recherche und Strategie (neben Schritt 3). Studiere die eigentliche Kategorie, schreibe die neun Strategieantworten und die Design-These. references/02-research-and-strategy.md
3. Inspirationsbretter (neben Schritt 2). Sechs Bretter pro Runde; jedes Brett ist EIN Design, dargestellt als vier Bildschirme derselben App, etwa 2048 x 1280; die Person kann weitere Runden anfordern, bis sie zufrieden ist. Die sechs stammen aus sechs Kandidatenwelten in der Kultur der Zielgruppe, nicht aus sechs Adjektiven (references/09-design-craft.md Abschnitt 2). references/03-design-direction.md
4. Konzepte, Beweise, Gremium. Ein Konzept pro Brett, strukturell unterschiedlich; jedes als echte Seite rendern; bewerten; auswählen.
5. Richte die Richtung ein. DESIGN.md, tokens.css, fonts.css, Kontrastprüfung, ein Bauplan pro Seite.
6. Plan. Seiten und Abschnitte mit Einzeiler-Jobs, Funktionen mit ausführbaren Abnahmeschritten, Bilder mit Jobs.
7. Bauen. Zuerst Fundament, dann Seitenersteller parallel, dann ein Integrator. Nur Tokens, echte Kopien, echte Bilder, funktionierende Steuerelemente. references/04-build-system.md und 05-working-apps.md für funktionierende Apps.
8. Verifizieren mit scripts/check-app.mjs am Produktions-Build: drei Größen, so scrollen wie ein Besucher scrollt, Bilder, gemessene Fakten, ein Design-Scan (Kontrast, Typografie, Hierarchie, bedeckter Text, Generator-Aussagen), Funktionsabläufe, eine aufgezeichnete Tour. references/06-qa-and-repair.md
9. Kritisieren, dann reparieren. Beurteile zuerst das Design, unverankert; dann lies den Scan; dann führe die benannten Durchgänge aus (Layout, Satz, Einfärben, Kühner, Härten, Polieren...) nacheinander, jeder abgegrenzt, jeder endend mit Nachweisen. Korrigiere Ursachen; überprüfe erneut; mache rückgängig, was es verschlechtert hat. references/09-design-craft.md
10. Polieren am ausgewählten Bild, dann ehrlich berichten nur anhand von Messungen.

Überspringe nicht 3, 4, 8 und 9: Hier hört eine App auf, eine Vorlage zu sein, und hier hört „erledigt“ auf, eine Behauptung zu sein. Führe unabhängige Schritte zusammen aus.

Grundsätze (Non-Negotiables)

1. Ehrlichkeit geht über alles. Erfinde niemals Testimonials, Logos, Presseberichte, Bewertungen, Statistiken, Auszeichnungen, Teammitglieder, Adressen, E-Mails, Telefonnummern, Preise, Öffnungszeiten, Antwortzeiten, Richtlinien, Garantien oder Qualifikationen. Eine fehlende Tatsache wird weggelassen (Standard), in eine Einladung umgewandelt oder einmal mit einem sichtbaren <Draft> für den Eigentümer markiert. Das Zählen, was die Person nicht aufgelistet hat, ist Erfindung. Beispieldaten in einer funktionierenden App sind nur erlaubt, weil die App „Demodaten“ auf dem Bildschirm anzeigt.
2. Nichts tut so, als ob es funktioniert. Kein href="#", kein Formular, das nirgendwo hinführt, kein deaktivierter „noch nicht verbundener“ Button, kein Drittanbieter-Formularservice, den die Person nicht gewählt hat, kein Login, das alles akzeptiert. Verdrahte es wirklich oder lasse es weg und sage es.
3. Behaupte niemals, was nicht gemessen wurde. Nicht „getestet“, „verifiziert“, „barrierefrei“, „poliert“ oder „responsiv“ ohne Nachweis für genau diese Behauptung. „Konnte nicht nachsehen“ ist niemals „sauber“. Sage niemals, dass die Arbeit begonnen hat, es sei denn, du hast den Aufruf getätigt, der sie startet.
4. Entscheide das Aussehen anhand von Bildern, vor dem Code, und baue nach dem ausgewählten Bild. Keine Standard-Looks. Lehne die KI-Erkennungsmerkmale erster und zweiter Ordnung ab, es sei denn, die Welt dieses Kunden verdient sie (09 listet sie als Regeln, die das QA-Skript misst; ein review-Ergebnis wird nur mit einem Grund behalten).
5. Ein Designsystem. Farbe, Schriftart, Radius, Schatten und Easing stammen nur aus Tokens. Höchstens zwei Schriftfamilien. Ein signaturartiger Moment und eine bewusste Unvollkommenheit. Akzent sparsam verwendet.
6. Bilder sind großzügig, art-directet und niemals gefälscht. Etwa eines pro Bildschirm Scrollen, ein gemeinsamer Stil, durch das Bildmanifest, echte Alt-Texte; keine handgezeichneten SVG-Bilder von Objekten oder Personen; keine Beschriftungen in Bildern; kein KI-Bild, das als echtes Ereignis beschriftet ist.
7. Richtige Sprache, richtige Schrift. lang und dir gesetzt; echte Schrift (niemals Transliteration als Ersatz); logische CSS-Eigenschaften; Übersetzungen, die du nicht überprüfen kannst, werden für den Eigentümer markiert.
8. Alles, was die Person sagt, wird aufgezeichnet und verwendet. Folgeanfragen, Lenkungen und Antworten gehen in das Anforderungsregister ein und werden von jedem späteren Schritt gelesen. Eine Folgeanfrage setzt dasselbe Projekt fort.
9. Beweise schlagen Code. Jede visuelle Behauptung stammt von einem Bild, das du in diesem Durchlauf bei 390, 768 und 1440 angesehen hast.
10. Ursachen beheben, kleinste Änderung. Reproduzieren, Ursache beheben, erneut überprüfen. Zwei fehlgeschlagene Patches: Komponente neu schreiben. Ein Fehler in einem generierten Bild erfordert ein neues Bild, kein CSS.

Der Starter und die Skripte

<skill> unten ist der Ordner, in dem sich diese SKILL.md befindet (z. B. ~/.claude/skills/ai-website-builder). Führe die Skripte aus dem Projektordner aus.

bash <skill>/scripts/scaffold.sh ./my-app [--app]           # Kopiere den Starter, installiere, lint, baue (--app fügt src/app/ für eine funktionierende App hinzu)
node <skill>/scripts/contrast.mjs --tokens src/styles/tokens.css   # Jedes Farbpaar, das eine Komponente verwendet, Hell und Dunkel
node <skill>/scripts/optimize-images.mjs --src .app-notes/originals --alt .app-notes/alt.json   # avif + webp-Set und das Manifest
pnpm build && pnpm preview                                  # Bediene den PRODUKTIONS-Build (lasse ihn laufen)
node <skill>/scripts/check-app.mjs --url http://localhost:4173 --flows .app-notes/flows.json --tour [--extremes]
                                                            # Bilder, gemessene Fakten, Design-Scan, Funktionsabläufe, aufgezeichneter Besuch, Bericht
                                                            # --extremes fügt 320x640 und 1920x1080 hinzu; --no-design überspringt den Scan

Das QA-Skript benötigt Playwright (pnpm add -D playwright && npx playwright install chromium) oder --chrome /path/to/chrome. Der Optimierer benötigt sharp.

assets/template/ ist Vite + React 19 + TypeScript + Tailwind v4 mit Pre-Rendering pro Route, einem Token-Vertrag, 18 UI-Primitiven, einem Bewegungskit, einem immersiven Kit, einem App-Kit und einem Lint, das den Build bei den üblichen Fehlern fehlschlagen lässt. Seine AGENTS.md ist die maßgebliche Dateikarte; STANDALONE.md sagt, was man von Hand tun muss, ohne eine Hosting-Plattform (Autor-Tokens, Bilder erstellen, Formular-Endpunkt setzen). Verwende für eine funktionierende App scaffold.sh --app (es schreibt src/app/{accounts,db,seed}.ts; eine App, bei der sich niemand anmeldet, behält demoAccounts leer). Verwende einen anderen Stack, wenn das Projekt der Person bereits einen hat: Die Methode, die Regeln und die Skripte hängen nicht von der Vorlage ab.

Helfer einsetzen

Teile die Arbeit mit einem Sub-Agenten-Tool gemäß references/08-role-briefs.md auf und gib jedem Helfer einen disjunkten Schreibbereich (Fundament: gemeinsame Dateien; Seitenersteller: ein Seitenordner pro Stück; Integrator zuletzt). Allein befolgst du dieselbe Reihenfolge. Führe eine gemeinsame To-Do-Liste: Die Einträge der Person sind ihre eigenen und können geändert werden; gib nicht ab, während ein Eintrag, der zu deinem Teil passt, offen ist; am Ende ist jeder Eintrag erledigt, mit einer Notiz blockiert oder nicht erledigt mit einem Grund.

Der Abschlussbericht (nur aus Messungen)

Was du gebaut hast (Seiten, Funktionen); bei einer funktionierenden App, was echt ist und was nachgestellt ist; was die Person bereitstellen muss; was verifiziert wurde (Urteil) und was NICHT verifiziert wurde; was noch offen ist in einfachen Worten; pro Anforderung: gebaut und verifiziert, gebaut und nicht verifiziert, oder nicht erledigt und warum. Kurz, einfach, kein Marketington. Verwende assets/checklists/done.md, bevor du ihn sendest.

Referenzkarte

Datei	Lies sie, wenn …
references/00-operating-loop.md	du den Durchlauf planst, Arbeit aufteilst, die Journale und die To-Do-Liste führst
references/01-read-the-request.md	in den ersten zehn Minuten jedes Auftrags; Lese-App oder funktionierende App; Sprache; Behauptungen; Folgeanfragen
references/02-research-and-strategy.md	du die Kategorie recherchierst, die Strategie und die Design-These schreibst, Seitengerüste auswählst
references/03-design-direction.md	Bretter, Konzepte, Bewegungen, Typografie, handwerkliche Gesetze, KI-Erkennungsmerkmale, Beweise, Gremium, Detailtreue
references/04-build-system.md	du Code schreibst: Tokens, Seiten, Texte, Formulare, Bilder, Animationen, SEO, Barrierefreiheit, Budgets
references/05-working-apps.md	alles, was Leute nutzen: Demo-Backend, Anmeldung, Regionen, Abläufe, Lern-Apps
references/06-qa-and-repair.md	du verifizierst, beurteilst, reparierst, kritisierst, den Abschlussbericht erstellst
references/07-failure-catalogue.md	bevor du startest und bevor du berichtest: was zuvor schiefging und die Abhilfe
references/08-role-briefs.md	du Helfer-Agenten einweist; Tool-Namen zuordnest
references/09-design-craft.md	du entscheidest, wie stark du pushen willst (Besuchermodi), eine Welt aufbaust, Farb- und Schriftart-Baselines, die Erkennungsmerkmale als Regeln, die Verfeinerungsdurchgänge, die beiden Bewertungen, die Bewertung
references/10-copy-and-voice.md	du Text auf der App schreibst oder überprüfst: Stimme aus Fakten, Slot-Regeln, die Erkennungsmerkmale für generierten Prosa
references/11-listening-to-the-audience.md	den Recherche-Schritt: Die Sorgen und Worte der Zielgruppe hören, ohne ihre Behauptungen zu übernehmen
references/12-diagrams.md	ein Wie-es-funktioniert-, Prozess-, Ablauf- oder Architekturbild; in Markup aus Tokens erstellt
references/13-reference-teardown.md	du bis zu drei Referenz-Apps auf Handwerk und Struktur während der Recherche misst
references/14-scripts-and-app-jobs.md	Schriftarten für ein nicht-lateinisches Skript; was Besucher in jeder Art von App tun wollen; Barrierefreiheits-Ergänzungen
references/15-redesign-and-extension.md	eine App bereits existiert: erfasse sie, wähle Polieren, Umstylen oder Vollständig, beweise, dass nichts verloren ging
references/NOTICE.md	Credits und Lizenzen der öffentlichen Projekte, von denen dieses Skill gelernt hat
assets/checklists/brief.md, done.md	die Formen der Journale; die letzte Überprüfung