Was macht beedle?
Erstelle Marketing-Seiten, die Suchmaschinen und KI-Crawler lesen können, die ein Fremder in zehn Sekunden versteht und die nur das behaupten, was belegt werden kann. Weniger ist mehr: Jeder Abschnitt muss sich seinen Platz verdienen. Jede Runde endet mit einer unabhängigen Überprüfung.
Lektionen: Lies vor Schritt 1 die Datei design/LESSONS.md des Projekts, falls vorhanden, und befolge alles, was darin zur Marketing-Seite steht. Das sind die Korrekturen des Eigentümers.
1. Das Projekt lesen
Finde heraus, was bereits existiert, bevor du etwas fragst: den Stack und Host, eine etwaige aktuelle Seite, den tatsächlichen Namen des Produkts, das Repository, Store-Einträge, Preise, Screenshots, Design-Tokens oder Theme, Analysen und docs/marketing/page-brief.md.
Baue mit dem Stack, den das Projekt bereits verwendet. Für eine neue Seite folge reference/seo.md („Stack auswählen“). Marketing-Inhalte sind niemals Flutter Web oder client-seitig gerendert, da Crawler sie möglicherweise nie sehen.
Verwende das Theme des Projekts, falls vorhanden (design/THEME.md, *.tokens.json). Falls nicht, portiere die Tokens aus der App. Wenn es auch keine App zum Portieren gibt, schreibe die eine kleine Datei in reference/small-theme.md, weil eine Seite kein Design-System benötigt. Greife nur dann auf den Skill ultrahand:theme zurück, wenn der Nutzer nach einem Theme fragt oder wenn mehrere Seiten oder eine App es gemeinsam nutzen müssen.
2. Typ und Startzustand auswählen
Lies reference/page-types.md. Wähle einen Typ und einen Zustand (Pre-Launch oder Live) und notiere die unterstützenden Seiten, die die Website benötigt.
3. Das Briefing schreiben
Speichere docs/marketing/page-brief.md im Projekt unter Verwendung dieser Vorlage. Es ist der Vertrag, den der Prüfer mit der Seite abgleicht, und der Ausgangspunkt für die nächste Sitzung.
# Page brief
- Type and state:
- Audience: (who, and what they already know)
- The page's one job:
- Primary CTA: (exact words and destination)
- Secondary action: (one, lighter, or "none")
- Search phrases: (3-5 things this audience actually types)
- Objections: (the real reasons someone would leave)
- Analytics and cookies: (what loads, or "none")
## Claims
| Claim on the page | Evidence |
| --- | --- |
| <every number, quote, comparison, "first", "fastest", ...> | <file, link, or measurement, with date> |
| <a plain description of what it is or does> | <file or link, or `README only` if that's all there is> |
## Waiting on a person
- <who: what they must do, or "nothing">
Frage den Nutzer nur nach dem, was das Projekt nicht beantworten kann – normalerweise die Zielgruppe und die Belege. Erfinde niemals Beweise. Ein fehlendes Testimonial ist ein fehlender Abschnitt, kein Platzhalter zum Ausfüllen. Verwende auffällige Platzhalter (Sentinels), die laut scheitern, wie APP_STORE_ID_TODO, statt plausibler Fake-Werte.
Wenn du nur die README hast, kannst du die Seite trotzdem bauen. Sie kann klar sagen, was das Produkt ist und tut: markiere diese Zeilen mit README only. Sie kann keine Zahlen, Daten, Versionen, Lizenz, Preis, Sicherheit, Datenschutz oder Verfügbarkeit belegen – suche daher für jede Angabe eine Primärquelle: den Code, eine LICENSE-Datei, eine Release-Seite, einen Registry- oder Store-Eintrag, eine Messung oder die datierte Aussage des Eigentümers. Zitiere diese Quelle. Wenn es keine gibt, lasse die Behauptung von der Seite weg.
Alles, was nur eine Person liefern kann, kommt unter Waiting on a person, sobald du davon weißt: ein echter Screenshot, eine Domain, ein zu bestätigender Preis. Es bleibt dort, bis die Person es erledigt hat.
4. Zuerst den Text schreiben
Folge reference/message.md. Schreibe den Text vor jedem Layout. Beginne mit den fünf Blöcken dort. Füge einen Abschnitt nur hinzu, wenn du den Einwand nennen kannst, den er beantwortet, und halte diesen Einwand im Briefing fest.
5. Bauen
Folge reference/seo.md für das, was in die Seite und daneben gehört. Verwende echte Produkt-Screenshots oder Aufnahmen und bezeichne eine Nachbildung niemals als Screenshot. Eine Aufnahme der echten App mit Beispieldaten ist echt: sag auf der Seite, dass es ein Beispiel ist, und sag in der Behauptungstabelle, wie du es erstellt hast. Wenn es nichts Echtes zu zeigen gibt, lasse das Bild weg oder hinterlasse einen Platzhalter, wenn der Seitentyp einen benötigt. Vermeide die im Nachrichten-Referenz genannten Design-Merkmale, da sie eine Seite generiert aussehen lassen, bevor jemand sie gelesen hat.
6. Selbstprüfung
Baue die Seite und führe die Prüfung auf der gebauten Ausgabe durch, behebe dann jeden Fehler, den du kannst:
beedle audit --dir <built site>
Füge für jeden Abschnitt, der kein Marketing ist (wiederholbar), --exclude docs hinzu. Wenn beedle nicht im PATH ist, teile dem Nutzer mit, dass die Prüfung nicht durchgeführt wurde und dass INSTALL.md erklärt, wie man es hinzufügt.
Ein Fehler, den nur eine Person beheben kann, bleibt bestehen, z. B. ein DOMAIN_TODO-Platzhalter für eine Domain, die niemand gekauft hat. Tausche niemals einen Fake-Wert ein, um eine saubere Ausführung zu erhalten. Stelle sicher, dass es unter Waiting on a person steht, und fahre dann mit der Überprüfung fort.
7. Die Runde überprüfen
Jede Runde endet mit einer Überprüfung durch einen frischen Prüfer in einer eigenen Sitzung, bevor du dem Nutzer sagst, dass die Seite fertig ist. Eine Runde ist der erste Bau und jede spätere Eingabeaufforderung, die die Seite ändert – daher wird auch eine einzeilige Textänderung überprüft. Überspringe dies nur, wenn der Nutzer sagt, dass die Runde übersprungen werden soll, und sage, dass du es übersprungen hast.
Starte sie selbst, ohne dazu aufgefordert zu werden. Du kannst deine eigene Seite nicht fair überprüfen: Du siehst, was du bauen wolltest. Folge review/round.md. Lies kurz: Schreibe das Briefing, führe beedle review --brief <brief> --add-dir <project> im Hintergrund aus und handle dann die Ergebnisse. Veröffentliche, stelle bereit oder erkläre die Seite nicht für fertig, bevor dies erledigt ist.
8. Bericht
Sage, was du gebaut hast, den Typ und Zustand, das Urteil und was die Überprüfung gefunden, behoben und offen gelassen hat, mit den Kosten.
Wenn das Urteil Kann nicht ausgeliefert werden, bis eine Person handelt lautet, führe damit an: Die Seite ist nicht fertig, wer was tun muss und was die nächste Runde prüfen wird, sobald dies erledigt ist. Schätze es niemals auf „fast fertig“ herunter.
Liste immer auf, was nach dem Start für den Eigentümer noch zu tun ist: Search Console- und Bing Webmaster-Verifizierung sowie der Rich Results Test auf der veröffentlichten Seite.
Stelle nicht bereit, es sei denn, der Nutzer fragt danach.
9. Lernen
Wenn der Eigentümer das Ergebnis korrigiert oder eine dauerhafte Präferenz angibt, füge eine Zeile zur Datei design/LESSONS.md des Projekts hinzu (erzeuge sie bei Bedarf). Wenn die Korrektur zeigt, dass diese Regeln für jedes Projekt falsch sind, korrigiere die Regel auch hier.