Justesse

Was macht Justesse?

Verwandle eine kurze Beschreibung, ein Repository oder eine visuelle Referenz in eine kohärente Produktionsoberfläche. Behandle Geschmack als kontextuelles Urteil unter Randbedingungen, nicht als bevorzugtes Framework, Ästhetik oder Komponentenrezept.

Hierbei handelt es sich um eine deklarative, referenzbasierte Fähigkeit. Ihre Designlogik, Regeln und Akzeptanzkriterien müssen unabhängig von dem Modell, der Agenten-Laufzeit, dem Kommandozeilenwerkzeug, dem Anbieter und der Hosting-Umgebung bleiben, die sie ausführen. Eine laufzeitspezifische Entdeckung kann dieses Verzeichnis exponieren, darf aber weder die Semantik der Fähigkeit verändern noch für ihren Workflow erforderlich sein.

Betriebsmodus festlegen

Wähle vor Designentscheidungen einen primären Modus aus. Gib ihn im Design-Read an und wechsle nicht stillschweigend zwischen den Modi. Wenn zwei Modi materiell unterschiedliche Ergebnisse implizieren und die Anfrage diese nicht auflöst, stelle eine gezielte Frage. Eine Aufgabe kann einen sekundären Modus benennen, aber der primäre Modus steuert den Workflow und die Akzeptanzschwelle.

Modus	Primäres Ergebnis	Erforderliche Referenz
Marketing / Conversion	Werte vermitteln und ein Publikum zu einer messbaren Handlung bewegen	marketing-surfaces.md
Produkt / Aufgabe	Einem Benutzer helfen, den Zustand zu verstehen und wiederkehrende Arbeiten (inkl. Dashboards) zu erledigen	product-and-transaction.md
Transaktionsfluss	Eine folgenreiche oder mehrstufige Aktion sicher und wiederherstellbar abschließen	product-and-transaction.md
Redesign: Bewahren	Qualität verbessern, während wiedererkennbare Marken- und Produktverträge erhalten bleiben	redesign-preservation.md
Redesign: Überholung	Eine neue visuelle Sprache etablieren, während unveränderbare Verträge beibehalten werden	redesign-preservation.md
Referenz zu Code	Gelieferte visuelle Belege in die native Implementierung des Zielprojekts übersetzen	reference-to-code.md
Visuelle Überprüfung	Hierarchie, Kohärenz, Benutzerfreundlichkeit, Reaktionsfähigkeit und Produktionsrisiken diagnostizieren	interface-quality.md
Lesen / Dokumentation	Einem Leser helfen, etwas durch Dokumentation, Leitfäden, Artikel, Hilfe oder Changelogs zu verstehen	reading-surfaces.md
Erlebnis / Präsentation	Einen Besucher in Portfolio-, Galerie- oder Ausstellungsarbeiten eintauchen lassen, während die Oberfläche zurücktritt	experience-surfaces.md
Bildkonzept	Kunstrichtung definieren oder produzieren, die der Oberfläche dient	image-concepts.md
Datenvisualisierung	Messungen, Vergleiche, Verteilungen, Beziehungen und Unsicherheiten in überprüfbare Beweise verwandeln	data-visualization.md
Executive-Entscheidungsmemorandum	Begrenzte Beweise in eine ergebnisorientierte Präsentation für eine Entscheidungsperson verwandeln	decision-memo.md

Nach Auswahl des primären Modus wird das Profil separat festgelegt. Dieser Skill liefert den Profilmechanismus, aber kein Profil. Aktiviere personal:<name> nur, wenn dieses genaue Flag in der Anfrage oder den Projektanweisungen explizit ist. Leite es niemals aus dem Namen einer Person, einem Artefakttyp oder der Verfügbarkeit dieses Skills ab. Ohne das Flag halte die visuelle Sprache, Stimme, Palette, Materialität und Oberflächenfarbe markenneutral; eine helle Papierleinwand ist kein Standard.

Ein aktives Flag öffnet eine erforderliche Deklaration, gewährt jedoch kein visuelles System. Erhalte konkrete Antworten auf alle zehn Felder in profile-declaration.md, bevor du unter dem Profil eine Designentscheidung triffst, und fülle niemals ein unbeantwortetes Feld durch Rückschluss oder durch Übernahme eines Werts aus einem anderen Profil, aus den Beispielen dieses Skills oder aus seinen Testvorrichtungen. Frage jedes Feld mit einem ausgearbeiteten Beispiel an, in der Antwortform dieses Feldes; eine bloße Frage führt zu einer Stimmung, in der die Form eine Messung benötigt.

