Communitygithub.com

umairmsm/wp-design

Étape 2 d'une construction WordPress wp-site-kit : direction du design, prototype HTML/CSS statique avec tokens de design, validation du propriétaire avec captures d'écran, polices auto-hébergées et port du look approuvé dans un skin WordPress interchangeable.

Qu'est-ce que wp-design ?

Cette compétence guide la phase de design d'un projet WordPress basé sur wp-site-kit. Elle commence par définir une direction créative (via un document DESIGN_DIRECTION.md avec des moodboards ou maquettes minimales), puis la transforme en un prototype HTML/CSS statique utilisant des tokens de design (tokens.css) qui reflètent exactement ceux du thème WordPress. L'accessibilité est intégrée dès le départ (contraste, focus visible, navigation clavier, prefers-reduced-motion). Après validation du propriétaire (captures d'écran téléphone et ordinateur), les polices sont auto-hébergées au format woff2, puis le design est porté vers un skin WordPress en copiant les tokens, le CSS des composants et en adaptant les templates sans modifier les contrats de données et de balisage du thème de base. La compétence insiste sur la création de chaque design comme un skin interchangeable, ce qui permet des refontes ultérieures sans perdre les fonctionnalités existantes.

Compatible avec~Claude Code~Codex CLI~Cursor
npx skills add https://github.com/umairmsm/wp-site-kit/tree/HEAD/skills/wp-design
Voir l'original→Voir toutes les compétences

Demander à votre IA préférée

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

OpenAIChatGPTClaudeClaudeGeminiGeminiGrokGrokPerplexityPerplexityDeepSeekDeepSeek

Documentation

Étape 2 : Design

Objectif : le propriétaire a approuvé un look qu'il a vu sur un téléphone et un ordinateur portable. Il est écrit sous forme de tokens, afin de pouvoir devenir un skin WordPress par copie, et d'être remplacé ultérieurement sans perte de fonctionnalités.

Étapes

  1. Direction. Remplir le docs/DESIGN_DIRECTION.md du projet : étoile polaire, public cible, ce à quoi nous ne devons pas ressembler (concurrents, modèles), et les non-négociables. Proposer au maximum deux ou trois directions, sous forme de petits moodboards ou de maquettes héros, pas de sites complets.
  2. Prototype dans static/. HTML et CSS simples. css/tokens.css utilise les mêmes noms que le skins/default/tokens.css du thème. Les composants utilisent uniquement les tokens. Structure réelle (en-tête, héros, cartes, formulaire, pied de page), contenu fictif, pas de prix ni de texte de politique.
  3. Accessibilité dès le départ :
    • contraste ≥ 4.5:1 pour le texte ;
    • focus visible ;
    • un seul H1 ;
    • un lien d'évitement ;
    • parcours clavier ;
    • respect de prefers-reduced-motion. Vérifier le prototype avec axe (extension de navigateur) avant de le présenter.
  4. Validation par le propriétaire. Captures d'écran de chaque page aux largeurs téléphone (375 px) et ordinateur portable (1440 px). Enregistrer la date de validation dans DESIGN_DIRECTION.md et sauvegarder les captures dans docs/design/.
  5. Polices : auto-héberger les fichiers .woff2, les sous-ensembles pour les langues nécessaires, vérifier la licence, et précharger les un ou deux premiers visages à l'écran (les nommer *-preload.woff2). Aucune requête vers Google Fonts.
  6. Port vers WordPress (references/design-system.md) :
    • copier les tokens dans le skin ;
    • déplacer le CSS des composants dans skin.css ;
    • organiser les templates avec les fonctions de rendu du thème de base ;
    • ajouter des surcharges de parties de skin uniquement là où le balisage doit différer. Le look change ; les contrats de données et de balisage du thème de base restent inchangés.
  7. Les refontes ultérieures sont de nouveaux skins : copier skins/default vers skins/<nom>, modifier les tokens, prévisualiser avec ?skin=<nom> (administrateurs), et basculer avec l'option <prefixe>_skin une fois approuvé.

Porte (cocher dans SITE_STATUS.md)

  • DESIGN_DIRECTION.md rédigé ; validation du propriétaire enregistrée avec captures d'écran
  • Tokens définis ; les composants utilisent uniquement les tokens
  • Polices auto-hébergées ; 0 requête vers Google Fonts

Leçons apprises

  • Le design verrouillé a changé lorsque le partenaire commercial a envoyé sa propre refonte. Parce que le look était un skin, le changement a conservé toutes les fonctionnalités. Construisez chaque design comme un skin, même le premier.
  • Ne copiez pas la palette, l'association typographique ou la mise en page d'un concurrent. Les propriétaires le remarquent, et les visiteurs ne se souviennent pas de vous.
  • Un skin de test uniquement (dev-*) pour essayer des idées n'apparaît jamais en production.
  • Si les compétences frontend-design ou design-motion-principles sont installées, utilisez-les pour la direction et le mouvement.

Individual skills in this repo

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

umairmsm/wp-build

Stage 3 of a wp-site-kit WordPress build - local DDEV site, the core must-use plugin (modules), the presentation-only child theme with skins, the content model (custom post types, meta, WP_Query, render functions), and the enquiry pipeline that saves leads before forwarding. Use when building or changing features, templates, content types, forms or plugin modules on a wp-site-kit site.

umairmsm/wp-content

Stage 4 of a wp-site-kit WordPress build - real copy and photos. Content truth (facts only from the owner), AI drafts and owner approval, claims audits, banned words and fake proof, legal pages, the photo pipeline (dedupe, real-only, EXIF strip, WebP sizes, alt text, AI image register), and recorded content changes. Use for "write the copy", "add photos", "the owner sent new photos", "check for duplicates", "update prices or text on the live site", "legal pages".

umairmsm/wp-kickoff

Stage 1 of a wp-site-kit WordPress build. Use when starting a new WordPress website or taking over or rebuilding an existing one - discovery brief, stack decision, creating the project with bin/wp-site-new, locked decisions, private repo and credentials inventory. Triggers - "new WordPress site", "start a client website", "rebuild this site", "take over this WordPress site".

umairmsm/wp-operate

Stage 8 of a wp-site-kit WordPress build and everything after launch - backups with an off-machine copy, restore drills, the disaster-recovery runbook, credentials inventory, update policy, alerts, and working from more than one machine (bridge file, workstation doctor, encrypted state bundle, rescuing unpushed work). Use for "backup", "restore", "move to a new machine/server", "update plugins", "what if the server dies", "work from the cloud box", "set up a second machine".

umairmsm/wp-seo

Stage 5 of a wp-site-kit WordPress build - titles and descriptions, canonical URLs, one schema owner and JSON-LD, sitemaps, robots.txt and llms.txt, AI crawler access, redirects (301 vs 302), legacy URL maps, Search Console, and adding languages one pilot at a time with Polylang (hreflang, .po/.mo strings, native review). Use for "SEO", "schema", "redirect", "old URLs", "translate the site", "add French/Spanish", "hreflang", "canonical".

umairmsm/wp-ship

Stage 7 of a wp-site-kit WordPress build - staging behind Cloudflare Access, server hardening, safe deploys from a commit (scripts/deploy-safe.sh), database content changes, the launch audit, DNS cutover without breaking a running business, and the first week after launch. Use for "deploy", "set up staging", "go live", "launch", "cutover", "move DNS", "harden the server".

umairmsm/wp-site

Start here for any WordPress website built with wp-site-kit, from an empty folder to a live site. Use when someone says "build a WordPress site", "new website for a client", "where are we on the site", "what is next before launch", or asks to continue a site project. Finds the current stage from SITE_STATUS.md, applies the hard rules, and hands over to the right stage skill.

Skills associés

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