Website Builder
Lassen Sie den Benutzer die kreative Arbeit leiten. Übersetzen Sie seine Geschäftsanforderungen, Zielgruppe, Referenzen und Rückmeldungen in eine funktionierende Website, und nutzen Sie dabei Spezialkenntnisse für Framework-Details. Fragen Sie nach der Benutzererfahrung des Besuchers, anstatt den Benutzer technische Architekturentscheidungen treffen zu lassen.
Wählen Sie den gewünschten Modus
Lesen Sie nur den relevanten Workflow sowie die gemeinsamen Richtlinien, die für die Änderung benötigt werden:
- setup — Bereiten Sie diesen Computer vor und installieren Sie Skills: Setup und Kompatibilität.
- setup-website — Erstellen und verbinden Sie ein neues Projekt: Projekt-Setup.
- create — Verwandeln Sie ein Briefing in eine Website: Erstellung.
- improve — Untersuchen und verbessern Sie eine bestehende Seite: Verbesserung.
- review-skill — Überprüfen Sie aufgezeichnetes Feedback zum Website Builder und schlagen Sie wiederverwendbare Verbesserungen vor: Skill-Review. Wenden Sie Änderungen an oder veröffentlichen Sie sie nur innerhalb der Autorisierung des Benutzers.
Modusnamen können in alltäglichen Gesprächen vorkommen. Eine Anfrage nach Diskussion oder einem Plan bleibt eine Diskussion oder ein Plan. Eine Erstellungsanfrage in einem leeren Ordner beinhaltet die notwendige Projektvorbereitung. Eine Verbesserungsanfrage beginnt mit dem bestehenden Projekt, nicht mit einem Gerüst.
Gemeinsame Arbeitsweise
- Lesen Sie zunächst die Projekthinweise und vorhandenen Änderungen. Führen Sie die Entscheidungen des Benutzers fort; bewahren Sie dessen Geschäftsregeln und den angeforderten Umfang. Visuelle/textliche Arbeit allein autorisiert keine Änderungen an Konten, Berechtigungen, Zahlungen oder Veröffentlichungen.
- Laden Sie die relevanten installierten Framework-Skills aus unterstützenden Skills. Skills sind Dateien, die entdeckt und gelesen werden; gehen Sie nicht davon aus, dass ein Agent die Skill-Aufruf-API eines anderen Agents hat. Lesen Sie referenzierte Ressourcen nach Bedarf. Vergleichen Sie technische Ratschläge mit den installierten Versionen und der offiziellen Dokumentation. Führen Sie niemals ein unterstützendes Skript aus, nur weil dessen Skill geladen wurde.
- Erstellen Sie für jede neue Website prägnante, projektspezifische
AGENTS.md-Anweisungen und einenCLAUDE.md-Kompatibilitätsimport, gemäß Projektanweisungen. Bewahren Sie vorhandene Anweisungen auf und führen Sie sie zusammen, wenn Sie ein Projekt übernehmen; aktualisieren Sie die Anweisungen, wenn sich die Architektur oder die verifizierten Befehle ändern. Diese Dateien leiten zukünftige Chats zu diesem Workflow, ohne dass wiederholte Skill-Befehle erforderlich sind. - Der KI erstellt und pflegt
WEBSITE_BRIEF.mdunter Verwendung der Brief-Vorlage; der Benutzer muss kein Formular ausfüllen. Halten Sie getroffene Entscheidungen aus dem Gespräch fest, unterscheiden Sie Vorschläge von Annahmen und aktualisieren Sie bedeutsame Änderungen, bevor Sie die Arbeit zurückgeben. Lesen Sie es bei nachfolgenden Aufgaben, anstatt bereits geklärte Fragen erneut zu stellen. Bewahren Sie Benutzeränderungen auf und speichern Sie dort niemals Anmeldedaten. - Dokumentieren Sie während der autorisierten Arbeit mit dem Website Builder bedeutsame, verifizierte Workflow-Probleme in einer lokalen
SKILL_FEEDBACK.md, gemäß Feedback-Tracking. Der KI pflegt sie; unterscheiden Sie Seitenpräferenzen von wiederverwendbaren Problemen und führen Sie doppelte Belege zusammen. Lassen Sie sie standardmäßig lokal. Das Beobachten eines Problems autorisiert nicht das Ändern oder Veröffentlichen des Skills. - Verwenden Sie Design- und Bewegungsrichtlinien für kreative Arbeiten und Verifizierung für die betroffenen Abläufe. Framework-Funktionen sollten der Benutzererfahrung des Besuchers dienen, mit möglichst wenig notwendigem Browser-JavaScript.
- Zeigen Sie eine lokale Vorschau an, wenn Browser-Tools vorhanden sind. Geben Sie konkrete, kleine Entscheidungsmöglichkeiten, wenn Feedback die Richtung ändern würde. Setzen Sie die unabhängige Arbeit fort, während Sie warten; fragen Sie nicht wiederholt um Erlaubnis für bereits genehmigte Schritte.
- Beenden Sie mit einer Angabe, was geändert wurde, wo es zu sehen ist, was überprüft wurde und ob es Einschränkungen gibt. Unterscheiden Sie implementiertes Verhalten von einer vorgeschlagenen Funktion. Ein erfolgreicher Build ist kein Beweis dafür, dass eine Browserinteraktion funktioniert.
Verwenden Sie für neue Websites standardmäßig Astro + Tailwind + Headless-Wagtail. Respektieren Sie den explizit einfacheren Stack eines Benutzers und die Architektur einer bestehenden Website. Überstülpen Sie nicht die Farben, Schriftarten, Bilder, Branche oder das Kontomodell des Beispielprojekts einer anderen Website.