Kernworkflow

1. Prüfen vor dem Vorschlagen. Lies die relevanten Projektdateien, repräsentative Bildschirme und Komponenten, Paket- und Build-Konfiguration, Design-Tokens, Datenstrukturen, Routen, Tests und gelieferte Referenzen. Identifiziere, was echt ist, was abgeleitet ist und was unbekannt bleibt.
2. Das Briefing formulieren. Lies brief-and-direction.md. Halte Zielgruppe, Benutzeraufgabe, Geschäftsziel, Inhalts- und Markenbelege, Randbedingungen, primären Modus und Erfolgssignal fest. Zähle jedes angeforderte Ergebnis vor der Implementierung auf. Bevorzuge eine vertretbare Interpretation gegenüber einer Collage von Trends.
3. Den Design-Read deklarieren. Gib in einer kompakten Aussage den Modus, die Zielgruppe, die Produktaufgabe, die visuelle Richtung, Dichte und Bewegungs-Haltung an. Unterscheide Entscheidungen von Annahmen.
4. Den Produktvertrag einhalten. Behalte das bestehende Framework, den Paketmanager, Komponentenkonventionen, Designsystem, Daten- und API-Verträge, Zustandssemantik, Routen, Formulare, Analysen, Einwilligungs- und Rechtsverhalten, Barrierefreiheit, SEO, Inhaltsbedeutung, Tests und Leistungsbudgets bei, es sei denn, der Benutzer autorisiert explizit eine Änderung. Der Überholungsmodus ist keine Erlaubnis, sie zu brechen.
5. Nativ implementieren. Verwende installierte Abhängigkeiten und etablierte Primitive. Drücke die Richtung im eigenen Framework und Stilmodell des Projekts aus. Führe React, Tailwind, GSAP, ein anderes Designsystem, den Dunkelmodus, eine Schriftart oder eine Abhängigkeit nicht bloß deshalb ein, weil dieser Skill eine visuelle Möglichkeit erwähnt.
6. Den gesamten Zustandsraum auflösen. Gestalte responsives Layout plus die zutreffenden Lade-, Leer-, Teil-, Fehler-, Erfolgs-, Deaktiviert-, Berechtigungs-, Offline-, Validierungs- und Destruktionsaktions-Zustände. Für Dashboards und Abläufe schütze die Lesbarkeit von Daten, die Kontinuität von Aufgaben und die Wiederherstellbarkeit.
7. In begrenzten Durchgängen rendern und verifizieren. Baue zuerst vollständig. Prüfe dann repräsentative schmale und breite Viewports sowie echte Inhaltsextreme gemeinsam in einem gebündelten Durchgang, wenn eine Vorschau-Umgebung existiert, und vergleiche Hierarchie, Lesereihenfolge, Überlauf, Kontrast, Fokus, Interaktions-Feedback und Vertragstreue. Behebe alles, was dieser Durchgang zeigt, in einem Durchgang, bestätige mit höchstens einem weiteren Durchgang und höre auf zu polieren: Eine offene Selbst-QA-Schleife verbraucht das Budget ohne Konvergenz, und die Begrenzung deckt den gesamten Zyklus ab, einschließlich Screenshots, Fehlerscans, Mikro-Editierungen und Neuerstellungen. Bezeichne ein Mockup nicht als produktionsreif ohne angemessene Build-, Test- und visuelle Belege.
8. Lieferung prüfen. Lies production-preflight.md, behebe zutreffende Fehler, überprüfe jedes angeforderte Ergebnis und melde Checks, die nicht ausgeführt werden konnten.

Referenz-Routing

Lade nur das, was der aktive Modus benötigt; jede Referenz ist hier direkt verlinkt.

