Ein Gestaltungswerkzeug für KI-Agenten bauen und Befehle und Prüfungen ordnen

## Gestaltungsbefehle in einem Skill bündeln und jedem eine Referenzdatei zuordnen Halten Sie das für Benutzer sichtbare Befehlsangebot übersichtlich und leiten Sie jeden erkannten Befehl an gezieltes Referenzmaterial weiter. Eine Zusammenführung reduziert unübersichtliche Menüs und erleichtert die Pflege gemeinsamer Gestaltungsgesetze. ### Befehlsarchitektur - Bevorzugen Sie eine vom Benutzer aufrufbare Gestaltungsfunktion mit Unterbefehlen gegenüber vielen eigenständigen Funktionen, sofern nicht wirklich ein eigener Lebenszyklus erforderlich ist. - Pflegen Sie eine einzige Weiterleitungstabelle, die jeden Befehl seiner Referenzdatei zuordnet. - Halten Sie Befehlsbeschreibungen, Argumenthinweise, Kategorien und Beziehungen in verbindlichen Metadaten, die von Buildvorgängen und Kurzbefehlsgeneratoren verwendet werden. - Erzeugen Sie anbieterspezifische Funktionsdateien aus einer gemeinsamen Quelle, statt die Kopie jedes Anbieters einzeln zu bearbeiten. - Verwenden Sie schlanke Kurzbefehle nur als Weiterleitungen zum kanonischen Befehl. - Legen Sie gemeinsame Regeln in der gemeinsamen Quelle und befehlsspezifische Entscheidungen in der zugehörigen Referenz ab; verweisen Sie auf gemeinsame Leitlinien, statt sie zu duplizieren. ### Kontextweiterleitung - Lesen Sie den Projektkontext, bevor Sie ein Register oder ein plattformspezifisches Regelwerk auswählen. - Geben Sie einem ausdrücklich gesetzten Projektfeld Vorrang, nutzen Sie danach Hinweise aus Aufgabe und Oberfläche und schließlich einen dokumentierten Standardwert. - Warnen Sie bei unbekannten Kontextwerten, statt stillschweigend ein unpassendes Regelwerk anzuwenden. - Laden Sie Variantenreferenzen anstelle der Standarddatei, wenn das Plattformverhalten eines Befehls erheblich abweicht. ## Zuerst Marke oder App festlegen, dann die Regeln für Web oder Betriebssystem ergänzen Behandeln Sie Gestaltungszweck und Auslieferungsplattform als unabhängige Achsen. Das Register bestimmt das Erlebnisziel; die Plattform bestimmt Interaktionskonventionen und Umsetzungsbeschränkungen. ### Gestaltungsregister - Verwenden Sie ein Markenregister, wenn die Gestaltung selbst das Produkt ist: für Marketing, Kampagnen, Portfolios, redaktionelle Erlebnisse und unverwechselbare öffentliche Oberflächen. - Beurteilen Sie Markenarbeit anhand ihrer Unverwechselbarkeit über viele visuelle Richtungen hinweg, statt einen einzigen modischen Stil zu erzwingen. - Verwenden Sie ein Produktregister, wenn die Gestaltung einer Anwendung, einer Übersicht, einer Verwaltungsoberfläche oder einem Werkzeug dient. - Beurteilen Sie Produktarbeit danach, ob erfahrene Benutzer berechtigte Vertrautheit, Vertrauen und Sicherheit in der Bedienung entwickeln. - Fragen Sie früh nach dem Register, da es nachgelagerte Gestaltungsentscheidungen verändert. ### Plattform - Unterscheiden Sie responsive Webangebote, eine einzelne native Plattform und eine adaptive plattformübergreifende Bereitstellung. - Ergänzen Sie das ausgewählte Register um Leitlinien der nativen Plattform, statt die Plattform als Ersatz für den Gestaltungszweck zu behandeln. - Wenden Sie bei adaptiven Produkten beide nativen Regelwerke an und passen Sie sie an das jeweilige Betriebssystem an; eine einzige visuelle Ausführung auf allen Plattformen ist nicht adaptiv. - Lassen Sie Browser-Einblendungen, HTML-Prüfer und aktive Webschnittstellen für native Projekte deaktiviert, selbst wenn deren Quelldateien webähnliche Erweiterungen verwenden. - Belassen Sie die Prüfung der Barrierefreiheit in einem eigenen Prüfpfad. Fügen Sie während der kreativen Erzeugung nicht wiederholt allgemeine Hinweise zur Barrierefreiheit ein, wenn dadurch zwar vorsichtige, aber gestalterisch unausgereifte Arbeit entstünde. ## Farbregeln und eine Liste verbotener Wendungen für öffentliche Texte einhalten Visuelle Variablen, Layoutcode, redaktionelle Stimme und veröffentlichte Inhalte benötigen eindeutige Verantwortliche und automatische Prüfungen, ohne menschliches Gestaltungsurteil zu ersetzen. ### Visuelle Grundlagen - Bevorzugen Sie eine kleine, überprüfbare Stilarchitektur mit einem Einstiegspunkt, gemeinsamen Variablen und gezielten Teilmodulen. - Verwenden Sie semantische Farbvariablen konsequent: die kontrastreichste Schriftfarbe für Fließtext, weichere dunkle Töne nur bei ausreichend großer Schrift und gedämpfte Töne für nachgeordnete Beschriftungen. - Vermeiden Sie reines Schwarz und reines Weiß, wenn das visuelle System abgetönte Extremwerte definiert. - Halten Sie Umsetzungsregeln nahe an der von ihnen geregelten Oberfläche und bewahren Sie die automatische Neuladung, wo sie unterstützt wird. ### Redaktionelle Disziplin - Lesen Sie die redaktionellen Vorgaben des Projekts, bevor Sie öffentliche Texte, Anleitungen, Dokumentation oder Marketingseiten ändern. - Setzen Sie eine dokumentierte Ausschlussliste für überstrapazierte Formulierungen, Satzzeichen und KI-typische Prosamuster durch. - Umgehen Sie eine Textprüfung nicht mit Rechtschreibtricks. Hat ein verbotener Begriff eine notwendige technische Bedeutung, schlagen Sie eine Änderung des Stilhandbuchs vor. - Prüfen Sie strukturelle Probleme, die reguläre Ausdrücke nicht beurteilen können, darunter inhaltsleere Gewissheit, wiederkehrender Rhythmus, automatische Dreiergruppen und schematische Kontrastwendungen. - Halten Sie jeden redaktionellen Inhalt in einem einzigen Inhaltsbaum, den sowohl die Buildwerkzeuge als auch das Darstellungsgerüst verwenden. - Geben Sie redaktionellen Begleittexten zu Befehlen eine kurze Bezeichnung sowie Abschnitte für Einsatzfälle, Vorgehen, konkrete Beispiele und tatsächliche Fallstricke. ## Automatisch erzeugte Dateien nicht mit alltäglichen Gestaltungsänderungen vermischen Trennen Sie Bearbeitungsquellen, erzeugte Auslieferungen, lokalen Zustand und Veröffentlichungsausgaben, damit gewöhnliche Gestaltungsarbeit keine störenden oder irreführenden Artefakte erzeugt. ### Quellorientierte Buildvorgänge - Verwenden Sie im normalen Entwicklungsbetrieb quellorientierte Buildvorgänge und einen getrennten Veröffentlichungs-Build, wenn versionsverwaltete Anbieterauslieferungen abgeglichen werden müssen. - Behandeln Sie erzeugte Anbieterverzeichnisse als Auslieferungsartefakte und nicht als Bearbeitungsoberflächen, auch wenn sie für die Installation absichtlich eingecheckt werden. - Halten Sie erzeugte Varianten aus Funktionsänderungen heraus, sofern die Aufgabe keine Veröffentlichung, keinen Abgleich erzeugter Ausgaben und keine Änderung des Buildsystems betrifft. - Erzeugen Sie versionsverwaltete Ausgaben nach Quelländerungen über den genehmigten Ablauf neu und lassen Sie die Prüfung fehlschlagen, wenn Manifeste, Metadaten oder erzeugte Kopfmetadaten auseinanderlaufen. - Ignorieren Sie lokale Zustandsdateien, selbst wenn sie in versionsverwalteten Auslieferungsverzeichnissen liegen. - Starten Sie den Entwicklungsserver neu, wenn Inhaltslader oder Befehlsmetadaten nicht automatisch neu geladen werden; verwechseln Sie das Aktualisieren des Browsers nicht mit dem erneuten Laden von Daten aus der Buildphase. ### Veröffentlichte Medien - Erzeugen Sie Vorschaubilder für soziale Medien und ähnliche Medien aus verbindlichen Metadaten, damit sichtbare Zahlen und Bezeichnungen nicht auseinanderlaufen können. - Rendern Sie in höherer Auflösung und verkleinern Sie anschließend, wenn gestochen scharfer Text erforderlich ist. - Wenn ein sichtbar verändertes Medium eine Cacheaktualisierung durch einen neuen Namen erfordert, ändern Sie den Dateinamen und alle Verweise in derselben Änderung. - Prüfen Sie Bereitstellungsrouten, Umschreibregeln, statische Dateien und Serverfunktionen mit dem für die Plattform vorgesehenen Buildvorgang. - Befüllen Sie externe Vorschauzwischenspeicher erst vor, nachdem die neue Bereitstellung erreichbar ist. ## Ohne Erlaubnis nichts bei fremden Projekten einreichen und kostenpflichtige Tests trennen Gestaltungswerkzeuge dürfen die Umsetzung automatisieren, aber ohne ausdrückliche Befugnis keine Grenze überschreiten, an der ein menschlich autorisierter Beitrag erforderlich ist. ### Beitragsberechtigung - Befolgen Sie die Vorgabe des Repositorys, zunächst ein Ticket oder zunächst eine Genehmigung einzuholen. - Eröffnen Sie kein externes Ticket und keinen Änderungsantrag, sofern der befugte Verantwortliche dies nicht verlangt oder eindeutig genehmigt hat. - Legen Sie den Einsatz von KI in Commits, Änderungsbeschreibungen, Kommentaren und Tickettexten offen, wenn die Richtlinie dies verlangt. - Wird ein nicht autorisierter KI-Agent dennoch zur Veröffentlichung aufgefordert, stoppen Sie die externe Aktion und erstellen Sie stattdessen eine lokale Übergabenotiz. - Halten Sie erzeugte Veröffentlichungsartefakte und sachfremde Abgleichänderungen aus gewöhnlichen Beiträgen heraus. ### Testauswahl - Belassen Sie schnelle deterministische Einheiten- und Testdatentests in der Standardsuite. - Stellen Sie browsergesteuerte vollständige Ablauftests, die Installation von Abhängigkeiten, aktive Entwicklungsserver und kostenpflichtige Modellaufrufe hinter ausdrücklich aufzurufende Befehle. - Führen Sie kostspielige Tests mit echten Diensten aus, wenn Sie den von ihnen abgedeckten Integrationspfad ändern, und nicht unbegrenzt als Standard. - Halten Sie Testagenten hinter einer schmalen Schnittstelle austauschbar und verwenden Sie deterministische Attrappen für eine breite Testdatenabdeckung. - Prüfen Sie bei Verhaltensbewertungen die Spuren der Werkzeugaufrufe statt ausgefeilter frei formulierter Antworten. - Beziehen Sie mehrere Modellfamilien ein, wenn die anbieterübergreifende Weiterleitung das zu prüfende Verhalten ist, und überspringen Sie die Tests sauber, wenn Zugangsdaten fehlen. - Nehmen Sie kostenpflichtige Bewertungssuiten nur dann in die kontinuierliche Integration auf, wenn deren Kosten und Schwankungen beabsichtigt sind. ## Beim Hinzufügen von Befehlen alle Listen anpassen und neue Versionen getrennt veröffentlichen Befehle und unabhängig ausgelieferte Komponenten erfordern synchronisierte Metadaten, doch Funktionsarbeit und Veröffentlichungsarbeit sollten getrennt bleiben. ### Befehle hinzufügen oder ändern - Fügen Sie Befehlsreferenz, Weiterleitungseintrag, Menüeintrag, Liste gültiger Befehle, Metadaten, Kategorie, Beziehungen und Visualisierungszuordnung gemeinsam hinzu. - Aktualisieren Sie jede für Menschen sichtbare Befehlsanzahl und lassen Sie den Buildvorgang maschinenlesbare Anzahlen aus der Weiterleitungstabelle ableiten und prüfen. - Halten Sie optionale redaktionelle Inhalte von Beschreibungen zur automatischen Auslösung getrennt: Die einen sind für Leser geschrieben, die anderen für den Befehlsabgleich. - Wenn ein plattformspezifischer Befehl erheblich abweicht, fügen Sie eine weitergeleitete Variante hinzu und halten Sie gemeinsame Betriebssystemdetails in Plattformreferenzen fest. ### Versions- und Veröffentlichungsrichtlinie - Erhöhen Sie bei einer gewöhnlichen Funktionsänderung weder Versionsnummern noch fügen Sie Versionshinweise hinzu. - Versionieren Sie unabhängig ausgelieferte Komponenten getrennt und aktualisieren Sie nur die geänderte Komponente. - Aktualisieren Sie für eine Veröffentlichung das verbindliche Manifest und die synchronisierten Spiegel, fügen Sie benutzersichtbare Hinweise hinzu, führen Sie den Veröffentlichungs-Build aus und erstellen Sie anschließend einen Tag mit dem komponentenspezifischen Präfix. - Prüfen Sie die Veröffentlichungsautomatisierung vor der Veröffentlichung in einer Vorschau. - Lehnen Sie die Veröffentlichung ab, wenn das Arbeitsverzeichnis nicht sauber ist, der Zweig nicht synchronisiert ist, die Kennzeichnung bereits existiert, Hinweise fehlen oder die Neuerzeugung nicht eingecheckte Abweichungen hervorbringt. - Halten Sie Einträge im Änderungsprotokoll knapp und benutzerorientiert; lassen Sie interne Umstrukturierungen, Werkzeugdetails und den Abgleich erzeugter Ausgaben weg. ## Vor einer neuen Gestaltungsprüfung zuerst einen fehlschlagenden Test schreiben Wenn ein Gestaltungsprüfer eine Kommandozeile, eine Browser-Einblendung, eine Erweiterung und eine Website bedient, muss seine Regelmaschine eine einzige Quelle besitzen, und jeder daraus abgeleitete Verbraucher muss neu erstellt und geprüft werden. ### Reihenfolge der Regelentwicklung 1. Fügen Sie eine Testdatei mit eindeutig gekennzeichneten Beispielen hinzu: mindestens vier Fälle, die beanstandet werden sollen, und mindestens fünf Erscheinungsformen von Fehlalarmen. 2. Verwenden Sie ausdrückliche Abmessungen, wenn das Test-DOM keine Layoutmaschine besitzt. 3. Fügen Sie einen gezielten Test hinzu und beobachten Sie, dass er fehlschlägt, bevor Sie die Regel umsetzen. 4. Fügen Sie Regelmetadaten und eine reine Prüffunktion hinzu, die ohne DOM-Zugriff stabile Kennungen und Ausschnitte zurückgibt. 5. Implementieren Sie getrennte Adapter für Browser und Test-DOM und binden Sie anschließend beide Adapter in jede relevante Durchlaufschleife ein. 6. Erstellen Sie jeden erzeugten Verbraucher des Prüfers neu und führen Sie die vollständige Testsuite aus. 7. Prüfen Sie die Testdatei und eine repräsentative echte Seite in einem Browser, um Abweichungen zwischen Adaptern und Fehlalarme zu erkennen. ### Disziplin bei Testdateien und Bewertungen - Verwenden Sie stabilen zitierten Text oder eine andere deterministische Kennung in Ausschnitten, damit Tests den passenden Fall extrahieren können. - Verlassen Sie sich in einem DOM-Emulator nicht auf die Layoutgeometrie; werten Sie stattdessen ausdrückliche Stilangaben aus. - Verwenden Sie gemeinsame Hilfsfunktionen für Hintergründe, Farbverläufe und Farbnormierung, wenn sich das Verhalten von Browser und Emulator unterscheidet. - Vergleichen Sie bei der Wirkungsmessung Gestaltungsergebnisse aus derselben Aufgabenbeschreibung mit und ohne Gestaltungssystem. - Halten Sie die Bewertungsinfrastruktur in einem eigenen Arbeitsbereich mit eigenen Betriebsanweisungen. - Erstellen Sie vor einer Bewertungsreihe die neueste Gestaltungsquelle und aktualisieren Sie den Filter für eingebettete Funktionsabschnitte, sobald sich Leitlinienüberschriften der obersten Ebene ändern.