Communitygithub.com

nextora-design-system

Couleurs, typographie, espacements, variations de style et le sélecteur optionnel de couleurs/polices pour le thème parent Nextora et ses thèmes enfants.

Qu'est-ce que nextora-design-system ?

Cette compétence définit l'autorité unique pour l'apparence dans la suite Nextora. Elle est nécessaire pour tout travail sur un thème enfant, un bloc Gutenberg, un modèle ou un motif, car elle centralise la palette, la typographie, les jetons de design, les variations de style et le sélecteur de couleurs/polices pour le visiteur. Toute demande mentionnant une palette, un rôle de couleur, un slug de préréglage, une famille de polices, un préréglage de police, les paramètres theme.json, les alias Tailwind @theme, les propriétés CSS personnalisées, une variation de style, « suivre la palette », « doit changer avec le choix du visiteur », les couleurs de bloc délimitées ou l'apparence d'un nouveau thème enfant déclenche son utilisation. La compétence impose des règles strictes : ne pas coder en dur une palette, ne pas réimplémenter le sélecteur, stocker les couleurs délimitées sous forme de slugs de préréglage et les résoudre via des variables CSS, et router la typographie à travers les rôles Nextora dédiés. Elle s'applique à l'écosystème Nextora (thème parent, thèmes enfants, blocs Gutenberg, sélecteur de schéma) et repose sur la consultation des fichiers de référence (`presets-and-switching.md`, `source-map.md`, `quality-gates.md`) avant toute modification.

Compatible avec~Claude Code~Codex CLI~Cursor
npx skills add https://github.com/miketropi/nextora-skills/tree/main/skills/nextora-design-system

Demander à votre IA préférée

Ouvre une nouvelle conversation avec cette compétence d'agent déjà préchargée.

Documentation

Système de design Nextora

Autorité unique pour l'apparence dans cette suite. Le code des thèmes enfants, le code des blocs, les modèles et les motifs se réfèrent tous ici pour la palette, la typographie, les jetons, les variations de style et le sélecteur. Chargez cette compétence avec nextora-child-themes pour tout nouvel enfant, et avec nextora-gutenberg-blocks pour tout bloc restylisé ou nouveau bloc.

Charger ces références en premier

FichierÀ lire pour
references/presets-and-switching.mdIdentité canonique des préréglages, variables de rôle, stockage délimité des couleurs et résolution PHP, les deux mécanismes de style, le verrouillage de fonctionnalité, ce qu'un enfant apporte, les règles de découverte/fusion, la sémantique de scheme-switcher.json, la priorité d'exécution, les valeurs par défaut des rôles :root pour un nouvel enfant, et la liste des contre- revendications.
../nextora-ecosystem/references/source-map.mdVocabulaire de provenance et résolution racine.
../nextora-ecosystem/references/quality-gates.mdPortes qualité et les recettes partagées d'acceptation en aval (§8).

Les valeurs citées dans la référence sont des ancres, pas des données actuelles. Relisez le theme.json de la cible, son point d'entrée CSS, l'arborescence styles/ et les fichiers du sélecteur avant d'éditer.

Flux de travail ordonné

1. Résoudre la cible et identifier les sources d'apparence actives

Identifiez la racine du thème parent et la racine du thème actif. Lisez ensuite, dans l'ordre : theme.json (palette, dégradés, familles de polices, tailles, espacements, styles, customTemplates), le point d'entrée CSS livré (resources/css/app.css pour le parent, le point d'entrée de l'enfant), l'arborescence styles/ et scheme-switcher.json. Ne prenez jamais une valeur de palette depuis une compétence, une capture d'écran ou un exemple d'enfant.

2. Décider quel mécanisme est correct

BesoinUtiliser
L'auteur choisit une couleur/typographie/espacement pour un wrapper de blocPrise en charge native du bloc supports + get_block_wrapper_attributes()
Une couleur à l'intérieur de la surface propre du blocUn attribut délimité, stocké comme slug de préréglage, résolu en variable de préréglage à la sortie (§5)
Un aspect alternatif à l'échelle du site que le propriétaire choisit et conserveUne variation de style de theme.json (styles/*.json, styles/typography/*.json)
Un choix de prévisualisation pour le visiteurLe sélecteur, et uniquement derrière son verrouillage (§6)
Une valeur par défaut de marque pour un thème enfant completUne contribution de palette/police de l'enfant plus les valeurs par défaut des rôles :root (§7)

Privilégiez d'abord les prises en charge natives. Ajoutez une substitution délimitée uniquement lorsque les styles globaux ne peuvent pas l'exprimer, et n'inventez jamais un deuxième système d'apparence en dehors de ceux-ci.

3. Modifier les préréglages de manière additive et par identifiant

Ajoutez des slugs ; ne renommez pas et ne redirigez pas un slug parent que le contenu hérité utilise déjà. Chaque surface lit var(--wp--preset--color--<slug>), var(--wp--preset--gradient--<slug>) ou var(--wp--preset--font-family--<slug>), donc un hexadécimal littéral dans le CSS du thème exclut cette surface des changements de palette et du sélecteur. Ne reflétez les alias @theme Tailwind que là où la construction CSS les consomme, et vérifiez ce que chaque alias pointe réellement plutôt que de copier un bloc d'alias depuis un guide plus ancien — le --color-secondary du parent se résout actuellement au préréglage paragraph.

4. Router la typographie à travers les rôles Nextora