• Immer lesen: brief-and-direction.md, interface-quality.md und production-preflight.md.
• marketing-surfaces.md für Marketing-, Kampagnen-, Redaktions-Conversions-, Preis-, Launch- oder andere Akquisitionsflächen.
• reading-surfaces.md für Dokumentation, Leitfäden, Artikel, Hilfe, Changelogs und lange Seiten, deren Aufgabe das Verstehen ist.
• experience-surfaces.md für Portfolios, Galerien, Präsentationen und Ausstellungsseiten, bei denen die Arbeit selbst im Vordergrund steht.
• product-and-transaction.md für Anwendungs-UIs, Dashboards, datendichte Arbeitsbereiche, Formulare, Checkout, Onboarding, Einstellungen und mehrstufige Abläufe.
• data-visualization.md immer dann, wenn eine Oberfläche einen KPI, ein Diagramm, eine analytische Abbildung, einen Metrikvergleich, eine Zahlentabelle oder eine Datums-/Zeitraumanzeige enthält.
• redesign-preservation.md immer dann, wenn eine bestehende Oberfläche sich ändert, entweder im Bewahrungs- oder Überholungsmodus.
• reference-to-code.md wenn Screenshots, Mockups, Websites oder andere visuelle Beispiele Implementierungseingaben sind.
• image-concepts.md nur, wenn Bildmaterial Teil des Briefings ist oder der Bildkonzept-Modus ausgewählt wurde.
• style-lenses.md wenn das Briefing keine visuelle Sprache enthält oder konkurrierende Richtungen getrennt werden müssen.
• finishing.md zuletzt und nur, wenn die Interface-Qualitätschecks bestehen, für lieferungsreife Verfeinerung und zur Beurteilung nahezu identischer Kandidaten; Fertigstellung ersetzt niemals Hierarchie, Wahrhaftigkeit oder Zustände.
• react-next-tailwind.md nur, wenn das untersuchte Projekt bereits React, Next.js oder Tailwind verwendet oder der Benutzer diesen Stack ausdrücklich für die Neuerstellung autorisiert hat; es ist nicht der portable Standard.
• decision-memo.md für ein Executive-Memo, Entscheidungs-Deck oder jede ergebnisorientierte Foliensequenz.
• pptx-safe-html.md vor dem Layout der ersten Folie immer dann, wenn das Ergebnis eine bearbeitbare Präsentationsdatei und keine Seite ist.
• surface-translation.md wenn eine Weltanschauung über ein Dashboard, eine verfasste Landingpage, eine Fallstudie, einen Bericht und eine Präsentation hinweg getragen werden muss.
• Mit dem exakten personal:<name>-Flag zuerst profile-activation.md und profile-declaration.md lesen, dann profile-data-semantics.md, sobald die Deklaration vollständig ist. Andernfalls weder laden noch anwenden.
• profile-calibration.md nur bei einem kontrollierten Profilvergleich, einer Negativkontrolle, einer Blindprüfung oder einer Beförderungsentscheidung lesen.
• upstream-provenance.md nur für Zuschreibung, Prüfung, Weiterverteilung oder Upstream-Vergleich lesen.

Lade keine unzusammenhängenden Dateien rekursiv aus Referenzen.

Bedingte Fähigkeiten

Verwende Bildgenerierung, Bildsuche oder Browsen nur, wenn verfügbar, autorisiert und notwendig. Für Bildarbeit bevorzuge vorhandene Repository-Assets, dann vom Benutzer bereitgestellte Assets, dann ein autorisiertes Werkzeug. Andernfalls liefere eine spezifische Konzeptbeschreibung oder ein klar gekennzeichnetes Platzhalterbild, ohne zu behaupten, es sei finale Kunst. Verwende Platzhalter nur für wirklich fehlende externe Assets oder Abhängigkeiten; gib die Abmessungen, Rolle und den nächsten Ersetzungsschritt jedes Platzhalters an. Erfinde keine Produkt-Screenshots, Kunden, Metriken, Logos oder Empfehlungen.

Verwende Bewegung nur, wenn sie Hierarchie, Feedback, Kontinuität oder Erzählung verdeutlicht. Bevorzuge den bestehenden Mechanismus des Projekts und die leichteste ausreichende Technik. Bewahre Inhalte ohne Bewegung, ehre reduzierte-Bewegung-Einstellungen, vermeide Scroll-Erfassung und räume Observer, Listener und Zeitpläne auf. Bewegungsbibliotheken sind bedingte Implementierungsentscheidungen, niemals eine Anforderung. Eskaliere zu motion-patterns.md nur, wenn ein nativer CSS-Übergang nicht mehr ausreicht und die Arbeit geschichtete Choreografie, Scroll-Storytelling oder eine dedizierte Animations-Engine benötigt.

Liefervereinbarung

Liefere die implementierte oder überprüfte Oberfläche zusammen mit dem Modus und dem Design-Read, den beibehaltenen und beabsichtigt geänderten Verträgen, Verifikationsbelegen sowie allen Platzhaltern oder ungelösten Risiken. Gib bei einer reinen Überprüfungsanfrage die Befunde nach Benutzerauswirkung priorisiert an und zitiere den betroffenen Bildschirm oder die betroffene Komponente; verändere das Projekt nicht, es sei denn, du wirst darum gebeten.