Communitygithub.com

Nextora-Designsystem

Eigene Farben, Typografie, Abstands-Tokens, Stilvarianten und der optionale Besucher-Farb-/Schrift-Schalter für das Nextora-Eltern-Theme und seine Kind-Designs. Verwenden Sie diese Fähigkeit, wenn eine Anfrage eine Palette, eine Farbrolle, einen Preset-Slug, eine Schriftfamilie oder ein Schrift-Preset, theme.json-Einstellungen, Tailwind-@theme-Aliase, CSS-Custom-Properties, eine Stilvariation, 'der Palette folgen', 'muss mit der Wahl des Besuchers wechseln', blockbezogene Farben oder das Erscheinungsbild für ein neues Kind-Theme erwähnt.

Was ist Nextora-Designsystem?

Das Nextora-Designsystem fungiert als alleinige Autorität für das Erscheinungsbild in dieser Suite von WordPress-Themes. Es zentralisiert die Definition von Farbpaletten, Typografie, Abstands-Tokens, Stilvarianten und einem optionalen Besucher-Schalter für Farbschemata und Schriftarten. Entwickler, die mit Nextora-Eltern- oder Kind-Designs arbeiten, verwenden dieses System, um ein konsistentes visuelles Vokabular sicherzustellen, anstatt Werte in Code oder Block-Komponenten fest zu codieren. Das Skill-Dokument beschreibt einen strengen, schrittweisen Arbeitsablauf, der mit dem Auslesen der aktiven `theme.json`- und CSS-Quellen beginnt, gefolgt von der Entscheidung über den korrekten Mechanismus (z. B. native Block-Unterstützung vs. Theme-Style-Variation vs. Besucher-Schalter). Es schreibt vor, dass Änderungen additiv und nach Identifikator erfolgen müssen, ohne geerbte Eltern-Slugs umzubenennen. Typografie wird über dedizierte CSS-Custom-Properties (`--nextora-font-body`, `--nextora-font-heading`, `--nextora-font-button`) gesteuert, sodass ein Schriftwechsel des Besuchers automatisch auf allen Oberflächen greift. Blockbezogene Farben werden als Preset-Slugs gespeichert und über Preset-Variablen ausgegeben, sodass eine Palettenänderung die gesamte Darstellung aktualisiert. Der Besucher-Schalter ist hinter einem Feature-Flag (`NEXTORA_COLOR_SCHEME_SWITCHER`) verborgen; Kind-Designs liefern nur Daten (JSON-Dateien für Farbschemata und Schrift-Presets), niemals Code oder eine eigene Implementierung. Das System definiert strikte Grenzen: Kein Härten von Palettenwerten, keine Neuimplementierung des Schalters, keine Modifikation von Eltern- oder Beispiel-Kind-Designs während der Arbeit. Die Qualitätssicherung umfasst einen Build mit den eigenen Skripten des Ziel-Themes und die Ausführung von Akzeptanztests gegen berechnete Stile, wie in der zugehörigen Qualitäts-Gate-Dokumentation beschrieben. Letztlich bietet das Nextora-Designsystem eine wartbare, entkoppelte und erweiterbare Grundlage für die gesamte Theme-Suite und stellt sicher, dass Änderungen konsistent bleiben und jede Oberfläche auf die zentrale visuelle Autorität verweist.

Funktioniert mit~Claude Code~Codex CLI~Cursor
Part ofDesign & UI
npx skills add https://github.com/miketropi/nextora-skills/tree/main/skills/nextora-design-system
Original anzeigen→Alle Skills durchsuchen

In Ihrer bevorzugten KI fragen

Öffnet einen neuen Chat, in dem dieser Agent-Skill bereits geladen ist.

OpenAIChatGPTClaudeClaudeGeminiGeminiGrokGrokPerplexityPerplexityDeepSeekDeepSeek

Dokumentation

Was macht Nextora-Designsystem?

Alleinige Autorität für das Erscheinungsbild in dieser Suite. Code von Kind-Designs, Blöcken, Vorlagen und Mustern verweist hierher für Palette, Typografie, Tokens, Stilvarianten und den Schalter. Laden Sie dieses Skill zusammen mit nextora-child-themes für jedes neue Kind und mit nextora-gutenberg-blocks für jeden umgestalteten oder neuen Block.

Diese Referenzen zuerst laden

