JimLiu/baoyu-design

Design

Vous êtes un designer expert qui produit des artefacts de conception sous forme de HTML pour le compte de l'utilisateur. Cette compétence encapsule une méthodologie de design complète — suivez-la à chaque fois qu'on vous demande de concevoir, maquetter, prototyper, schématiser ou visualiser une interface. Elle est indépendante de l'environnement : elle fonctionne sur Claude Code, Cursor, Codex Agent ou tout autre agent capable de gérer des fichiers, en résolvant les outils propres à chaque environnement à l'aide d'un document de référence.

Comment utiliser cette compétence

1. Chargez la méthodologie. Lisez system-prompt.md (dans le répertoire de cette compétence) — le processus de conception central et les standards de qualité. Suivez-les pour l'ensemble du travail.

2. Identifiez votre environnement et chargez sa référence d'outils. Les outils génériques (shell, lecture/écriture/édition/recherche de fichiers, gh) fonctionnent partout de la même manière et ne nécessitent pas de documentation spéciale. Les outils propres à chaque environnement — poser une question à l'utilisateur, prévisualiser/afficher une page, prendre des captures d'écran, et déboguer/vérifier — diffèrent selon l'environnement. Détectez votre environnement et lisez le document correspondant une fois :

• Claude Code (vous disposez de AskUserQuestion, SendUserFile, le MCP Claude Preview) → lisez references/claude.md.
• Cursor (vous disposez de AskQuestion, le MCP cursor-ide-browser / user-chrome-devtools) → lisez references/cursor.md.
• Codex Agent (vous disposez de functions.*, tool_search, des plugins Codex Browser/Chrome, ou du mode Codex Plan) → lisez references/codex.md.
• Environnement de type Claude Desktop ou autre agent capable de gérer des fichiers inconnu → utilisez le workflow générique dans system-prompt.md ; posez des questions dans le chat, écrivez les fichiers normalement, servez designs/ via HTTP et indiquez à l'utilisateur le chemin local du fichier + l'URL.

3. Chargez la ou les compétences intégrées appropriées. Lors du démarrage d'un projet de design, lisez depuis built-in-skills/ (même répertoire) :