La typographie du corps, des titres et des boutons se résout via --nextora-font-body, --nextora-font-heading et --nextora-font-button. theme.json utilise var(--nextora-font-body) ; le sélecteur écrit ces trois propriétés en ligne sur <html> avec une pile de familles concrète. Une surface qui lit directement une variable de préréglage ne suivra pas un changement de police du visiteur. Ajoutez ou modifiez une famille de polices dans theme.json (avec les ressources fontFace lorsqu'il ne s'agit pas d'une pile système) et chargez-la avant de la proposer comme choix de préréglage.

5. Stocker les couleurs délimitées comme préréglages, les résoudre à la sortie

Suivez le modèle d'assistant existant dans blocks/advanced-icon/color-utils.ts (normalizeColorForStorage, colorValueForPicker) et ses homologues PHP (nextora_icon_resolve_color, nextora_icon_hex_to_preset_slug, nextora_ac_resolve_color) : un préréglage choisi stocke son slug ; un hexadécimal à opacité totale correspondant à une entrée de palette se normalise en slug de cette entrée ; les couleurs personnalisées et les hexadécimaux partiellement opaques à 8 chiffres restent littéraux ; les dégradés conservent l'identité du préréglage de la même manière. À la sortie, un slug stocké devient var(--wp--preset--color--<slug>) afin qu'un changement change la palette atteigne la surface, et les hexadécimaux à 8 chiffres sont traités avant sanitize_hex_color(). Une valeur vide signifie « valeur par défaut du thème » et n'émet rien. Réutilisez les signatures réelles ; n'écrivez pas un résolveur parallèle. Rappelez-vous qu'un contrôle de couleur n'est pas un assainisseur : le HTML stocké passe toujours wp_kses_post().

6. Respecter le verrouillage du sélecteur et contribuer des données plutôt que du code

Le sélecteur pour visiteur existe uniquement lorsque NEXTORA_COLOR_SCHEME_SWITCHER est strictement true. En dehors de cela, il n'y a pas de charge utile, pas de script, pas de CSS de thème de page et pas popover — et aucune substitution du côté enfant ne doit être écrite pour combler le vide. Un enfant contribue des données : styles/color-scheme/*.json, styles/font-preset/*.json, éventuellement styles/*.json pour une variation incluse, et une liste d'autorisation scheme-switcher.json facultative. Lors de la création d'un nouvel enfant, définissez les rôles par défaut propres de l'enfant sur :root dans son CSS chargé ultérieurement (§7 de la référence) au lieu de fixer une police de préréglage. N'ajoutez jamais d'implémentation de sélecteur à un enfant.

7. Vérifier sur les surfaces réelles

Construisez avec le script propre de la cible (npm run build:css ou npm run build) — ne modifiez jamais la sortie assets/css/*, et ne déclarez jamais qu'une construction régénère assets/js/scheme-switcher.js, qui est maintenu manuellement et en dehors du pipeline. Appliquez ensuite ../nextora-ecosystem/references/quality-gates.md et sa recette §8 du système de design ainsi que les étapes spécifiques aux préréglages dans references/presets-and-switching.md §10.

Limites strictes

  • Ne codez pas en dur une palette de marque. Les valeurs proviennent des préréglages actifs de la cible.
  • Ne propagez pas d'hexadécimaux de secours obsolètes provenant d'anciens documents dans le nouveau CSS du thème.
  • Ne réimplémentez pas le sélecteur et ne prétendez pas qu'il fonctionne parce qu'un exemple d'enfant semble correct : l'exemple fixe ses propres polices et ajoute des entrées de palette réservées aux enfants.
  • Ne promettez pas qu'un paramètre d'URL de couleur remplace un thème groupé déjà résolu, ou que Réinitialisation efface les styles de l'éditeur de site.
  • Ne restylisez pas l'interface wp-admin à partir d'une feuille de style de thème ; les réinitialisations d'éditeur restent à l'intérieur du canevas de l'éditeur.
  • Ne réduisez pas silencieusement la version minimale déclarée de WordPress/PHP — mettez en surface l'exigence à la place.
  • Ne modifiez pas le thème parent ou l'exemple d'enfant pendant la réalisation de ce travail.

Vérifications d'achèvement

  • Thème cible résolu ; chaque préréglage, police, dégradé et jeton référencé existe dans le theme.json/variations de ce thème.
  • Le tableau des mécanismes à l'étape 2 a été suivi ; les prises en charge natives utilisées lorsqu'elles suffisent.
  • La typographie se résout via les rôles --nextora-font-* et suit un changement de préréglage.
  • Les couleurs délimitées stockent un slug de préréglage lorsque la couleur correspond à un préréglage, conservent les valeurs personnalisées et partiellement opaques littéralement, et se rendent via des variables de préréglage.
  • Le verrouillage du sélecteur est respecté ; la contribution d'un enfant est uniquement des données ; toute paire par défaut d'un nouvel enfant est déclarée sur :root via les rôles.
  • Les variations de style (persistantes) et le sélecteur (prévisualisation à l'exécution) sont décrits et testés comme des choses différentes.
  • Les étapes d'acceptation du §8 ont été exécutées sur des styles calculés, ou la surface non vérifiée est rapportée clairement.

Limites

Instructions Markdown et références sourcées uniquement : pas de scripts d'exécution, de générateurs, d'arbres de thèmes copiés, de gestion de paquets ou d'automatisation d'installation, et aucune modification des sources du thème parent ou enfant. Les commandes de construction et de vérification en aval dans le navigateur appartiennent au thème cible et sont listées dans ../nextora-ecosystem/references/quality-gates.md.

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.

Skills associés