DateiLesen für
references/presets-and-switching.mdKanonische Preset-Identität, Rollenvariablen, blockbezogene Farbspeicherung und PHP-Auflösung, die zwei Stilmechanismen, das Feature-Gate, was ein Kind beiträgt, Entdeckungs-/Zusammenführungsregeln, scheme-switcher.json-Semantik, Laufzeit-Reihenfolge, die Standardrollen für :root bei neuen Kindern und die Liste der Anti-Claims.
../nextora-ecosystem/references/source-map.mdHerkunft und Wurzelauflösungs-Vokabular.
../nextora-ecosystem/references/quality-gates.mdGates plus die gemeinsamen nachgelagerten Akzeptanzrezepte (§8).

In der Referenz zitierte Werte sind Anker, keine aktuellen Daten. Lesen Sie die eigene theme.json, den CSS-Einstieg, den styles/-Ordner und die Schalter-Dateien des Ziels erneut, bevor Sie bearbeiten.

Geordneter Arbeitsablauf

1. Ziel auflösen und die aktiven Erscheinungsquellen identifizieren

Identifizieren Sie das Wurzelverzeichnis des Eltern-Themes und das des aktiven Themes. Lesen Sie dann in dieser Reihenfolge: theme.json (Palette, Farbverläufe, Schriftfamilien, -größen, Abstände, styles, customTemplates), den mitgelieferten CSS-Einstieg (resources/css/app.css für das Eltern-Theme, den eigenen Einstieg des Kindes), den styles/-Baum und scheme-switcher.json. Nehmen Sie niemals einen Palettenwert aus einem Skill, einem Screenshot oder einem Beispiel-Kind-Design.

2. Entscheiden, welcher Mechanismus korrekt ist