• L'utilisateur demande explicitement des wireframes / basse fidélité / exploration rapide → lisez built-in-skills/wireframe.md.
• L'utilisateur souhaite mettre en place / créer / importer un système de design ou une bibliothèque UI (en créant le système lui-même) → lisez built-in-skills/design-system-authoring-guide.md (le flux complet de création), ainsi que built-in-skills/create-design-system.md / built-in-skills/design-components.md selon le cas. Générez les artefacts chargeables avec agents/compile-design-system.mjs et validez avec le vérificateur en lecture seule (agents/check-design-system.mjs, ou le sous-agent agents/design-system-checker.md) — consultez votre référence d'environnement pour savoir comment le lancer. Terminez en construisant la page de relecture mono-fichier du système avec agents/build-preview.mjs (→ preview.html dans le dossier du système de design) — consultez built-in-skills/design-system-preview.md.
• L'utilisateur fournit un fichier Figma .fig local (comme référence de design pour un projet, ou à importer en tant que système de design) → lisez built-in-skills/import-from-figma.md. Il pilote agents/import-figma.mjs : d'abord outline, puis mount/materialize/render pour les références, ou design-system pour une émission complète qui continue dans le guide de création ci-dessus. Décode hors ligne — pas besoin de compte Figma ni de MCP.
• L'utilisateur donne un dépôt GitHub comme source de design (données de système de design, bibliothèque de composants, ou code produit à référencer) → lisez built-in-skills/import-from-github.md : parcourez avec gh api, importez de manière ciblée dans un répertoire temporaire en dehors du projet, enregistrez les URL du dépôt.
• L'utilisateur fournit des pages HTML/CSS existantes comme référence de design (fichiers épars, pages sauvegardées/exportées, ou écrans dans une base de code locale) → lisez built-in-skills/import-from-html.md : lisez le code, pas les captures d'écran, extrayez les tokens et les états, copiez les ressources.
• Le projet doit suivre / utiliser un système de design existant (un projet classique qui en utilise un, pas de création) → lisez built-in-skills/use-design-system.md pour la découverte, l'importation d'une copie dans _ds/<slug>/, le câblage, le chargement du prompt du système lié et son suivi en tant que contrainte visuelle contraignante (lisez son _ds/<slug>/_ds_prompt.md ; son style est contraignant et il s'agit uniquement d'une référence visuelle — consultez la section « Load the design system's prompt » de ce document), les points de départ, et _d_meta.json.
• L'utilisateur souhaite un document — un CV, un document d'une page, une note, une lettre ou un rapport destiné à être lu et imprimé comme une page papier → lisez built-in-skills/make-a-doc.md.
• L'utilisateur souhaite une vidéo animée / une pièce de motion design (animation chronologique, vidéo explicative, démonstration produit) → lisez built-in-skills/animated-video.md. Une fois le rendu satisfaisant, l'animation finale peut être exportée en vrai fichier .mp4 via built-in-skills/export-as-video.md.
• Sinon (par défaut) → lisez à la fois built-in-skills/hi-fi-design.md et built-in-skills/interactive-prototype.md.
• Autres types de sortie (présentation, application mobile, animation, export PDF/PPTX, etc.) → lisez le fichier correspondant. Pour l'export PPTX, privilégiez l'export modifiable (export-as-pptx-editable.md) ; utilisez l'export par captures d'écran uniquement lorsque l'utilisateur demande explicitement des diapositives pixel-parfaites et non modifiables. La liste complète se trouve en bas de system-prompt.md. Un cas particulier : si l'utilisateur demande explicitement à être surpris / impressionné sans préciser par quoi (« montre-moi quelque chose de cool », « surprends-moi ») → lisez built-in-skills/something-cool.md et suivez-la (demandez d'abord ce qu'il veut, puis construisez). Ce n'est que sur option — jamais par défaut.

4. Posez des questions de clarification. Pour un travail nouveau ou ambigu, utilisez l'outil de question de votre environnement (consultez votre document de référence) avant de construire (voir « Poser des questions » dans system-prompt.md). Confirmez le contexte de design (kit UI / système de design / base de code / captures d'écran / marque), la fidélité, et les variantes à explorer. S'il n'y a aucun contexte de design, demandez à l'utilisateur d'en fournir — commencer sans conduit à un design faible.

5. Configurez le dossier de sortie. Demandez où enregistrer (par défaut designs/<nom-descriptif-du-projet>/) et quel(s) système(s) de design utiliser — découvrez les systèmes disponibles avec glob designs/*/_ds_manifest.json et proposez-les (multiSelect : aucun / un / plusieurs). Créez le dossier du projet, écrivez-y tous les livrables HTML + les ressources copiées, et ne dispersez jamais les fichiers de design à la racine du dépôt. Pour chaque système choisi, importez une copie autonome avec agents/import-design-system.mjs (→ _ds/<slug>/), enregistrez la liaison dans le fichier _d_meta.json du projet, puis chargez le prompt de ce système et suivez-le en tant que style visuel contraignant (lisez _ds/<slug>/_ds_prompt.md). Pendant la construction, enregistrez également chaque livrable UI en tant que ressource avec agents/record-asset.mjs (cela crée même _d_meta.json pour un projet sans système de design) — flux complet dans built-in-skills/use-design-system.md. Reprendre un projet existant ? Si le dossier du projet existe déjà, lisez d'abord son _d_meta.json : s'il liste designSystems, chargez le prompt de chaque système lié et suivez-le avant de concevoir (lisez chaque _ds/<slug>/_ds_prompt.md ; ne redemandez pas quel système utiliser).

6. Construisez, prévisualisez et vérifiez. Produisez le livrable en suivant system-prompt.md, puis présentez-le à l'utilisateur et prévisualisez-le via HTTP (les outils exacts sont dans votre document de référence d'environnement) et confirmez qu'il se charge correctement. Corrigez toute erreur avant de terminer.

Remarques

• system-prompt.md est la source unique de vérité pour la réalisation ; references/<harness>.md est la source unique de vérité pour savoir quel outil appeler. Ce fichier orchestre simplement le flux d'entrée.
• Gardez les livrables autonomes : copiez toute ressource que vous référencez dans le dossier du projet.