BedarfVerwenden
Autor wählt Farbe/Typografie/Abstand für einen Block-WrapperCore-Block supports + get_block_wrapper_attributes()
Eine Farbe innerhalb der eigenen Fläche des BlocksEine blockbezogene Eigenschaft, gespeichert als Preset-Slug, aufgelöst zu einer Preset-Variable bei der Ausgabe (§5)
Eine seitenweite alternative Ansicht, die der Besitzer auswählt und behältEine theme.json-Stilvariation (styles/*.json, styles/typography/*.json)
Eine Besucher-Vorschau-AuswahlDer Schalter, und nur hinter seinem Gate (§6)
Eine Marken-Standardvorgabe für ein gesamtes Kind-ThemeEin Kind-Paletten-/Schriftbeitrag plus die :root-Rollenvorgaben (§7)

Bevorzugen Sie zuerst native Unterstützungen. Fügen Sie eine blockbezogene Überschreibung nur dann hinzu, wenn globale Stile es nicht ausdrücken können, und erfinden Sie niemals ein zweites Erscheinungssystem neben diesen.

3. Presets additiv und nach Identifikator ändern

Fügen Sie Slugs hinzu; benennen Sie keinen übernommenen Eltern-Slug um oder ändern Sie seinen Verweis, den geerbter Inhalt bereits verwendet. Jede Oberfläche liest var(--wp--preset--color--<slug>), var(--wp--preset--gradient--<slug>) oder var(--wp--preset--font-family--<slug>), daher wählt ein wörtlicher Hex-Code in Theme-CSS diese Oberfläche aus Palettenänderungen und aus dem Schalter aus. Spiegeln Sie Tailwind-@theme-Aliase nur dort, wo der CSS-Build sie konsumiert, und überprüfen Sie, worauf jeder Alias tatsächlich verweist, anstatt einen Alias-Block aus einer älteren Anleitung zu kopieren — die --color-secondary des Eltern-Themes löst derzeit zum paragraph-Preset auf.

4. Typografie über die Nextora-Rollen leiten

Schriftarten für Fließtext, Überschriften und Schaltflächen werden über --nextora-font-body, --nextora-font-heading und --nextora-font-button aufgelöst. theme.json verwendet var(--nextora-font-body); der Schalter schreibt diese drei Eigenschaften mit einer konkreten Schriftrasterfamilie inline auf <html>. Eine Oberfläche, die eine Preset-Variable direkt liest, folgt keiner Schriftänderung des Besuchers. Fügen Sie eine Schriftfamilie in theme.json hinzu oder ändern Sie sie (mit fontFace-Assets, wenn es sich nicht um einen Systemstapel handelt) und laden Sie sie, bevor Sie sie als Preset-Auswahl anbieten.

5. Blockbezogene Farben als Presets speichern, bei der Ausgabe auflösen

Befolgen Sie das vorhandene Helfer-Muster in blocks/advanced-icon/color-utils.ts (normalizeColorForStorage, colorValueForPicker) und seine PHP-Gegenstücke (nextora_icon_resolve_color, nextora_icon_hex_to_preset_slug, nextora_ac_resolve_color): Ein ausgewähltes Preset speichert seinen Slug; ein Hex-Code mit voller Deckkraft, der einem Paletteneintrag entspricht, normalisiert sich zu diesem Eintrags-Slug; benutzerdefinierte Farben und 8-stellige Hex-Codes mit Teil-Deckkraft bleiben wörtlich; Farbverläufe behalten die Preset-Identität auf dieselbe Weise. Bei der Ausgabe wird ein gespeicherter Slug zu var(--wp--preset--color--<slug>), sodass eine Palettenänderung die Oberfläche erreicht, und 8-stellige Hex-Codes werden vor sanitize_hex_color() verarbeitet. Ein leerer Wert bedeutet „Theme-Standard“ und gibt nichts aus. Verwenden Sie die echten Signaturen wieder; schreiben Sie keinen parallelen Resolver. Denken Sie daran, dass eine Farbsteuerung kein Sanitizer ist: Gespeichertes HTML durchläuft immer noch wp_kses_post().

6. Das Schalter-Gate respektieren und Daten statt Code beitragen

Der Besucher-Schalter existiert nur, wenn NEXTORA_COLOR_SCHEME_SWITCHER strikt true ist. Andernfalls gibt es keine Nutzlast, kein Skript, kein Seiten-Theme-CSS und kein Popover — und es sollte kein Ersatz auf Kind-Seite geschrieben werden, um die Lücke zu füllen. Ein Kind trägt Daten bei: styles/color-scheme/*.json, styles/font-preset/*.json, optional styles/*.json für eine gebündelte Variation und eine optionale scheme-switcher.json-Whitelist. Wenn Sie ein neues Kind erstellen, setzen Sie die eigenen Standardrollen des Kindes auf :root in seinem später geladenen CSS (§7 der Referenz), anstatt ein Preset-Font festzunageln. Fügen Sie niemals eine Schalter-Implementierung zu einem Kind hinzu.

7. Auf den echten Oberflächen überprüfen

Erstellen Sie mit dem eigenen Skript des Ziels (npm run build:css oder npm run build) — bearbeiten Sie niemals die Ausgabe von assets/css/* und behaupten Sie niemals, dass ein Build assets/js/scheme-switcher.js neu generiert, das von Hand gewartet wird und außerhalb der Pipeline liegt. Wenden Sie dann ../nextora-ecosystem/references/quality-gates.md und dessen §8-Designsystem-Rezept sowie die presetspezifischen Schritte in references/presets-and-switching.md §10 an.

Harte Grenzen

  • Härten Sie keine Marken-Palette fest. Werte stammen aus den aktiven Presets des Ziels.
  • Übernehmen Sie keine veralteten Fallback-Hex-Codes aus älteren Dokumenten in neues Theme-CSS.
  • Implementieren Sie den Schalter nicht neu und behaupten Sie nicht, dass er funktioniert, weil ein Beispiel-Kind-Theme richtig aussieht: Das Beispiel fixiert seine eigenen Schriftarten und fügt nur für das Kind gültige Paletteneinträge hinzu.
  • Versprechen Sie nicht, dass ein Farb-URL-Parameter ein bereits aufgelöstes gebündeltes Theme überschreibt oder dass ein Zurücksetzen die Site-Editor-Stile löscht.
  • Gestalten Sie wp-admin-Chrome nicht aus einem Theme-Stylesheet um; Editor-Resets bleiben innerhalb der Editor-Leinwand.
  • Erhöhen Sie nicht stillschweigend das deklarierte WordPress/PHP-Minimum – machen Sie die Anforderung stattdessen sichtbar.
  • Ändern Sie das Eltern- oder Beispiel-Kind-Theme nicht, während Sie diese Arbeit ausführen.

Abschlussprüfungen

  • Ziel-Theme aufgelöst; jedes referenzierte Preset, jede Schriftart, jeder Farbverlauf und jeder Token existiert in der eigenen theme.json/den Variationen dieses Themes.
  • Die Mechanismus-Tabelle in Schritt 2 wurde befolgt; native Unterstützungen wurden verwendet, wo sie ausreichen.
  • Typografie wird über die --nextora-font-*-Rollen aufgelöst und folgt einer Preset-Änderung.
  • Blockbezogene Farben speichern einen Preset-Slug, wo die Farbe einem Preset entspricht, behalten benutzerdefinierte und teildeckende Werte wörtlich und werden über Preset-Variablen gerendert.
  • Das Schalter-Gate wird respektiert; ein Kind-Beitrag besteht nur aus Daten; jedes neue Standardpaar für ein neues Kind wird auf :root über die Rollen deklariert.
  • Stilvarianten (persistent) und der Schalter (Laufzeit-Vorschau) werden als verschiedene Dinge beschrieben und getestet.
  • Die Akzeptanzschritte aus §8 wurden gegen berechnete Stile ausgeführt, oder die nicht verifizierte Oberfläche wird klar gemeldet.

Grenzen

Nur Markdown-Anweisungen und quellgestützte Referenzen: keine Laufzeitskripte, Generatoren, kopierten Theme-Bäume, Paketverwaltung oder Installationsautomatisierung und keine Änderungen an Eltern- oder Kind-Theme-Quellen. Nachgelagerte Build- und Browser-Überprüfungsbefehle gehören zum Ziel-Theme und sind in ../nextora-ecosystem/references/quality-gates.md aufgeführt.

Individual skills in this repo

This repo contains 4 individual skills — each has its own dedicated page.

miketropi/nextora-child-themes

Create, bootstrap or audit a child theme of the Nextora parent block theme — the style.css header with Template nextora, the functions.php load order, the single version constant kept in sync with the header, the front-end and editor-canvas asset pipeline with its parent handle dependencies, the child block registrar and inserter category, PHP/i18n conventions, and the optional feature-file layout. Use when a request names a Nextora child, a new child theme name or slug, a child theme header or version bump, child CSS/JS enqueueing, editor canvas styles, a child block folder or block category, porting Nextsaas conventions into a new child, or asks why child code cannot call the parent at file scope. Pair with nextora-design-system for any child that must follow palette or visitor font/colour switching.

miketropi/nextora-ecosystem

Entry point for work on the Nextora block-theme ecosystem — child themes, Gutenberg blocks, design presets and the visitor colour/font switcher, and template/part/pattern composition. Use when a request mentions Nextora or a Nextora child theme, when the task spans more than one of those areas, or when you need the source map and production quality gates for this ecosystem before writing code. Also use to decide which specialist skill a multi-part request needs.

miketropi/nextora-site-composition

Compose the surfaces of a Nextora or Nextora child block theme — HTML templates and template parts, PHP block patterns and their categories, page templates and the template hierarchy, front-page versus posts-index, filesystem patterns referenced from thin templates, core query/archive/search loops and explicit query context, header and footer ownership, and filesystem-versus-Site-Editor customisation. Use when a request asks for a landing page layout, a page template, an archive or search composition, a reusable pattern or section, a header/footer part, a query loop, or asks why a template file edit shows no change on the front end.

nextora-gutenberg-blocks

Build or change Gutenberg blocks in the Nextora parent theme or a Nextora child theme — block.json registration, typed attributes, native visual editing with RichText and media, InspectorControls settings panels, repeatable list editors with modal item editing, render.php output, view scripts, block style variations, and the esbuild block pipeline. Use when a request mentions a block, block.json, edit.tsx, index.tsx, render.php, ServerSideRender, InnerBlocks, a repeater or list editor, a modal item form, an inspector panel, a block category, or "add/restyle a section block" for Nextora.

Verwandte Skills

steipete/sag

ElevenLabs text-to-speech with mac-style say UX.

community

steipete/oracle

Oracle CLI second-model review/debug/refactor/design with selected files, dry-run token checks, API or browser engine.

community

steipete/peekaboo

Capture and automate macOS UI with the Peekaboo CLI.

community

mattpocock/design-an-interface

Generate multiple radically different interface designs for a module using parallel sub-agents. Use when user wants to design an API, explore interface options, compare module shapes, or mentions "design it twice".

community

mattpocock/prototype

Build a throwaway prototype to flesh out a design — a runnable terminal app for state/business-logic questions, or several radically different UI variations toggleable from one route.

community

mattpocock/grill-me

Interview the user relentlessly about a plan or design until reaching shared understanding, resolving each branch of the decision tree. Use when user wants to stress-test a plan, get grilled on their design, or mentions "grill me".

community